Gitea Actions job token spoofing of instance-signed commits
Affects Gitea 1.19.0 through 28.2.0 with Actions enabled and email confirmation for registration off, which is the default. Fixed in 28.3.0.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 5/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 28.3.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Gitea, the self-hosted Git service, is affected through its Actions feature, where a workflow job could register a GPG key and email address on the built-in system account and cause commits signed with that key to display as verified and signed by the instance. The impact is limited to misleading signature status shown in repositories and pull requests, since signature enforcement and access controls are not affected.
Read the original description
The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation (the default) the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance in every repository where they appear, including pull requests to repositories the user cannot write to. The impact is limited to the displayed signature status: enforcement such as required signed commits only checks that a signature is verified and is unaffected, and no access is gained. The `/api/v1/user` routes now reject system users.
What to do
Check whether your setup matches what the bug needs.
Actions job token (GITEA_TOKEN) is used to call the /api/v1/user email and GPG key endpoints Default configuration: Actions enabled and email confirmation for registration disabled (REGISTER_EMAIL_CONFIRM = false) Instances that require email confirmation with a working mailer are not affected Affects Gitea versions from 1.19.0 up to and including 28.2.0Upgrade to a fixed version: 28.3.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- gitea.dev
From 1.19.0 · fixed in 28.3.0
Evidence 5
- Advisory
- Patch
- Patch
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-116474
What does this mean?
A regular user who can run one workflow job can use the job token to add an email and a GPG key to their account. Commits signed with their own key then display as signed by the instance and trusted, in every repository where they appear. Only the displayed signature status is affected, and no access is gained.Source: github.com
Am I affected, and how do I check?
Gitea versions 1.19.0 through 28.2.0 are affected in the default configuration, with Actions enabled and REGISTER_EMAIL_CONFIRM set to false. Instances that require email confirmation with a working mailer are not affected. To check, look at the Gitea version on the admin dashboard and the REGISTER_EMAIL_CONFIRM value in the app.ini file.Source: github.com
What should I do about it?
Upgrade Gitea to 28.3.0 or later, which contains the fix. No workaround is listed in the facts.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data