Skip to main content
← Vulnerabilities

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.

Published
Last modified
Published
Not listed in CISA KEV
5/100 · provisional
Specific setups only
Fix
Fixed in 28.3.0
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.0
  • Upgrade to a fixed version: 28.3.0.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • gitea.dev

    From 1.19.0 · fixed in 28.3.0

Evidence 5

  1. Advisory
  2. Patch
  3. Patch
  4. Repository
  5. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

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