CVE-2026-71206 in shiori
Summary
by MITRE • 08/05/2026
Shiori's CheckToken function (internal/domains/auth.go) validates only the JWT's HMAC signature and returns the embedded claims.Account object unmodified, never re-fetching the account from the database. No session store or token-revocation mechanism exists in the codebase. Deleting an account or demoting it from owner to a regular role has no effect on tokens already issued to that account — a deleted or demoted owner's token continues authenticating with its original owner-level privileges until natural expiry, which can be up to 30 days with 'remember me' enabled.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability described represents a critical session management flaw in the Shiori application that directly impacts authentication security and privilege enforcement. This issue resides within the CheckToken function located in internal/domains/auth.go, where the system performs only HMAC signature validation of JWT tokens without implementing proper token revocation or account status verification mechanisms. The fundamental design flaw allows attackers to maintain elevated privileges indefinitely through previously issued tokens regardless of account modifications.
This vulnerability constitutes a classic case of insufficient session management as defined by CWE-613 and aligns with ATT&CK technique T1548.003 for abuse of privileges through session management weaknesses. The system fails to implement any form of token revocation or session store that would invalidate previously issued tokens when account status changes occur. The absence of a token revocation mechanism creates a persistent security gap where compromised or revoked credentials continue functioning with their original privilege levels.
The operational impact of this vulnerability extends beyond simple privilege escalation to encompass potential account takeover scenarios and unauthorized access to administrative functions. When an account is deleted or demoted from owner to regular user status, the existing JWT tokens retain their original claims without any verification against current account state. This means that even if a legitimate administrator deletes an account or removes privileges from a compromised account, the attacker can continue operating with full administrative capabilities until the token naturally expires, which can extend up to 30 days when 'remember me' functionality is enabled.
The security implications of this flaw are particularly severe given that it operates as a server-side logic error without any client-side validation or additional authentication layers to compensate for the missing token validation. The system assumes that tokens issued at a certain point in time will remain valid indefinitely, regardless of account modifications or security events occurring after token issuance. This approach violates fundamental security principles of least privilege and immediate privilege revocation, creating an extended window of opportunity for attackers who obtain legitimate tokens.
Mitigation strategies should include implementing a comprehensive token revocation system that tracks issued tokens and invalidates them upon account changes, along with establishing proper session management mechanisms such as token blacklisting or database-backed session stores. The application must fetch current account information from the database during token validation to ensure privilege levels reflect current status rather than cached claims. Additionally, implementing short-lived tokens with refresh mechanisms would significantly reduce the window of opportunity for attackers to exploit this vulnerability while maintaining usability for legitimate users.