CVE-2026-109553: Gitea SSH certificate principal impersonation of other users
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 (SSHTRUSTEDUSERCAKEYS) and accepts arbitrary principals (SSHAUTHORIZEDPRINCIPALSALLOW=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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Only instances that trust a user certificate authority through SSH_TRUSTED_USER_CA_KEYS are affected. The described impersonation path also requires SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything; instances that do not trust a user certificate authority are not affected.
What does an attacker need to impersonate another user?
The attacker must be able to register another user's public-key line as their own principal, or hold a certificate signed by the trusted user certificate authority and list that public-key line as a principal. They can then authenticate as that key's owner through the HTTP signature API and Gitea's built-in SSH server.
What can be done before a fix is applied?
Do not trust a user certificate authority via SSH_TRUSTED_USER_CA_KEYS, since instances without a trusted user CA are not affected. Where operationally possible, avoid accepting arbitrary principals with SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything.