Hackers Actively Exploiting Critical Auth Bypass in Gitea Docker Image

Attackers are actively compromising self-hosted Gitea instances right now by exploiting a critical authentication bypass in the official Gitea Docker image. The flaw lets unauthenticated attackers impersonate any user on the platform — including administrators — without supplying a password.

What Happened

BleepingComputer reports that threat actors are in-the-wild exploiting a critical flaw specific to the official Docker image for Gitea, a widely-used open-source self-hosted Git service. The vulnerability enables full user impersonation — an attacker can authenticate as any account, including site admins, with no credentials required.

The flaw is specific to the Docker image deployment path, not to bare-metal or package-manager installs. Active exploitation is confirmed, meaning a working exploit or automated scanner is already in circulation.

Why It Matters

Gitea is a go-to choice for teams running a lightweight, self-hosted alternative to GitHub or GitLab. If your instance is internet-accessible — or reachable from any compromised host on your internal network — this vulnerability hands an attacker:

• Full administrative control — modify user accounts, permissions, and site configuration
• Read/write access to all repositories — exfiltrate source code or push malicious commits
• Supply chain exposure — any CI/CD pipeline pulling from those repos is now suspect
• Credential harvesting — SSH keys, deploy tokens, and OAuth secrets stored in Gitea are readable

An unauthenticated admin-level auth bypass is one of the most severe vulnerability classes for code hosting infrastructure. The blast radius extends beyond Gitea itself: everything downstream of your repos — builds, deployments, artifacts — is potentially tainted.

What To Do

Act immediately if you run Gitea via the official Docker image.

1. Update the image now. Run docker pull gitea/gitea:latest and redeploy. If you pin to a version tag, check the Gitea releases page for the patched version and update your compose file accordingly.

1. Audit access logs. Look for unexpected logins, newly created admin accounts, SSH key additions, or repository changes from unfamiliar IP addresses. Gitea logs live at /data/gitea/log/ inside the container volume by default.

1. Rotate all credentials stored in Gitea. Deploy keys, personal access tokens, OAuth application secrets, and webhook secrets should all be treated as compromised until rotated.

1. Review recent commits on critical branches. Check for unauthorized pushes to default branches or any branch that feeds automated deployments. Pay particular attention to CI configuration files.

1. Restrict network access. If Gitea doesn't need to be publicly reachable, put it behind a VPN or firewall while you assess and remediate.

1. Hunt for persistence. New admin accounts, unfamiliar SSH public keys, and webhook URLs pointing to external hosts are common attacker footholds.

If you deployed Gitea via a system package manager rather than Docker, you are likely not affected by this specific vector — but confirm against the upstream advisory once it publishes full CVE details.

Confirmed active exploitation means this is not a "patch this week" situation. Self-hosted Git infrastructure sits upstream of everything you build and ship — treat it accordingly.