Inside CVE-2026-73800: How a Penti Researcher Helped Uncover a Secret-Stealing Flaw in Gitea Actions

Every serious vulnerability starts as a hunch. For our researcher chakradhar1228, this one began with a question offensive security people ask about any CI/CD system: what happens when untrusted code from a stranger's fork gets to run against a repository that holds real secrets? Chasing that thread through Gitea, the popular self-hosted Git service, led to CVE-2026-73800, a high-severity flaw that lets a single pull request walk out the door with a repository's, and even an organization's, CI/CD secrets. It was reported responsibly and fixed in Gitea 1.27.2. Here is how the story unfolds.

At a glance

• CVE: CVE-2026-73800 (GHSA-r9ch-mqjm-g67v)
• Title: Secret Exfiltration via Reusable Workflow Resolution in pull_request_target Events
• Severity: High (CVSS 8.8, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
• Weakness: CWE-94 (Code Injection) and CWE-829 (Inclusion of Functionality from an Untrusted Control Sphere)
• Affected: Gitea >= 1.19.0
• Fixed in: Gitea 1.27.2

The setup: a trigger built for trust

To understand the bug, you have to understand the stage it plays out on. Gitea Actions, Gitea's built-in CI/CD engine, mirrors GitHub Actions, including a special trigger called pull_request_target. Most triggers treat a fork's code as suspect. This one is different: it runs in the context of the base repository, which means it can reach that repository's secrets even when the pull request came from a fork owned by someone you have never met. It is a powerful, deliberately trusting mechanism, and platforms guard it carefully by running it against the base branch rather than whatever a contributor pushed to their fork.

The twist: one place the guard forgot to look

Gitea did most of the guarding correctly. When a pull_request_target run starts, it overrides github.sha and github.ref so everything evaluates against the trusted base branch commit, not the fork. On the surface, everything looked locked down. The twist chakradhar1228 found was a single blind spot: that same override was never applied when Gitea went to resolve a local reusable workflow.

So a workflow that pulled in a helper with a local path like uses: ./.gitea/workflows/build.yaml quietly fetched that helper from the fork's HEAD commit, the attacker's code, instead of the base branch. The main workflow was trusted. The reusable workflow it called in was not. And because it all executed inside the privileged pull_request_target context, an attacker could write whatever steps they liked into that helper and watch them run with full access to repository and organization secrets. Reading those secrets and mailing them to an endpoint of the attacker's choosing is the easy part.

Why the ending matters

CI/CD secrets are the crown jewels of a modern software supply chain. One leaked deployment token, cloud credential, or signing key can turn a throwaway pull request into full control of production. That is what makes CVE-2026-73800 so uncomfortable: with a CVSS score of 8.8 and an attack that needs nothing more than the ability to open a pull request, the barrier to entry is almost zero. And it is precisely the kind of flaw automated scanners walk right past, because it does not live in a suspicious string. It lives in the logic of how trusted and untrusted code are told apart.

Are you in this story?

If you run a self-hosted Gitea instance on 1.19.0 or later with Actions turned on, you may be exposed, especially if you use pull_request_target workflows that call local reusable workflows and you accept pull requests from forks.

How it ends well

The happy ending ships in Gitea 1.27.2, which makes reusable workflow sources for pull_request_target runs resolve from the base branch commit, closing the gap. To get there safely:

• Upgrade to Gitea 1.27.2 or later. This is the complete fix.
• As an interim mitigation, avoid pull_request_target workflows that call local (./) reusable workflows.
• Restrict the secrets available to workflows triggered by fork pull requests, and review who can open PRs against sensitive repositories.
• Audit your Actions history for unexpected reusable-workflow executions on fork pull requests.

The takeaway

This vulnerability was disclosed responsibly to the Gitea security team and patched before it ever became public, and Penti's chakradhar1228 is among the credited reporters. You can read the official advisory here: GHSA-r9ch-mqjm-g67v.

The moral of the story is the one offensive researchers keep relearning: the vulnerabilities that hurt the most rarely announce themselves. They hide in the seams, in trust boundaries, context overrides, and the quiet assumptions between systems, where pattern-matching tools have nothing to say. That is exactly where Penti's agentic pentesting, backed by human validation, goes looking.