# Gitea CVE-2026-58443: Authorization Bypass in Pull Request Update API Enables Private Repo Access

> 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 public/private token confinement. A demonstrated PoC used an injected commit to trigger a private Gitea Actions workflow (ActionRun), proving code-execution-adjacent impact from what is nominally an access-control bug. Fixed in Gitea v1.27.0 (PR #38406); affects all versions up to v1.26.4.

- **Published:** 2026-07-21T00:00:00Z
- **Last reviewed:** 2026-07-21T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1587
- **ID:** TL-2026-1587
- **Severity:** CRITICAL (CVSS 9.6)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 29 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-58443, CVE-2026-58424, CVE-2026-58426

## Description

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 circumvented org settings), CVE-2026-58435 (LFS deploy-key privilege escalation), CVE-2026-58436 (DoS via Accept-Language header parsing), and CVE-2026-59765 (SSRF in migration asset downloads bypassing host validation).

CVE-2026-58443 also sits in a broader 2026 pattern of Gitea authorization/access-control CVEs. An earlier Gitea bulletin (SB2026062240, published 2026-06-22, covering Gitea 0.9.99-1.26.2) catalogued 8 related access-control flaws, several also CWE-863/CWE-284 'incorrect authorization' class bugs (e.g. CVE-2026-27775, 'gain full repository write access'; CVE-2026-20896, CVSS 9.1, 'impersonate arbitrary users' on Docker deployments). Separately, CVE-2026-58424 (CVSS 8.9, CWE-285/CWE-732/CWE-863, fixed in 1.26.3/1.26.4, published 2026-07-03) let attackers bypass permanent-fork pull-request workflow approval gates, and CVE-2026-58426 (CVSS 9.6, CWE-347 HMAC ambiguity, fixed in 1.26.2) allowed cross-repository Gitea Actions Artifacts V4 signed-URL reads and cross-task upload-state writes — both PR-workflow/CI-adjacent authorization flaws in the same subsystem family as CVE-2026-58443, underscoring a recurring class of bugs in Gitea's pull-request/Actions trust boundary. Cyber Security News published a public technical writeup of CVE-2026-58443 specifically on 2026-07-21. As of this writing the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog; exploitability is assessed as proof-of-concept-public rather than confirmed active exploitation in the wild.

## MITRE ATT&CK

- T1593 Search Open Websites/Domains
- T1588.002 Tool
- T1190 Exploit Public-Facing Application
- T1199 Trusted Relationship
- T1195.002 Compromise Software Supply Chain
- T1098 Account Manipulation
- T1078 Valid Accounts
- T1548 Abuse Elevation Control Mechanism
- T1550.001 Application Access Token
- T1069 Permission Groups Discovery
- T1087 Account Discovery
- T1072 Software Deployment Tools
- T1213 Data from Information Repositories
- T1567 Exfiltration Over Web Service
- T1565.001 Stored Data Manipulation

## Sources

- [Gitea Vulnerability Article - CVE-2026-58443](https://cybersecuritynews.com/gitea-vulnerability/)
- [Gitea 1.27.0 is released](https://blog.gitea.com/release-of-1.27.0/)
- [fix: Various security fixes (PR #38406)](https://github.com/go-gitea/gitea/pull/38406)
- [go-gitea/gitea Security Advisories](https://github.com/go-gitea/gitea/security)
- [SB2026062240 - Multiple vulnerabilities in Gitea](https://www.cybersecurity-help.cz/vdb/SB2026062240)
- [High-Severity Gitea Flaws Enable Workflow Bypass and Artifact Access](https://www.mallory.ai/stories/019f2b51-04a6-79ce-8770-2ba9a917d861)
- [Gitea Official Security Page](https://about.gitea.com/security/)
- [GHSA-xxjv-752h-3vp2: Public-only repository tokens could update private pull-request head branches](https://github.com/go-gitea/gitea/security/advisories/GHSA-xxjv-752h-3vp2)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1587