FlawAtlas
Search the atlas
CVE-2026-56750 Critical

Gitea Remember-Me Token Theft Not Invalidating Attacker Session in gitea.dev

Gitea Remember-Me Token Theft Not Invalidating Attacker Session in gitea.dev

Exploit probability Not scored
Published July 27, 2026
Required by Not available
Last source change July 27, 2026

02 / AFFECTED SOFTWARE

Affected packages

Unknown Unknown

38 explicit affected versions

Go gitea.dev
Go code.gitea.io/gitea

03 / CONNECTIONS

Connected vulnerabilities

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2026-56750

Gitea Remember-Me Token Theft Not Invalidating Attacker Session

View original source
Open Source Vulnerabilities GO-2026-6072

Gitea Remember-Me Token Theft Not Invalidating Attacker Session in gitea.dev

View original source
Open Source Vulnerabilities GHSA-rgv6-xp99-6mgj

The vulnerability is in the Remember-Me (gitea_incredible) token validation logic, specifically when handling a compromised token (hash mismatch). The vulnerable function is this one: https://github.com/go-gitea/gitea/blob/689ace1ce28fd74244b8aa335d9928cdbf6b22f9/services/auth/auth_token.go#L33-L64 ### Affected Endpoint POST `/user/login` (and any endpoint triggering `autoSignIn` via the Remember-Me cookie). ### Description Gitea implements Remember-Me cookies using a split token design (ID:Hash), [citing the Paragonie secure remember-me guide](https://github.com/go-gitea/gitea/blob/689ace1ce28fd74244b8aa335d9928cdbf6b22f9/services/auth/auth_token.go#L21). When a token is used, its Hash is rotated, but the ID remains the same. If an attacker steals a user's Remember-Me token and uses it to authenticate, the attacker is issued a new rotated token (same ID, new Hash). When the legitimate user later attempts to use their original token, Gitea correctly detects a hash mismatch for the given ID. According to the referenced Paragonie specification, this indicates a compromised token, and ALL active remember-me sessions for that user MUST be invalidated. However, Gitea's `CheckAuthToken` function simply returns `ErrAuthTokenInvalidHash`. The calling code (`autoSignIn`) catches this error and deletes the victim's local cookie via `ctx.DeleteSiteCookie`, but fails to delete the compromised token from the database. As a result, the attacker's active session is never invalidated, and the attacker maintains persistent, indefinite access to the victim's account, entirely defeating the purpose of the split-token security design.

View original source

05 / REFERENCES

Further evidence