CVE-2026-56750: Gitea Remember-Me Token Theft Not Invalidating Attacker Session
The vulnerability is in the Remember-Me (giteaincredible) 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/authtoken.go#L33-L64 Affected Endpoint POST /user/login (and any endpoint triggering autoSignIn via the Remember-Me cookie).
Published Jul 21, 2026
Affected packages
code.gitea.io/gitea
- Ecosystem
- Go
- Affected
- < 1.27.0
- Fixed in
- 1.27.0
- Check
go list -m code.gitea.io/gitea
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
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. 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.
Credited to AdamKorcz.
References
- https://github.com/go-gitea/gitea/security/advisories/GHSA-rgv6-xp99-6mgj
- https://github.com/go-gitea/gitea/pull/38406
- https://github.com/go-gitea/gitea/pull/38426
- https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31
- https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf
- https://github.com/go-gitea/gitea/releases/tag/v1.27.0
- https://github.com/advisories/GHSA-rgv6-xp99-6mgj
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
More Go vulnerabilities
All Go entriesCVE-2026-20896
Gitea Docker image: `REVERSE_PROXY_TRUSTED_PROXIES = *` default lets any source IP impersonate any user via `X-WEBAUTH-USER`
critical9.8Jul 21, 2026CVE-2026-22874
Gitea: Incomplete SSRF Protection in Webhook and Migration Allow-list Default Filter
critical9.6Jul 21, 2026CVE-2026-58426
Gitea Actions Artifacts V4 signed URL HMAC ambiguity allows cross-repository artifact read and cross-task upload-state write
critical9.6Jul 21, 2026CVE-2026-58443
Gitea: Public-only repository tokens can update private PR head branches
critical9.6Jul 21, 2026CVE-2026-22547
Gitea repository creation accepts insufficiently validated fields
critical9.1Jul 3, 2026CVE-2026-25718
Gitea template repository generation follows unsafe filesystem paths
critical9.1Jul 3, 2026
