O pac4j é amplamente integrado com Spring Security, Apereo CAS, JEE, Vert.x, Play, Dropwizard, entre outros.

🔴 Correção da v0.2.0: a alegação central da v0.1.0 estava errada

A v0.1.0 afirmava que "a base oficial de vulnerabilidades lista apenas 1 pacote, quando na verdade são 5", e por isso reportava como vulneráveis pac4j-oidc / javalin-pac4j / lagom-pac4j / ratpack-pac4j. Isso era um falso positivo. O advisory oficial listar apenas pac4j-jwt está correto.

Base da revisão (duas evidências independentes, ambas reproduzíveis por conta própria):

1. O escopo não é transitivo — no Maven, dependências de escopo test / provided não são repassadas para downstream, o pac4j-jwt não aparece no runtime classpath do consumidor.
2. Reinspeção do artefato real — o pac4j-oidc-6.0.0.jar tem 78 entradas no total, todas sob org/pac4j/oidc/, sem nenhuma classe pac4j-jwt embutida via shade. Nem é repassado, nem é carregado.

Onde estava o erro: a v0.1.0 analisou cada pom individualmente, mas olhou apenas "quem escreveu a coordenada pac4j-jwt", sem olhar o scope — tratando "está escrito no pom" como "o consumidor vai receber".

Se você atualizou o pac4j por causa do relatório da v0.1.0, essa atualização não era necessária (a atualização em si é inofensiva). Só é necessário agir quando existe de fato um pac4j-jwt de versão afetada na sua aplicação.

Por que ainda é necessária uma ferramenta dedicada

Para determinar se há ou não um pac4j-jwt afetado em uma determinada máquina, o mvn dependency:tree falha em dois casos — na máquina de produção só existe um fat-jar já empacotado (sem código-fonte e sem pom); ou ele foi embutido via shade dentro de algum SDK, e nem aparece na árvore de dependências. Esta ferramenta escaneia diretamente o próprio artefato, sem depender do ambiente de build.

Uso

Códigos de saída: 0 = não encontrado afetado · 1 = em dúvida/não determinável · 2 = encontrado afetado. Pode ser plugado diretamente no CI.

Exemplo de saída

A v0.1.0 ainda reportaria aqui uma linha extra [CRITICAL] pac4j-oidc — isso era um falso positivo, removido na v0.2.0, o motivo está na correção no início do documento.

O que ele faz

• Expande recursivamente fat-JARs do Spring Boot (em memória, sem descompactar em disco), rastreando até o caminho aninhado específico
• Identifica casos embutidos via shade no jar hospedeiro — exatamente o tipo que o mvn dependency:tree não consegue detectar
• Rastreia a cadeia de introdução — informa qual artefato arrastou o pac4j-jwt para dentro
• Fornece o veredito e o alvo de atualização concreto conforme os intervalos oficiais

Regras de veredito e limites (leia até o fim antes de usar)

O veredito segue sempre o advisory oficial GHSA-pm7g-w2cf-q238:

Autoverificação: esta ferramenta executa o veredito sobre todas as 147 versões do pac4j-jwt no Maven Central, o número de acertos é 114, coincidindo exatamente com a soma das versões dos três intervalos do advisory oficial (13+33+68). Essa asserção está escrita nos testes (OfficialRangeCrossCheckTest); se não bater, o build falha.

⚠️ Mas é preciso ter clareza sobre o que isso valida: valida que o algoritmo de intervalo de versões está correto, não valida "quais artefatos devem entrar na tabela de veredito" — o falso positivo da v0.1.0 ocorreu justamente neste último ponto, e na época essa autoverificação estava verde. O escopo em que a verificação passa ≠ o escopo em que a conclusão é válida.

Duas limitações que precisam ser esclarecidas

1. Cobre apenas o groupId org.pac4j. Há pesquisas de terceiros afirmando que são 19 artefatos afetados, 1.020 versões, mas a lista completa não foi divulgada. O que esta ferramenta reconstrói de forma independente é a parte dentro do escopo org.pac4j, sem alegar cobertura total. Outros groupIds (como org.apereo.cas do Apereo CAS) não foram incluídos.

2. pac4j-jwt 6.0.0 ~ 6.0.4 é marcado como "em dúvida" e não como "afetado". O oficial afirma que a série 6.x é afetada a partir de 6.0.4.1; já a pesquisa de terceiros afirma que a vulnerabilidade foi introduzida já em 1.9.2 — se isso for verdade, essas 5 versões também deveriam contar. Não verificamos de forma independente a conclusão de terceiros, por isso as marcamos separadamente e recomendamos atualização conservadora, em vez de classificá-las diretamente como críticas.

Por que ser tão conservador: uma regra de veredito errada não é um "falso positivo", é fazer o usuário tomar a ação errada. Preferimos marcar como em dúvida a fixar como conclusão um escopo não verificado.

Build

Feedback

Se encontrar erro de veredito, omissão ou falso positivo, abra uma Issue. Se você puder fornecer coordenadas reproduzíveis do artefato (groupId:artifactId:version), a correção será muito mais rápida.

License

Apache License 2.0

pac4j-check (English)

Offline scanner for CVE-2026-29000 (CVSS 10.0) — including the packages the official advisory does not list.

Single jar, ~24KB, zero runtime dependencies, Java 8+, fully offline, sends nothing anywhere.

The vulnerability

JwtAuthenticator in org.pac4j:pac4j-jwt fails to enforce signature validation on certain encrypted JWT (JWE) processing paths. An attacker holding the server's RSA public key (which is public by design) can craft a JWE-wrapped PlainJWT with arbitrary subject and role claims and authenticate as any user, including administrators — with no credentials.

🔴 v0.2.0 correction: v0.1.0's central claim was wrong

v0.1.0 claimed the official advisory "lists only one package while there are five", and flagged pac4j-oidc / javalin-pac4j / lagom-pac4j / ratpack-pac4j as affected. Those were false positives. The advisory listing only pac4j-jwt is correct.

Two independent lines of evidence, both reproducible:

1. Scope does not propagate — Maven does not pass test / provided dependencies to downstream consumers, so pac4j-jwt never reaches their runtime classpath.
2. Artifact inspection — pac4j-oidc-6.0.0.jar has 78 entries, all under org/pac4j/oidc/, with no shaded pac4j-jwt classes.

Root cause: v0.1.0 did parse every pom, but only looked at who names the coordinate, never at scope — mistaking "declared in a pom" for "reaches the consumer".

If you upgraded pac4j because of a v0.1.0 report, that upgrade was not required (though harmless). Action is only needed when an affected pac4j-jwt is actually present.

Why a dedicated tool

Deciding whether an affected pac4j-jwt is actually on a given machine defeats mvn dependency:tree in two common cases: a production box with only a packaged fat-jar (no sources, no pom), or a copy shaded inside some vendor SDK, invisible to the dependency tree. This tool inspects the artifacts themselves.

Usage

Exit codes: 0 clean · 1 disputed/undetermined · 2 affected.

What it does

• Recursively unpacks Spring Boot fat-JARs in memory (nothing written to disk)
• Detects pac4j-jwt shaded into a host jar — the case mvn dependency:tree cannot see
• Traces the introduction chain, so you know which artifact pulled it in
• Reports a concrete upgrade target

Rules and limitations

Verdicts follow the official advisory GHSA-pm7g-w2cf-q238 exactly:

Cross-check: running the rules over all 147 published pac4j-jwt versions yields 114 affected — exactly matching the advisory's three ranges (13+33+68). This is asserted in OfficialRangeCrossCheckTest; a mismatch fails the build.

Two limitations, stated plainly:

1. Only the org.pac4j groupId is covered. Third-party research reports 19 affected packages across 1,020 versions but has not published the full list. This tool independently reconstructs the org.pac4j portion and does not claim full coverage.
2. pac4j-jwt 6.0.0–6.0.4 are reported as DISPUTED, not AFFECTED. The advisory starts the 6.x range at 6.0.4.1; third-party research states the flaw was introduced as early as 1.9.2. We have not independently verified the latter, so these versions are flagged for human review with a conservative upgrade recommendation rather than asserted as vulnerable.

A wrong verdict is not a "false positive" — it makes people take the wrong action.

License

Apache License 2.0

Precisa de uma investigação mais aprofundada?

Esta ferramenta responde à pergunta "eu fui afetado ou não". As questões abaixo ela não consegue responder, mas posso ajudar:

• Dependências que passaram por shade / relocate, ou cujo artefato de build simplesmente não está disponível
• Determinar se "esta CVE na nossa cadeia de chamadas realmente dispara", e não apenas se a versão foi atingida
• Personalização conforme o seu próprio processo de build ou ambiente de rede interna, integração ao pipeline existente
• Você tem um problema semelhante com outro componente e ainda não existe ferramenta pronta

📮 [email protected] — descreva a situação e em até 24 horas envio uma resposta por escrito de uma página: se é possível fazer, onde está a dificuldade, quanto tempo levaria. Esta etapa é gratuita e você não precisa se comprometer com nada antecipadamente.