CVE-2026-20896

Gitea can be set up so a reverse proxy (like a web gateway) “logs users in” by passing a special header that says who the user is. The problem is that, in the vulnerable Docker default, Gitea trusts those header values even if the request didn’t actually come through your reverse proxy. It’s like leaving a sign-in passcode door unlocked: someone can walk up and claim to be any user they want just by changing the header they send.

This matters to you if you run Gitea Open Source Git Server using the Docker image and you’ve enabled reverse-proxy authentication headers (for example, X-WEBAUTH-USER). It’s an internet-reachable risk because the vulnerable default trusts all proxy addresses, so any remote attacker can spoof the user identity. The reachability gate is: only a risk if reverse-proxy authentication headers are enabled AND the setup trusts all proxies by default (REVERSE_PROXY_TRUSTED_PROXIES=*).

This is RED because attackers have been reported probing for this exact weakness soon after disclosure, and the flaw enables impersonation without any login. If your configuration matches the vulnerable default (trusting all proxies) and reverse-proxy login headers are enabled, you should treat it as an emergency fix. Do not wait for a perfect moment—make configuration safe and upgrade as soon as you can.

1. Confirm exposure

• In your Gitea Docker deployment, identify whether you use reverse-proxy authentication headers (commonly X-WEBAUTH-USER or similar) to establish who the user is.
• Check how Gitea is configured for reverse-proxy trust. You are specifically looking for the Docker default that trusts all proxies: REVERSE_PROXY_TRUSTED_PROXIES=*. If you see this default (or an equivalent “trust all” setting), your deployment matches the core conditions.

2. Validate whether the vulnerable default is in effect

• If your deployment explicitly sets REVERSE_PROXY_TRUSTED_PROXIES=* (or does not override it and is using the Docker image behavior described up to and including 1.26.2), treat it as vulnerable.
• The vulnerable Docker behavior described applies to Gitea Docker image versions up to and including 1.26.2.

3. Remediate (priority order)

• Priority A (immediate containment): Restrict trusted proxies.

  • Update configuration so Gitea trusts only your real reverse proxy’s IP(s) or hostname, instead of “all IP addresses.”
  • This prevents remote clients from spoofing header-based identity.

• Priority B (permanent fix): Upgrade to a patched release.

  • Upgrade your Gitea Docker image to a version that includes the fix referenced in go-gitea/gitea pull/38151.
  • Because no clean fixed-version string was provided in the findings, use the exact fixed tag/version shown on the Gitea vendor release page.

4. If patching is delayed (temporary workaround)

• Disable reverse-proxy login headers temporarily (or configure the reverse proxy to strip/overwrite the identity headers before requests reach Gitea).
• The goal is to ensure Gitea never receives attacker-controlled values for identity headers.

5. What to monitor after changes

• Review your reverse proxy and Gitea access logs for suspicious header values and unexpected user impersonation attempts.
• Look for abnormal sign-in/session activity (e.g., unexpected access to admin accounts) and changes to repositories shortly after suspicious requests.

6. KEV due date

• No CISA KEV entry was listed for this CVE, so no KEV-specific due date applies based on the provided findings.

Severity/priority: RED. Mechanism: CWE-284 (Improper Access Control / Trust of Untrusted Data via spoofable headers). Attack vector: network; no authentication and no user interaction required.

What’s happening: The Gitea Docker image trusts reverse-proxy identity headers by default (REVERSE_PROXY_TRUSTED_PROXIES=*), so if reverse-proxy authentication headers like X-WEBAUTH-USER are enabled, a remote attacker can spoof those headers and impersonate users.

Exploitation status: The findings report exploitation attempts are occurring in the wild (news says threat actors probed within 13 days of disclosure). No public exploit code is on record.

EPSS: a prediction was provided (0.8%, flat trend), but the findings indicate real-world activity; therefore EPSS should not be used to downplay urgency.

KEV: not listed in CISA KEV.

Patch state: a fix is referenced via go-gitea/gitea pull/38151, but no clean fixed-version string was provided in the findings; confirm the exact patched Docker image tag/version from the vendor release notes.