jackson-check

Ferramenta de autoverificação de 26 avisos de segurança do jackson-databind + jackson-core. Jar único sem dependências, sem conexão à rede.

Ela responde a três perguntas que o Dependabot não consegue responder:

0. Aquela que o Dependabot não catalogou, eu fui afetado? —— Até 2026-10-05, restava apenas uma: CVE-2026-68498 do jackson-core (ver a seção «v0.3.0»).
1. Dessas 26, quantas realmente me afetam? —— Varre seu código-fonte em busca das condições de disparo (@JsonView / tipos polimórficos / correspondência sem distinção de maiúsculas e minúsculas……), reduzindo o ruído de «tenho a versão afetada instalada» para «realmente acionei aquele recurso».
2. Para qual versão eu devo realmente atualizar? —— As versões corrigidas indicadas por cada advisory são inconsistentes entre si; só a interseção item a item dá a resposta.

java -jar jackson-check.jar ./target ./src

🔴 v0.4.0(2026-10-05): a versão "corrige tudo de uma vez" mudou de novo — 2.18.11 / 2.21.7 / 2.22.3 / 3.1.7 / 3.2.3

Em 30-09 e 01-10, a FasterXML publicou mais 4 avisos high (todos 7.5, todos de negação de serviço):

ID	Coordenada	Tema	Condição de disparo
CVE-2026-91776	jackson-databind	Cada type id desconhecido deixa uma entrada no cache durante todo o ciclo de vida do processo; a memória só cresce	@JsonTypeInfo(use = Id.NAME, defaultImpl = …) + o atacante consegue controlar o type id + mapper reutilizado por longo tempo
CVE-2026-91777	jackson-databind	Ao completar definições de referências futuras em ordem inversa, o número de comparações é cerca de N²/2 (N=2000 → 2.003.000 comparações)	Desserializar JSON não confiável em coleções ou Maps com @JsonIdentityInfo
CVE-2026-89425	jackson-core	Um token malformado é concatenado inteiro na mensagem de exceção, sem respeitar maxErrorTokenLength	Apenas o caminho createParser(DataInput); o aviso afirma que nenhuma configuração mitiga
CVE-2026-89407	jackson-core	Retrocesso quadrático na regex de NumberInput.looksLikeValidNumber() (74,4 segundos medidos com 160 mil caracteres)	Vincular uma string do JSON a um campo numérico (comportamento padrão do databind); esse caminho é limitado por maxStringLength (padrão 20 milhões) e não por maxNumberLength (padrão 1000)

As versões corrigidas das duas coordenadas têm o mesmo número: 2.18.11 / 2.21.7 / 2.22.3 / 3.1.7 / 3.2.3 (todas disponíveis no Central; a 89407 na linha 3.2 foi corrigida na 3.2.2, a 89425 exige a 3.2.3, vale a maior).

Portanto, as versões 2.18.10 / 2.21.6 / 2.22.2 / 3.1.6 / 3.2.2 indicadas pelo v0.2.0 / v0.3.0 já não bastam desde 30-09. Os jars de versões antigas não saberão disso — troque para o v0.4.0 e reescaneie.

⚠️ Estes quatro não são pontos cegos do Dependabot: entraram no banco global de vulnerabilidades do GitHub no mesmo dia da publicação, e o Dependabot alertará normalmente. O v0.4.0 apenas os incorpora para manter correta a resposta de "para qual versão devo atualizar".

🔴 Correção simultânea de uma afirmação do v0.2.0: a seção "v0.2.0" abaixo diz que "esses 4 não estão no banco global de vulnerabilidades do GitHub e o Dependabot não os reporta" — isso era válido até 14-09, mas deixou de ser a partir de 2026-09-28 — os quatro já foram incluídos no banco global (reexecução do ASSERT2 do gen_rules.py em 05-10: pontos cegos do lado databind 4 → 0). Agora o único ainda não localizável é o CVE-2026-68498 do jackson-core.

🔴 v0.3.0(2026-09-21): jackson-core é outra coordenada; escanear o databind não o encontra

A tabela de decisão do v0.2.x tinha apenas um artifactId em toda ela: jackson-databind. Assim, os 7 avisos que a FasterXML publicou no repositório jackson-core não eram detectados por este utilitário em nenhum caso — e ele não reportava erro algum por isso, apenas ignorava silenciosamente todos os jackson-core-*.jar. "Não escaneado" e "você está seguro" ficam idênticos no relatório.

O v0.3.0 mudou a granularidade da decisão de advisory × groupId × intervalo para advisory × groupId × artifactId × intervalo, e a decisão, o cálculo de interseção e o "esta coordenada não foi escaneada" passam todos a usar a coordenada completa como chave.

O mais importante — CVE-2026-68498 (high 7.5, 2026-09-12): StreamReadConstraints.maxNameLength (padrão 50 mil caracteres) não tem efeito no caminho de entrada por caracteres. O ReaderBasedJsonParser, ao acumular nomes de propriedades, usa o limite de comprimento de string (padrão 100 milhões, cerca de 2000 vezes maior); a validação real do nome só ocorre depois que toda a chave é lida — e nesse momento cerca de 200MB já foram alocados. Basta uma única chave JSON superlonga; a configuração padrão já é vulnerável.

• Afetados: >= 2.16.0, <= 2.18.9 → 2.18.10 · >= 2.19.0, <= 2.21.5 → 2.21.6 · >= 2.22.0, <= 2.22.1 → 2.22.2 · 3.x (tools.jackson.core) <= 3.1.5 → 3.1.6 · <= 3.2.1 → 3.2.2
• Entrada por bytes não é afetada: o UTF8StreamJsonParser revalida a cada expansão de buffer. Quem faz parsing a partir de byte[] / InputStream não é afetado; apenas quem faz parsing a partir de String / Reader / char[] é afetado.
• Verificação bidirecional por bytecode: a chamada a validateNameLength só existe no ReaderBasedJsonParser da versão corrigida, e não existe na versão vulnerável (reproduzido nas três linhas 2.18.9→2.18.10 · 2.21.5→2.21.6 · 3.1.5→3.1.6).

⚠️ Limites de capacidade da ferramenta, escritos aqui para evitar interpretações erradas: esta ferramenta consegue determinar a versão do jar, mas não consegue determinar a sua forma de chamada — a forma mais comum, readValue(someStringVariable, …), uma varredura textual não consegue distinguir se essa variável é String ou byte[]. Portanto, «condição de disparo não encontrada» não significa que você não é afetado, e é assim que também está impresso no relatório.

🔴 Não leia como «o Dependabot é totalmente cego para o jackson-core»: das 7 entradas do jackson-core, apenas CVE-2026-68498 não é encontrada na base global de vulnerabilidades do GitHub; as outras 6 já estão registradas e o Dependabot alerta normalmente. Esta entrada é reverificada pelo ASSERT-C2 do gen_rules.py a cada nova execução, se o número mudar, a geração é recusada.

v0.2.0(2026-09-14):08-21 / 09-01 foram publicadas mais 4 entradas, que na época não estavam registradas na base global de vulnerabilidades do GitHub

🔴 Esta seção é o registro de 09-14, dois pontos já estão desatualizados (ver «v0.4.0» acima): ① estas 4 entradas foram registradas na base global em 2026-09-28, e o Dependabot agora as reporta; ② a versão de «corrigir tudo de uma vez» já não é 2.18.10 / 2.21.6 / 3.1.6. O texto original é mantido, sem exclusão.

A FasterXML publicou 4 novas entradas na página Security do próprio repositório:

Número	Nível	Tema	Versão corrigida
CVE-2026-68497	high 7.5	Comprimento numérico sem limite ao vincular strings a javax.xml.datatype.Duration / XMLGregorianCalendar → DoS de CPU (basta o mapper padrão)	2.18.10 / 2.21.6 / 2.22.2 / 3.1.6 / 3.2.2
CVE-2026-19032	medium 5.3	A desserialização de java.nio.file.Path não restringe o esquema de URI, podendo acionar qualquer FileSystemProvider registrado	Idem
CVE-2026-83557	medium 5.6	A lista de bloqueio do PolymorphicTypeValidator padrão omite Comparable	Idem
CVE-2026-77310	medium 5.3	CVE-2026-54514 corrigido de forma incompleta: o ramo InetAddress ainda realiza resolução DNS imediatamente	2.18.9 / 2.21.5 / 2.22.1 / 3.1.5 / 3.2.1

Teste item a item: