Gitea CVE-2026-58443: Authorization Bypass in Pull Request Update API Enables Private Repo Access — Threadlinqs Intelligence
As of 2026-07-21, Gitea CVE-2026-58443: Authorization Bypass in Pull Request Update API Enables Private Repo Access is a critical-severity vulnerability threat, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 29 indicators of compromise.
Threat ID: TL-2026-1587 · Severity: CRITICAL · CVSS: 9.6 · Status: ACTIVE · Category: VULNERABILITY
A public-only-scoped Gitea API token can be used against the pull request update endpoint to push commits from a public base repository into a private pull request's head branch, bypassing Gitea's
CVE-2026-58443 (GHSA-xxjv-752h-3vp2) is an Incorrect Authorization vulnerability (CWE-863) in Gitea's pull request update API, `POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update`. Gitea supports 'public-only' access tokens that are supposed to be confined to interacting solely with public repositories and resources. The update endpoint validates the requesting token's public-only restriction against the *public base repository* named in the API route, but fails to re-apply that same restriction when the operation subsequently touches the pull request's *head repository* — which can be a private repository, provided the caller (a human account, not the token itself) already holds normal write permission there through an existing public-base/private-head PR relationship.
Because the authorization check only inspects the base repository's visibility, an attacker holding a public-only token can issue an authenticated API call that pushes new commits onto the private head branch of the pull request, even though the token was never meant to be able to touch private-repository content at all. This is a token-scope confused-deputy flaw: the API borrows the human account's broader write permission on the private repo while the request itself is authenticated with a token that should never have been able to reach it. As one technical writeup summarized it: 'A token that fails when attempting a direct write to a private repository can still modify a private branch through the pull request update function.'
The exploit chain requires: (1) a valid public-only access token with `write:repository` scope, (2) a user account that already holds normal write permission on the private PR head branch, (3) an existing public base repository, and (4) a pull-request relationship permitting base-to-head updates. The attacker stages content in the public base repository, invokes the vulnerable update endpoint targeting the private head branch, and Gitea server-side merges/rebases the public commits into the private branch. If Gitea Actions is enabled with push-triggered workflows on that private repository, the server-side push causes those workflows to execute automatically within the private repository's context — with access to any secrets, deploy credentials, and build artifacts scoped to that workflow. Researchers demonstrated exactly this: an injected commit landing on the private PR head branch via the bypass caused Gitea to start a matching private-repository ActionRun and associated job.
The flaw was reported by security researcher ohxorud-dev and patched by Gitea maintainer bircni via pull request #38406 (co-authored/reviewed by TheFox0x7, techknowlogick, Lunny Xiao, wxiaoguang, and Zettat123, with an automated Copilot AI review covering 84 files), merged 2026-07-12 and released as part of Gitea v1.27.0 (milestone 28.0.0). PR #38406 was a large, coordinated security-hardening PR — 36 commits across 84 files — bundling 46 distinct CVE fixes across four categories: (a) SSRF protections for migration asset/PR-patch fetches, OAuth2 avatar fetches, OpenID discovery, pull-mirror URL re-validation, and outbound proxy path validation (introducing a new `[security].ALLOWED_HOST_LIST` setting that deprecates the old `[webhook].ALLOWED_HOST_LIST`); (b) access-token scope enforcement fixes preventing scope escalation at token creation and confining public-only tokens across feeds, packages, Actions listings, and star/watch lists (CVE-2026-58443 falls in this category); (c) access-control/disclosure fixes blocking go-get default-branch leaks, webhook authorization-header exposure via API, stale watches on private-repo visibility transitions, and cross-repo label/attachment scoping; and (d) DoS mitigations (npm dist-tag bounds, Debian control-file decompression limits, Arch package file-list caps, SSH public-key length validation). Named sibling CVEs from the same v1.27.0 remediation batch include CVE-2026-58433 (team-repository linking endpoint ci
Target sectors: technology, software-development, government administration, finance, health, education
Target regions: Global
Detections & IOCs
As of 2026-07-22, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 29 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
VULNERABILITY, CRITICAL, threat intelligence, cybersecurity, CVE-2026-58443, T1593, T1588.002, T1190, T1199, T1195.002, T1098, T1078, T1548, T1550.001, T1069