CVE-2026-71206 — Shiori: JWT CheckToken Never Re-Validates Account State

Product: go-shiori/shiori File: internal/domains/auth.go CWE: CWE-613 — Insufficient Session Expiration CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L — 8.2 (High) CNA: Turan Security · CVE record

Description

Shiori's CheckToken function (internal/domains/auth.go) validates only the JWT's HMAC signature and returns the embedded claims.Account object unmodified — it never re-fetches the account from the database on each request. No session store or token-revocation mechanism exists anywhere in the codebase.

Impact

Once a JWT is issued, it remains fully valid for its entire lifetime regardless of what happens to the account afterward. If an admin deletes a user, demotes them, or the user's password is rotated after a suspected compromise, any JWT issued to that account before the change continues to authenticate successfully with the original claims (role, account ID, etc.) baked into the token — there is no server-side state to invalidate it.

Reproduction

1. Authenticate as a user and capture the issued JWT (e.g. via POST /api/v1/auth/login).
2. As an admin, delete the account or demote the user's role.
3. Replay the original JWT against any authenticated endpoint:
   root@kitploit:~

   GET /api/bookmarks
   Authorization: Bearer <original JWT>
   

4. The request succeeds using the stale claims — the deleted/demoted account still has access, because CheckToken never checks current DB state, only the signature.

Root Cause

CheckToken trusts the JWT payload as the source of truth for account state instead of treating it as a bearer credential to be re-validated against the database (or checked against a revocation list) on each use.

Fix Recommendation

Re-fetch the account by ID on every authenticated request (or at minimum check against a revocation/session store keyed by a token ID (jti) that's invalidated on account deletion, demotion, or password change) rather than trusting the embedded claims verbatim.