Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
When reverse-proxy auth is enabled, any network client can spoof the trusted header without privileges or interaction, so PR:N/UI:N and full C/I/A; the config precondition affects applicability, not base metrics.
Primary rating from Vendor (Gitea).
CVSS VectorVendor: Gitea
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
2DescriptionCVE.org
Gitea Docker image versions up to and including 1.26.2 use REVERSE_PROXY_TRUSTED_PROXIES=* by default, allowing any source IP to impersonate a user when reverse-proxy authentication headers such as X-WEBAUTH-USER are enabled.
Articles & Coverage 1
AnalysisAI
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any source IP to impersonate arbitrary users because the image ships with REVERSE_PROXY_TRUSTED_PROXIES=* by default. When an operator enables reverse-proxy header authentication (e.g. X-WEBAUTH-USER), the wildcard trust list means Gitea accepts those identity headers from any client rather than only from a trusted front-end proxy, granting full account takeover including administrator access. No public exploit has been identified at time of analysis, and the issue is patched in Gitea 1.26.3.
Technical ContextAI
Gitea is a self-hosted, lightweight Git service written in Go. It supports 'reverse proxy authentication', where a trusted front-end proxy authenticates the user and passes the identity to Gitea via an HTTP header (default X-WEBAUTH-USER). To prevent header spoofing, Gitea gates this trust on REVERSE_PROXY_TRUSTED_PROXIES, which should list only the proxy's IP/CIDR. The CPE cpe:2.3:a:gitea:gitea_open_source_git_server confirms the affected component is the Gitea server itself, but the defect is specific to the container packaging: the official Docker image sets REVERSE_PROXY_TRUSTED_PROXIES=* (trust all sources). The root cause maps to CWE-284 (Improper Access Control) - a security-sensitive trust boundary (which upstreams are allowed to assert identity) is configured permissively by default, so the authentication header ceases to be a controlled channel.
RemediationAI
Vendor-released patch: upgrade to Gitea 1.26.3 (or later, e.g. 1.26.4) per the release notes at https://github.com/go-gitea/gitea/releases/tag/v1.26.3 and https://blog.gitea.com/release-of-1.26.3-and-1.26.4/; the fix landed via https://github.com/go-gitea/gitea/pull/38151 and is described in advisory https://github.com/go-gitea/gitea/security/advisories/GHSA-f75j-4cw6-rmx4. If you cannot upgrade immediately, explicitly set REVERSE_PROXY_TRUSTED_PROXIES to the exact IP or CIDR of your front-end proxy (for example the proxy's internal address) instead of the wildcard *, which restores the intended trust boundary with no functional downside for legitimate proxy traffic. Alternatively, disable reverse-proxy header authentication entirely if it is not required (side effect: users relying on proxy-based SSO lose that login path), and ensure network controls prevent clients from reaching the Gitea container directly, so identity headers can only originate from the trusted proxy.
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. Rated medium severity (CVSS 6.1), this vulne
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access t
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-41614
GHSA-f75j-4cw6-rmx4