CVE-2026-116474: Signature Bypass

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.

Is your site exposed to CVE-2026-116474?

Run a free security scan — no signup, results in seconds.

EPSS — Exploit Prediction

0.0014

Probability of exploitation

0.03%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

Weakness Type (CWE)

CWE-347 CWE-347

References

Other References

https://blog.gitea.com/release-of-28.3.0/ https://github.com/go-gitea/gitea/pull/39945 https://github.com/go-gitea/gitea/pull/40115 https://github.com/go-gitea/gitea/releases/tag/v28.3.0 https://github.com/go-gitea/gitea/security/advisories/GHSA-mf6p-vqpw-3r7x

Frequently Asked Questions

What is CVE-2026-116474? +

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.

How do I check if I'm vulnerable to CVE-2026-116474? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-46684

DataEase is an open source data visualization and analysis tool. Prior to 2.10.23, DataEase enterprise token handling can let TokenFilter#doFilter() …

CVE-2026-67278

MikroTik RouterOS accepts malformed RSA/PKCS#1 v1.5 signatures during X.509 validation. Because its trust store includes an e=3 root CA, an …

CVE-2026-59639

In Bouncy Castle for Java before 1.85, CMS verifySignatures returns true for SignedData with zero signers. This issue also affects …

CVE-2026-12860

In Bouncy Castle for Java before 1.85, RSA PKCS#1 verification skips last two hash bytes in NULL-omitted path. This issue …

CVE-2026-44720

OpenLearnX is an open-source, decentralized learning and assessment platform. Prior to 2.0.4, a critical authentication vulnerability was identified in OpenLearnX …

CVE-2025-24800

Hyperbridge is a hyper-scalable coprocessor for verifiable, cross-chain interoperability. A critical vulnerability was discovered in the ismp-grandpa crate, that allowed …

CVE-2026-116474