Live › vulnerability › CVE-2026-104627
Go to dashboardGitea's OpenID 2.0 account-linking callback accepted assertions that the signed-in user never started, so an attacker-controlled OpenID provider could attach its identity to a victim's account. The attacker could then log in as the victim through OpenID, which skips the local TOTP and WebAuthn checks.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Instances that allow OpenID 2.0 sign-in or linking of OpenID identities to local accounts are exposed, since the flaw sits in the security settings callback. Instances that do not use OpenID can skip it. Whether the default configuration enables OpenID is unknown in the sources.
No product ranges from the sources yet.
gitea --version or the footer of the web UI, and compare against the fixed release in the advisory (unknown in sources).Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
The Gitea OpenID association callback in the security settings accepted a positive OpenID 2.0 assertion without checking that the signed-in user had started the linking. Because OpenID 2.0 allows unsolicited assertions, an attacker-controlled OpenID provider could attach the attacker's identity to the account of a signed-in victim who opened a crafted link, and the attacker could then sign in as the victim through OpenID login, which does not apply the local TOTP or WebAuthn checks. The callback now requires a time-limited state value bound to the user.
This page as .md · .json · in your agent: get_signal("CVE-2026-104627")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.