CVE-2026-109553
7.5HighPublished 18 Oct 2026 · NVD status: Awaiting Analysis · AI triage by gemini-3.8-flash
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- Low
- User interaction
- None
- Impact
- Full C/I/A compromise
- Weakness
- —
Impact
Authenticated users or valid SSH certificate holders can impersonate any other user across the built-in SSH server and HTTP signature API. Attackers need a valid account or a certificate signed by the trusted CA to register another user's public key as their principal.
Root cause
Gitea resolved SSH certificate principals by matching against all stored public keys instead of restricting lookups to dedicated principal keys.
Affected systems
Gitea versions prior to 28.2.0 configured with SSH_TRUSTED_USER_CA_KEYS and SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything.
CVSS v3.1 · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Fix & remediation
Upgrade to Gitea 28.2.0 or newer. As an interim workaround, unset SSH_TRUSTED_USER_CA_KEYS or change SSH_AUTHORIZED_PRINCIPALS_ALLOW away from 'anything' in app.ini.
AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
Gitea resolved the principals of an SSH certificate by searching the content of all stored public keys instead of only principal keys. When Gitea trusts a user certificate authority (`SSH_TRUSTED_USER_CA_KEYS`) and accepts arbitrary principals (`SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything`), a user could register another user's public key line as their own principal, or a holder of a certificate signed by that authority could list it, and then authenticate as the owner of that key through the HTTP signature API and the built-in SSH server. Instances that do not trust a user certificate authority are not affected.