CVE-2026-97208

Executive Summary

CVE-2026-97208 is an authorization bypass in the Gitea REST API endpoint used to create push mirrors (POST /api/v1/repos/{owner}/{repo}/push_mirrors). The endpoint validated only whether mirroring was globally enabled, but failed to enforce the [mirror] DISABLE_NEW_PUSH configuration setting that the Gitea web interface honors, allowing a repository administrator to create push mirrors even when the site administrator had explicitly disabled them. Because a push mirror transmits all refs of a repository to a caller-chosen remote on every commit or on a schedule, successful abuse results in silent exfiltration of repository source code and history to an attacker-controlled destination. Any Gitea instance that has disabled new push mirrors but not the mirroring feature as a whole is potentially affected.

Technical Analysis

The vulnerability is a classic inconsistent-enforcement / missing-authorization-check flaw (CWE-863, Incorrect Authorization). Gitea exposes push mirror functionality that replicates a repository's refs to a remote Git endpoint. Administrators can disable this capability instance-wide through the [mirror] configuration section, specifically the DISABLE_NEW_PUSH directive. The user-facing web interface was written to enforce this directive: a repository administrator interacting with the UI would be blocked from creating a new push mirror when DISABLE_NEW_PUSH was set.

The API surface diverged from the UI. The handler backing POST /api/v1/repos/{owner}/{repo}/push_mirrors performed an authorization check confirming that mirroring was enabled in general, but omitted the second check for [mirror] DISABLE_NEW_PUSH. As a result, the API acted as an alternate, less-restricted code path to the same privileged operation.

Two properties make this serious:

1. Bypass of an administrative control. The site administrator's explicit policy decision to disallow new push mirrors is honored by one interface and ignored by another. Security-relevant configuration is only as strong as its weakest enforcement point.
2. Data-bearing operation. A push mirror is not a read-only metadata action; it causes the repository's refs to be transmitted to an arbitrary remote endpoint chosen by the caller. Creating a mirror is therefore functionally equivalent to establishing a persistent outbound exfiltration channel, refreshed on each commit or per the configured schedule.

The privilege required is repository-administrator level (PR:H), which limits the attacker set to users who already hold elevated rights on a given repository, or an external actor who has compromised such an account. The NVD description does not specify the affected Gitea version range, and no patch commit, advisory, or fixed release has been identified. Technical detail beyond what is stated above (for example, the precise guarding logic in the handler) is not available in the provided data and is not speculated here.

Exploitation Scenarios

No public PoC or exploit code is available; the attack chain below is inferred from the vulnerability class and the endpoint semantics described in the NVD entry.

1. Reconnaissance / target identification. The attacker identifies a reachable Gitea instance, for example through banner-grabbing or fingerprinting the web UI and API. The attacker needs to know that the instance runs with push mirrors disabled as a matter of policy — relevant because the bypass is only meaningful where [mirror] DISABLE_NEW_PUSH is set. Fingerprinting the API version helps the attacker know the endpoint exists.

2. Prerequisite — repository-administrator access. The attacker must hold, or have compromised, an account with administrative rights over at least one repository (an API token or session for such an account). This is the primary control gating the attack; there is no privilege escalation to repository-admin demonstrated in the description, only a bypass of the site-level restriction once that level is reached.

3. Triggering the flaw (vulnerability-class level). With a valid authenticated request, the attacker sends a request to POST /api/v1/repos/{owner}/{repo}/push_mirrors specifying a remote Git destination under their control. The endpoint authorizes the request based solely on mirroring being enabled, and — unlike the web interface — does not reject it on the basis of [mirror] DISABLE_NEW_PUSH. The request therefore succeeds where the UI-based equivalent would have been refused. The precise request body/field names are not provided and are not fabricated here.

4. Execution / channel establishment. Gitea registers the new push mirror. Per the NVD description, a push mirror "pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule." Once the mirror is configured, the replication happens automatically and repeatedly, without further attacker interaction.

5. Post-exploitation impact. All refs of the targeted repository are transmitted to the attacker-selected remote: this includes source code, commit history, branches, and tags. Because mirrors are persistent, the channel continues to synchronize future commits, giving the attacker a standing copy of the repository and any secrets or internal material committed to it. This is data exfiltration and persistent supply-chain foothold rather than code execution.

Impact Assessment

CVE-2026-97208 is a confidentiality and integrity-impacting authorization bypass. Using CVSS 3.1 subscore reasoning against the available description:

• AV:N — reachable over the network via the Gitea API.
• AC:L — the bypass requires no special conditions beyond repository-admin privileges and a valid API request.
• PR:H — requires repository-administrator rights (attacker-supplied or compromised).
• UI:N — no user interaction is required.
• S:U — impacts remain within the Gitea instance and its repositories.
• C:L — confidentiality loss is scoped to the affected repository's refs and history.
• I:H — the integrity of the site-level security configuration is defeated, and repository data is replicated to an unauthorized destination on an ongoing basis.
• A:N — no availability impact described.

Business impact centers on the exfiltration of private source code, commit history, and any embedded secrets (CI credentials, tokens, keys) from repositories on instances whose administrators had explicitly disabled new push mirrors. Because mirroring is persistent and triggered on every commit or on a schedule, discovery does not stop the leak — the mirror must be found and removed. In regulated or multi-tenant environments, a single repository administrator's action can quietly move an organization's most sensitive IP to external infrastructure. The specific affected version set is unknown, so the blast radius across deployments cannot be precisely quantified.

Detection Guidance

Sigma Rule

title: Gitea Push Mirror Creation via API Bypassing DISABLE_NEW_PUSH
id: 9c2f1a44-7b1e-4d63-9f02-cve202697208
status: experimental
description: Detects creation of a push mirror through the Gitea API, which may indicate bypass of the [mirror] DISABLE_NEW_PUSH setting.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-97208
author: valtersit.com
date: 2026/01/01
logsource:
  product: gitea
  service: http
detection:
  selection_method:
    http.method: 'POST'
  selection_endpoint:
    http.url|contains: '/api/v1/repos/'
  selection_path:
    http.url|contains: '/push_mirrors'
  condition: selection_method and selection_endpoint and selection_path
fields:
  - http.url
  - http.method
  - source.ip
  - user.name
level: high
falsepositives:
  - Legitimate push mirror creation by authorized administrators in environments where DISABLE_NEW_PUSH is not set.

YARA Rule

rule CVE_2026_97208_Gitea_Push_Mirror_Abuse
{
    meta:
        description = "Detects Gitea push mirror API abuse requests referencing the push_mirrors endpoint"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-97208"
        author = "valtersit.com"
        date = "2026-01-01"
        cve = "CVE-2026-97208"

    strings:
        $ep   = "/api/v1/repos/"
        $mir  = "/push_mirrors"
        $mthd = "POST"
        $remote1 = "remote_address"
        $remote2 = "push_mirror"

    condition:
        uint16(0) == 0x4854 and any of ($ep, $mir) and all of ($mthd) or (2 of ($ep, $mir, $remote1, $remote2))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-97208 Gitea Push Mirror Creation via API (DISABLE_NEW_PUSH bypass attempt)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/v1/repos/"; http.uri; content:"/push_mirrors"; fast_pattern; classtype:attempted-admin; reference:cve,2026-97208; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-97208; sid:202697208; rev:1;)

Elastic Detection

api where http.request.method == "POST" and
  stringContains(http.request.uri.path, "/api/v1/repos/") and
  stringContains(http.request.uri.path, "/push_mirrors")

Splunk SPL Query

index=gitea sourcetype=gitea:http OR sourcetype=nginx:access
| search http_method=POST
| search uri_path="*/api/v1/repos/*/push_mirrors*"
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, user, uri_path, http_method
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="gitea,web,attack,">
  <rule id="2026970" level="10">
    <decoded_as>json</decoded_as>
    <field name="http.method">POST</field>
    <field name="http.url">/api/v1/repos/</field>
    <field name="http.url">/push_mirrors</field>
    <description>CVE-2026-97208: Possible Gitea push mirror creation via API bypassing DISABLE_NEW_PUSH</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_97208,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations

   • Disable the push-mirror feature at a broader scope than DISABLE_NEW_PUSH where operationally feasible, so that the API path cannot register a mirror at all; the flaw exists because the API enforced only "mirroring enabled," not the new-push restriction.
   • Where possible, restrict network access to /api/v1/repos/{owner}/{repo}/push_mirrors at the reverse proxy / WAF layer for repositories that should not mirror, or block the endpoint entirely until a fix is available.
   • Restrict repository-administrator privileges to a minimal set of trusted accounts, since PR:H is the gate for this attack. Audit all current repository admins and API tokens.
   • Review existing push mirror configurations across repositories and remove any not explicitly authorized by the site administrator.

2. Patch / upgrade steps

   • No vendor patch, fixed version, or advisory has been identified for CVE-2026-97208. Monitor the Gitea project's security advisories and release notes for an update that adds enforcement of [mirror] DISABLE_NEW_PUSH to the POST /api/v1/repos/{owner}/{repo}/push_mirrors handler, and upgrade immediately once available.

3. Long-term hardening

   • Treat security configuration as a contract between the UI and API: enforce authorization consistently across all interfaces, and add regression tests ensuring UI-restricted operations are equally restricted via the API.
   • Apply defense-in-depth for egress: restrict outbound Git/HTTP(S) destinations from the Gitea host so that an unauthorized push mirror cannot reach attacker-controlled remotes.
   • Enable and centralize API audit logging, and alert on push-mirror creation events as shown in the detection rules above.
   • Rotate any secrets, tokens, or keys that may have been present in repositories exposed through unauthorized mirrors.

References

• NVD — CVE-2026-97208: https://nvd.nist.gov/vuln/detail/CVE-2026-97208
• Gitea project security advisories and releases (vendor source of any forthcoming fix): https://github.com/go-gitea/gitea/releases
• Gitea API documentation (endpoint reference for POST /api/v1/repos/{owner}/{repo}/push_mirrors): https://docs.gitea.com/api/
• MITRE ATT&CK — T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• CWE-863 Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html

No exploit-in-the-wild evidence, public PoC, or threat-actor campaign has been identified for CVE-2026-97208. The CVE is not listed in CISA KEV.