Attack Chain

1. An administrator configures an OAuth2 authentication source within Gitea, linking it to an external Identity Provider (IdP).
2. A user, e.g., "Alice," signs into Gitea at least once via this OAuth2 source, establishing a link between her local Gitea account and the external IdP.
3. A Gitea administrator subsequently disables Alice's account through the Site Administration panel, setting her IsActive flag to false.
4. Alice attempts to sign in again using the previously linked external IdP, triggering the OAuth2 authentication flow.
5. The Gitea application's /user/oauth2/{source-name}/callback endpoint processes the authentication request.
6. Within the routers/web/auth/oauth.go::handleOAuth2SignIn function, the application reads the user's IsActive flag and, despite it being false, incorrectly sets opts.IsActive = optional.Some(true).
7. The user_service.UpdateUser function is called, which updates Alice's account in the database, effectively re-enabling it without administrative approval.
8. Gitea issues a new authenticated session to Alice, granting her full read and write access to her repositories, organizations, and tokens, bypassing the administrator's disable action.

Impact

This vulnerability allows users to circumvent administrative account disablement, leading to unauthorized access and persistence. In organizations utilizing Gitea, particularly those integrated with Single Sign-On (SSO) systems where account disablement is a critical incident response measure for compromised credentials or employee departures, this flaw completely undermines security protocols. Affected Gitea deployments risk former employees or attackers with compromised external IdP access continuously regaining access, leading to data exfiltration, unauthorized code commits, or other malicious activities, even after an administrator has attempted to revoke access.

Recommendation

• Patch Gitea installations to version 1.26.4 or later immediately to address CVE-2026-58422.
• Review audit logs for UpdateUser actions originating from OAuth callback processes for users previously disabled by an administrator.
• Consider implementing out-of-band monitoring for unexpected account re-activations, especially for accounts marked as disabled.

Attack Chain

Scenario 1: Authenticated Webhook/Migration SSRF

1. Attacker establishes authenticated access to a Gitea instance, either as a regular user or a repository administrator.
2. Attacker navigates to the webhook creation interface or initiates a repository migration.
3. Attacker crafts a malicious URL for the webhook or migration target, specifying an internal host within a CGNAT IP range (e.g., http://100.64.0.2:8080/internal) or an unblocked IPv6 transition prefix.
4. The crafted URL is submitted via Gitea's API for webhook or migration configuration.
5. Gitea's hostmatcher IP filter, due to a flaw in its IsGlobalUnicast() && !IsPrivate() logic, fails to block the CGNAT or IPv6 transition range IP.
6. Gitea initiates an outbound HTTP request to the specified internal CGNAT host.
7. The target internal host's HTTP response, including status, headers, and body (up to 1 MB), is captured by Gitea.
8. Attacker retrieves the stored response from the webhook delivery logs or migration details, gaining insights into internal network services or sensitive data.

Scenario 2: Unauthenticated OpenID SSRF

1. The Gitea instance has OpenID sign-in enabled, which is the default setting prior to initial installation completion (!InstallLock) or explicitly configured afterwards.
2. An unauthenticated attacker sends a specially crafted HTTP POST request to Gitea's /user/login/openid endpoint.
3. The POST request includes an openid parameter with a URL pointing to an internal IP address (e.g., http://192.168.1.100/admin) within the Gitea's network.
4. Gitea's openid-go library, responsible for OpenID discovery, uses http.DefaultClient without any IP filtering or hostmatcher integration.
5. Gitea initiates an outbound HTTP GET request to the internal IP address specified in the openid parameter.
6. The internal service receives the GET request from Gitea, potentially triggering actions, revealing its presence, or exposing information, even if the response is not directly returned to the attacker.

Impact

Successful exploitation of these SSRF vulnerabilities can lead to significant internal network reconnaissance, allowing attackers to discover active hosts, open ports, and running services within the Gitea environment. For the webhook and migration SSRF, sensitive information (up to 1MB of HTTP response data) from internal services can be exfiltrated and viewed by the attacker, potentially revealing API keys, configuration details, or other confidential data. While the OpenID SSRF does not directly exfiltrate data to the attacker, it enables unauthenticated port scanning and interaction with internal services, which can be a precursor to more sophisticated attacks, including lateral movement or exploitation of other internal vulnerabilities. Organizations using Gitea versions 1.26.2 or older are at risk, particularly those with OpenID sign-in enabled or those that allow user-created webhooks and repository migrations.

Recommendation

• Deploy the provided Sigma rule to detect attempts at exploiting the OpenID SSRF vulnerability via webserver logs.
• Patch Gitea instances to the latest available version immediately, as fixes for these SSRF vulnerabilities are expected in subsequent releases.
• Restrict outbound network access from Gitea servers to only necessary external endpoints using firewall rules to mitigate the impact of SSRF, even if internal IP filtering is bypassed.
• If OpenID sign-in is not strictly required, disable it in Gitea's configuration to eliminate the unauthenticated SSRF vector.
• Monitor Gitea's outgoing network connections for attempts to contact internal IP addresses, especially those in CGNAT ranges (e.g., 100.64.0.0/10) or RFC 1918 ranges, which would indicate successful exploitation of the webhook/migration SSRF.

Attack Chain

1. An authenticated user gains access to a Gitea instance.
2. The user navigates to a repository where they have permissions to create or modify a webhook, or initiate a repository migration.
3. The user configures the webhook's target URL (or migration source URL) to point to an IP address within one of the bypassable internal ranges, such as http://168.63.129.16/metadata for Azure metadata, or http://100.64.0.1/internal_api for a Carrier-Grade NAT network.
4. Gitea attempts to deliver the webhook or perform the migration. Its internal host matcher, MatchBuiltinExternal, uses net.IP.IsPrivate() to validate the target IP.
5. Due to the narrow definition of IsPrivate(), the target IP is incorrectly deemed "public" and the connection is allowed.
6. Gitea's server-side process makes an HTTP request to the specified internal resource, bypassing expected network segmentation.
7. The internal resource responds (e.g., with cloud credentials or internal service configuration), and Gitea captures the full HTTP response, including status, headers, and up to 1 MiB of the body.
8. The authenticated user accesses the webhook history UI for the configured webhook, which displays the captured response, effectively exfiltrating data from the internal network.

Impact

Successful exploitation of CVE-2026-22874 grants an authenticated attacker the ability to perform extensive Server-Side Request Forgery (SSRF) attacks against the internal network where the Gitea instance is hosted. This can lead to the compromise of sensitive internal systems and data. Specific impacts include accessing cloud metadata endpoints (e.g., AWS IMDS via NAT64, Azure WireServer), probing and exfiltrating data from internal services operating on Carrier-Grade NAT (100.64.0.0/10) or non-RFC1918 172.x.x.x ranges. The non-blind nature of the SSRF means attackers can read full HTTP response bodies through the webhook history UI, allowing for reconnaissance, sensitive information disclosure, and potential privilege escalation by acquiring credentials or API keys.

Recommendation

• Upgrade Gitea to version 1.26.3 or later immediately to address CVE-2026-22874.
• Review your Gitea server's outbound network connections for anomalous activity to the IP ranges listed in the IOC table, particularly to cloud metadata service IP addresses.
• Implement network egress filtering on the Gitea server to restrict outbound connections to only necessary and explicitly allowed external destinations, blocking all communication to the internal and cloud metadata IP ranges mentioned in this brief.