CVE-2026-71206 — Shiori: JWT CheckToken nunca vuelve a validar el estado de la cuenta

Producto: go-shiori/shiori Archivo: internal/domains/auth.go CWE: CWE-613 — Expiración de sesión insuficiente CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L — 8.2 (Alta) CNA: Turan Security · registro CVE

Descripción

La función CheckToken de Shiori (internal/domains/auth.go) valida únicamente la firma HMAC del JWT y devuelve el objeto claims.Account incrustado sin modificaciones — nunca vuelve a obtener la cuenta de la base de datos en cada petición. No existe ningún almacén de sesiones ni mecanismo de revocación de tokens en todo el código base.

Impacto

Una vez que se emite un JWT, permanece totalmente válido durante toda su vida útil, independientemente de lo que ocurra después con la cuenta. Si un administrador elimina un usuario, lo degrada de rol, o la contraseña del usuario se rota tras una sospecha de compromiso, cualquier JWT emitido para esa cuenta antes del cambio sigue autenticando correctamente con las claims originales (rol, ID de cuenta, etc.) incrustadas en el token — no hay estado del lado del servidor que pueda invalidarlo.

Reproducción

1. Autentícate como usuario y captura el JWT emitido (p. ej. mediante POST /api/v1/auth/login).
2. Como administrador, elimina la cuenta o degrada el rol del usuario.
3. Reenvía el JWT original contra cualquier endpoint autenticado:
   root@kitploit:~

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

4. La petición tiene éxito usando las claims obsoletas — la cuenta eliminada/degradada todavía tiene acceso, porque CheckToken nunca comprueba el estado actual de la base de datos, solo la firma.

Causa raíz

CheckToken confía en el payload del JWT como fuente de verdad para el estado de la cuenta, en lugar de tratarlo como una credencial de portador (bearer) que debe volver a validarse contra la base de datos (o comprobarse contra una lista de revocación) en cada uso.

Recomendación de corrección

Vuelve a obtener la cuenta por su ID en cada petición autenticada (o, como mínimo, comprueba un almacén de revocación/sesiones cuya clave sea el ID de token (jti) que se invalide al eliminar la cuenta, degradar el rol o cambiar la contraseña) en lugar de confiar en las claims incrustadas tal cual.