CVE-2026-70400

Executive Summary

CVE-2026-70400 is an authorization-scope bypass in the Gitea repository migration API. A delegated token that is restricted to public-resource operations can be used to create a private repository and an associated migration task, even though the ordinary private repository-creation route correctly rejects that same token. Any Gitea instance that issues fine-grained or delegated tokens (including organization-scoped automation, CI/CD service accounts, and third-party integrations) is affected; the attacker must already hold a valid but under-privileged token. Impact is limited to integrity and availability at the individual-repository level (CVSS 5.4), with no confidentiality loss, but it allows a low-privilege token holder to expand the blast radius of a compromise by planting private, migration-backed repositories under an authorizing user's account or an organization where that user has sufficient permissions.

Technical Analysis

The vulnerability is a straightforward inconsistent-authorization defect, classified under CWE-863 (Incorrect Authorization). Gitea exposes at least two distinct code paths that can result in the creation of a new repository:

1. The ordinary repository-creation route, which correctly evaluates the scope of the presented token and rejects the request when the token is a public-only token attempting to create a private repository.
2. The repository migration API, which creates a repository and a migration task, and which — per the NVD description — omits the equivalent scope check.

The defect is therefore not a memory-safety issue, not an injection flaw, and not an authentication bypass: the token is valid and the account is authenticated. The failure is purely one of authorization completeness — the same security invariant ("a public-only token may not create private resources") is enforced on one entry point and not on another. This class of bug is frequently introduced when a new feature (here, migration) reuses the underlying "create repository" service logic but implements its own guard clauses, and the new guard set diverges from the original.

Two properties of the flaw are worth emphasizing for defenders:

• It is an inconsistency, not a total absence of control. The NVD text explicitly states the ordinary route does reject the token. That means the correct validation logic exists in the codebase and is presumably reusable — the migration path simply does not call it.
• The privilege boundary crossed is the public/private visibility boundary, combined with a resource-creation side effect. The consequence is not read access to any private data (CVSS confidentiality impact is None), but the ability to create a private repository and a migration task. The integrity impact (Low) covers the unauthorized creation of repository state and the associated migration job; the availability impact (Low) reflects the consumption of migration/worker resources and the creation of persistent state that must be cleaned up.

The CVSS vector — AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L — is consistent with this reading. Attack is network-reachable (AV:N) with no special conditions (AC:L), but requires the attacker to already possess a valid low-privilege token (PR:L), requires no user interaction (UI:N), and is scoped to the vulnerable component (S:U). The combination of C:N/I:L/A:L places this in the moderate band and correctly signals that this is a privilege-scope expansion and persistence problem rather than a data-exfiltration problem.

Note on precision: the NVD description does not name the specific API endpoint path, request parameter, token-scope identifier, or source file involved, and none are asserted here. No public proof-of-concept, Nuclei template, or exploit code exists as of this writing. Any claim about exact request bodies or code symbols would be speculation and is deliberately omitted.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (inconsistent authorization on parallel creation paths) and is bounded strictly by what the NVD description states.

1) Reconnaissance and target identification. The attacker identifies a Gitea instance — typically via its web UI banner or by fingerprinting the HTTP response — and obtains, or already possesses, a delegated token. Realistic sources of such a token include: a CI/CD job that was configured with a public-only (least-privilege) token and whose build logs, environment variables, or artifacts leaked; a third-party integration granted a narrow public-scope token; a low-trust organizational service account; or a token harvested from a compromised developer workstation. The attacker does not need administrative rights and does not need a token that is intended to create private resources — that is precisely the gap being exploited.

2) Triggering the flaw. The attacker calls the Gitea repository migration API, specifying that the requested repository should be created as private. Because the migration code path omits the visibility/scope check that the ordinary creation route performs, the public-only token is accepted rather than rejected. The request is authenticated and well-formed; there is no malformed input, no injection payload, and no crash to observe. In detection terms this looks like a successful, ordinary API call — which is what makes it easy to miss.

3) Payload/execution method. At the vulnerability-class level, the "payload" is simply the migration request itself, carrying (a) the target repository definition and (b) an instruction to create it with private visibility. Gitea then provisions a private repository and enqueues a migration task. If the source for the migration is attacker-controlled, the migration task will fetch and import remote content into the newly created private repository — meaning the attacker can populate the repository they just created. The NVD description does not specify which migration sources or parameters are involved, so no specific field names are asserted here.

4) Post-exploitation impact. The attacker now controls a private repository that exists under either (i) the authorizing user's own account, or (ii) an organization where that user holds the permissions necessary to create repositories — per the description, both outcomes are possible. Nothing about this gives the attacker read access to other private repositories (consistent with C:N). The value to an attacker is instead: a persistent, low-noise foothold in a trusted namespace; a repository that may inherit organization-level trust, webhook configurations, or default automation; a migration task that runs server-side and may reach network resources the attacker cannot reach directly; and a potential staging point for later abuse if any downstream system treats "private repo inside org X" as implicitly trustworthy. Cleanup requires administrators to notice the unexpected private repository and its migration job, which — absent the detections below — may simply look like legitimate activity by the token's owner.

Impact Assessment

Business impact. The direct impact is moderate and bounded: unauthorized creation of private repository state and migration tasks. There is no confidentiality impact, so this is not a data-breach vulnerability in itself. The realistic business consequences are (a) governance and audit failure — private repositories appear in namespaces where policy says the token should have been incapable of creating them; (b) resource abuse — migration workers and storage are consumed, and migration tasks may perform outbound fetches on the server's behalf; (c) erosion of the least-privilege model, since the entire purpose of issuing a public-only token is defeated; and (d) potential secondary exposure if the attacker-controlled repository is later mirrored, indexed, or trusted by downstream tooling.

Affected systems. Gitea instances that (i) run a version containing the affected migration API and (ii) issue delegated or fine-grained tokens with a public-only scope. No affected-version range has been published, so all deployments exposing the migration API should be treated as potentially affected until the vendor clarifies. Self-hosted Gitea is the typical deployment; instances with open registration, publicly reachable APIs, or many third-party integrations have the largest token-leak surface.

Blast radius and scoring rationale. CVSS 5.4 with C:N/I:L/A:L correctly frames this as a moderate-severity authorization defect whose reach is limited to resource creation rather than data disclosure. The PR:L component is important context: this is not an unauthenticated attack, and organizations that strictly control token issuance and rotation face materially lower risk than organizations that hand out broad or long-lived tokens. The absence of any CISA KEV listing and any public exploit code further indicates that opportunistic, mass-exploitation activity is unlikely at this time — the threat model is a motivated actor who has already obtained a token.

Detection Guidance

Detection should focus on the outcome (private repositories created by tokens that should not be able to create them, and migration tasks that should not exist) rather than on request syntax, since the exploiting requests are well-formed and authenticated. The rules below are heuristic starting points: the NVD description does not publish exact endpoint paths or parameter names, so the log-field and path values used are generic examples that must be mapped to your Gitea deployment's actual audit-log schema and API surface before production use.

Sigma Rule

title: Gitea Migration API Used to Create Private Repository with Public-Only Token
id: 7f3c1a92-4b6e-4d21-9c8a-1e5d70400cve
status: experimental
description: Detects repository migration API activity that results in creation of a private repository, the pattern abused by CVE-2026-70400 where a public-only delegated token bypasses the scope check enforced on the ordinary repository-creation route.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-70400
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1078
  - attack.persistence
logsource:
  product: gitea
  service: audit
detection:
  selection_api:
    api_endpoint|contains:
      - '/api/v1/repos/migrate'
      - '/api/v1/repos'
  selection_method:
    http_method: 'POST'
  selection_private:
    private: true
  selection_token:
    token_scope|contains: 'public'
  condition: selection_api and selection_method and selection_private and selection_token
falsepositives:
  - Legitimate migrations performed with correctly scoped (private-capable) tokens
  - Administrative bulk-import tooling using tokens whose scope field contains 'public' as a substring
level: medium

YARA Rule

rule CVE_2026_70400_Gitea_Migration_Authz_Bypass_Artifact
{
    meta:
        description = "Heuristic detection for Gitea repository migration requests that create private repositories, associated with CVE-2026-70400 authorization bypass. Intended for scanning captured HTTP request logs, proxy archives, or forensic artifacts."
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-70400"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $migrate1 = "/api/v1/repos/migrate" ascii wide nocase
        $migrate2 = "repos/migrate" ascii wide nocase
        $priv1    = "\"private\":true" ascii wide nocase
        $priv2    = "\"private\": true" ascii wide nocase
        $priv3    = "private=true" ascii wide nocase
        $auth1    = "Authorization: token" ascii wide nocase
        $auth2    = "Authorization: Bearer" ascii wide nocase

    condition:
        (any of ($migrate*)) and (any of ($priv*)) and (any of ($auth*))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-70400 Gitea Migration API Private Repo Creation Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/v1/repos/migrate"; http.request_body; content:"private"; nocase; http.header; content:"Authorization"; nocase; reference:cve,2026-70400; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-70400; classtype:attempted-user; sid:7040001; rev:1; metadata:created_at 2026_01_01, updated_at 2026_01_01, service http;)

Elastic Detection

sequence by user.name, source.ip with maxspan=30s
  [http where http.request.method == "POST"
     and http.request.uri : "/api/v1/repos*"
     and url.path : "*migrate*"]
  [any where event.category == "web"
     and event.outcome == "success"
     and url.path : "*migrate*"]

Splunk SPL Query

index=gitea sourcetype=gitea:audit OR sourcetype=gitea:http
| eval ep = coalesce(http_uri, request_uri, uri_path, url)
| eval body = coalesce(request_body, http_request_body, body)
| where like(ep, "%/api/v1/repos%") AND match(ep, "(?i)migrate")
| where http_method="POST" OR method="POST"
| where match(body, "(?i)\"?private\"?\s*[:=]\s*true")
| eval token_scope = coalesce(token_scope, scope, token_name)
| where match(lower(coalesce(token_scope,"")), "public")
| stats count min(_time) as first_seen max(_time) as last_seen values(ep) as endpoints values(user) as actor values(src_ip) as source_ip by token_scope
| where count > 0
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="gitea,web,attack,">
  <rule id="704001" level="10">
    <decoded_as>json</decoded_as>
    <field name="api_endpoint">/api/v1/repos</field>
    <field name="http_method">POST</field>
    <regex type="pcre2">"private"\s*:\s*true</regex>
    <description>CVE-2026-70400: Gitea migration API creating a private repository (possible public-only token authorization bypass)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>authorization_bypass,persistence,</group>
  </rule>

  <rule id="704002" level="12">
    <if_sid>704001</if_sid>
    <regex type="pcre2">"scope"[^}]*"public"</regex>
    <description>CVE-2026-70400: Gitea migration API created private repository using a public-only scoped token</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>authorization_bypass,persistence,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, commit, advisory, or affected-version range has been published in the intelligence available for this CVE. The guidance below is therefore preventive and compensating, not a fix.

1) Immediate mitigations (apply now).

• Re-scope and audit tokens. Inventory every delegated, fine-grained, and service token in Gitea. Any token carrying a public-only scope should be assumed capable of this bypass. Rotate or revoke tokens that are not actively required, and shorten expiry on all remaining tokens.
• Restrict the migration surface. If the repository migration API is not operationally required, block it at the reverse proxy or API gateway for all but a small allowlisted set of identities and source addresses. This removes the vulnerable entry point without waiting for a vendor fix.
• Harden token issuance. Stop issuing tokens whose effective privileges exceed their intended purpose. Prefer per-job, short-lived tokens scoped to a single repository where the platform permits, rather than account- or organization-wide tokens.
• Constrain organization repository creation. In organizations where low-trust tokens exist, restrict repository-creation permission in the organization's settings so that the "organization where that user has the necessary permissions" path from the description is unavailable to under-scoped automation accounts.
• Audit for existing abuse. Enumerate all private repositories and migration tasks created by public-scope tokens or unexpected actors. Unexplained private repositories under a user or organization namespace should be treated as potential exploitation and investigated before deletion.

2) Patch/upgrade steps. There is no patch to apply at this time. Monitor the Gitea release notes and security advisories for a fix that adds the missing scope check to the migration path, and for a published affected-version range. When a fix ships, validate it by confirming that a public-only token is rejected on the migration route exactly as it is on the ordinary repository-creation route, then upgrade on a prioritized schedule — instances with many third-party integrations or broadly issued tokens first.

3) Long-term hardening.

• Adopt centralized authorization middleware so that visibility/scoping invariants are defined once and enforced on every code path that mutates repository state, eliminating the class of "parallel path missing a guard" defect.
• Add regression tests that assert scope enforcement on all repository-creation entry points, including migration, import, template, fork, and any future addition.
• Enable and retain Gitea audit logging with token identity and scope captured, and forward it to the SIEM so detections like those above can correlate token scope against the resources created.
• Rate-limit and alert on repository creation and migration task creation, especially by machine identities.
• Treat migration tasks as code execution-adjacent: they perform server-side fetches. Restrict egress from the Gitea host to only the migration sources you actually need.

References

1. NVD — CVE-2026-70400: https://nvd.nist.gov/vuln/detail/CVE-2026-70400
2. CWE-863: Incorrect Authorization — https://cwe.mitre.org/data/definitions/863.html
3. FIRST EPSS — not yet scored for this CVE (no EPSS value is asserted; verify at https://api.first.org/data/v1/epss?cve=CVE-2026-70400)
4. CISA Known Exploited Vulnerabilities Catalog — CVE-2026-70400 is not listed as of this writing; check https://www.cisa.gov/known-exploited-vulnerabilities-catalog
5. Gitea project security advisories — consult the official Gitea release notes and advisory page for the eventual fix and affected-version range (no advisory content for this CVE was available when this report was produced)

Threat actor and exploitation status: no public proof-of-concept, no Nuclei template, no exploit code, and no in-the-wild exploitation or named threat-actor campaign is associated with CVE-2026-70400 in the available intelligence.