The SecNews technical team is monitoring a new, critical issue regarding the Gitea Docker image : the CVE-2026-20896 vulnerability , which can lead to authentication bypass and user (even administrator) impersonation in environments where reverse-proxy authentication is enabled. According to reports, the first signs of probing by threat actors have already appeared, which increases the pressure for immediate configuration checks and upgrades.
The issue does not affect "all" Gitea installations, but mainly deployments that expose the container's backend HTTP port beyond the trusted reverse proxy. When this happens, an attacker can try to pass artificial credentials with an HTTP header, turning a false assumption of trust into a real breach mechanism.
See also: Over 400 Arch Linux AUR packages seized for Infostealer development
What is CVE-2026-20896 and why does it affect Gitea Docker image?
CVE -2026-20896 is related to the way Gitea's official Docker images package default settings. As mentioned in the official release notes for version 1.26.3/1.26.4, the Docker template included a default REVERSE_PROXY_TRUSTED_PROXIES = * , which essentially allows any IP address to be considered a "trusted proxy" for header-based authentication purposes.
In deployments where the administrator enables reverse-proxy authentication, Gitea can rely on identity headers such as X-WEBAUTH-USER to identify the user, assuming that this header is only inserted by a trusted proxy. With the above wildcard trust, the assumption breaks down: if the attacker can reach the container port directly (outside the proxy “path”), he can try to declare any username.
When does it become exploitable and what is the risk?
Exploitation is not “one size fits all”. For there to be a real risk, conditions must be present such as: enabled reverse-proxy authentication, incorrect trust in proxies (wildcard or too wide range) and, most importantly, the ability to access the Gitea HTTP server without the intermediary of the authenticated proxy. In such a case, impersonation can lead to access to repositories, tokens, webhooks, organization settings and potentially pave the way for a supply-chain incident.
According to The Hacker News, Sysdig detected the first signs of activity that looked like initial probing a few days after the disclosure, but no full exploit chain had been confirmed at the time of reporting.
See also: Target: Dev server offline – Hackers say they stole source code
Which versions are affected and what was fixed
Based on the available evidence, the vulnerability affects Gitea Docker images up to 1.26.2 and was addressed in 1.26.3, while maintainers quickly moved on to 1.26.4 for additional fixes. In the official article “release of 1.26.3 and 1.26.4”, the Gitea team explicitly describes that the default REVERSE_PROXY_TRUSTED_PROXIES = * allowed any source IP to impersonate via the X-WEBAUTH-USER, and that reverse-proxy authentication is now opt-in and admin-configured.
What should administrators do now?
The SecNews technical team recommends a practical “control-restrict-upgrade” approach. First, confirm which Docker image you are running and immediately upgrade to 1.26.3+ (ideally the latest stable) if you are using the official image. Next, check if the deployment allows direct access to the Gitea backend port: in Docker/Compose look at the published ports and firewall rules, while in Kubernetes check Services/Ingress and NetworkPolicies so that only the trusted proxy can “talk” to the service.
Finally, even after the upgrade, it is worth looking for suspicious signs in logs and admin events (e.g. unusual admin sessions, new tokens, changes to webhooks or addition of SSH keys) for the exposure period. In environments based on reverse-proxy auth, it is good practice for the proxy to strip any incoming identity header from the client and replace it only after it has completed authentication itself.
See also: LiteLLM vulnerability chain allows AI gateway server takeover
The conclusion is that the Gitea Docker image should be treated as a critical element of the software development chain. A seemingly small default in a configuration template can become an entry point for attackers, especially when combined with incorrect service exposure to the network. Timely upgrade and proper access restriction to the backend significantly reduce the possibility of abuse.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
