Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2026-71206-PoC — PoC: Shiori JWT CheckToken nunca revalida o estado da conta (CVE-2026-71206, Alta 8.2) | Kitploit
Ferramentas/GitHubGitHub/nel-droid/cve-2026-71206-poc
Autenticação e AutorizaçãoAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebSegurança WebAutenticação
GitHubnel-droid/cve-2026-71206-poc

CVE-2026-71206-PoC

PoC: Shiori JWT CheckToken nunca revalida o estado da conta (CVE-2026-71206, Alta 8.2)

Ver Repositório
há 3 diasAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

CVE-2026-71206 — Shiori: o CheckToken do JWT nunca revalida o estado da conta

Produto: go-shiori/shiori Arquivo: internal/domains/auth.go CWE: CWE-613 — Expiração de sessão insuficiente CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L — 8.2 (Alto) CNA: Turan Security · registro CVE

Descrição

A função CheckToken do Shiori (internal/domains/auth.go) valida apenas a assinatura HMAC do JWT e retorna o objeto claims.Account embutido inalterado — ela nunca busca novamente a conta no banco de dados a cada requisição. Não existe armazenamento de sessão nem mecanismo de revogação de token em lugar algum do código.

Impacto

Uma vez que um JWT é emitido, ele permanece totalmente válido durante toda a sua vida útil, independentemente do que acontecer com a conta depois. Se um administrador excluir um usuário, rebaixá-lo, ou a senha do usuário for alterada após uma suspeita de comprometimento, qualquer JWT emitido para essa conta antes da alteração continua autenticando com sucesso com as claims originais (função, ID da conta etc.) embutidas no token — não há estado no servidor para invalidá-lo.

Reprodução

  1. Autentique-se como um usuário e capture o JWT emitido (por exemplo, via POST /api/v1/auth/login).
  2. Como administrador, exclua a conta ou rebaixe a função do usuário.
  3. Reproduza o JWT original em qualquer endpoint autenticado:
    root@kitploit:~
    GET /api/bookmarks
    Authorization: Bearer <original JWT>
    
  4. A requisição é bem-sucedida usando as claims obsoletas — a conta excluída/rebaixada ainda tem acesso, porque CheckToken nunca verifica o estado atual do banco de dados, apenas a assinatura.

Causa raiz

CheckToken confia no payload do JWT como fonte de verdade para o estado da conta, em vez de tratá-lo como uma credencial bearer a ser revalidada contra o banco de dados (ou verificada em uma lista de revogação) a cada uso.

Correção recomendada

Busque novamente a conta pelo ID em cada requisição autenticada (ou, no mínimo, verifique um armazenamento de revogação/sessão indexado por um ID de token (jti) que seja invalidado na exclusão da conta, rebaixamento ou alteração de senha), em vez de confiar literalmente nas claims embutidas.

Baixar ferramenta