fastjson-check

Um único comando para descobrir se o seu aplicativo Java realmente tem fastjson, onde ele está escondido e se é afetado pela CVE-2026-16723.

Zero dependências · Totalmente offline · Um único jar de 23KB · Compatível com Java 8+

English | Download

---

Por que você precisa disso

Em 21 de julho de 2026, o fastjson oficial divulgou a CVE-2026-16723 (CVSS 9.0, execução remota de código):

• Afeta fastjson 1.2.68 ~ 1.2.83
• Explorável com a configuração padrão — não é necessário habilitar AutoType, nem gadget no classpath, nem autenticação
• A exploração na natureza apareceu em poucos dias após o anúncio, visando principalmente implantações Spring Boot fat-JAR

⚠️ O patch oficial 1.2.84 já foi lançado, mas quase ninguém sabe

Muitos avisos de segurança (incluindo vários veículos de segurança em inglês) ainda afirmam que "o 1.x está EOL, nunca haverá patch, só resta migrar para o fastjson2". Essa afirmação deixou de ser verdadeira a partir de 2026-07-29. Verifique você mesmo:

Evidência	Link
O Maven Central possui com.alibaba:fastjson:1.2.84, jar enviado em 2026-07-29	repo1
GitHub release 1.2.84, publicado em 2026-07-29T08:24:51Z	release
Commit chave fix: strengthen autoType type name validation and whitelist verification	2026-07-29T07:02:55Z

O 1.2.83 foi lançado em maio de 2022, e desde então o branch 1.x ficou quatro anos sem commits — o 1.2.84 foi lançado como exceção especialmente para esta vulnerabilidade.

O título do release não indica correção de segurança: o título do 1.2.83 dizia "（correção de segurança）", enquanto o 1.2.84 diz apenas "Lançamento da versão 1.2.84". Mas o corpo do texto menciona — há uma seção completa de Security Fixes, listando item por item quatro reforços de AutoType, e assim está desde o dia do lançamento (2026-07-29) (verificável no arquivo Wayback 20260729094935).

Quanto a por que a maioria dos avisos de segurança e scanners ainda não acompanhou após o lançamento do patch, não consegui apurar, então não farei suposições aqui.

📌 Correção em 2026-08-14: aqui estava escrito "o texto completo não menciona segurança, portanto não foi acompanhado". A primeira metade foi verificada como incorreta com base no corpo do release e no arquivo Wayback do mesmo dia (apenas o título não indicava), e a segunda metade, portanto, perdeu sua base, sendo também removida.

👉 Impacto prático para usuários do 1.x: atualizar para 1.2.84 é a medida de menor custo (mesmo branch de versão menor, geralmente sem necessidade de alterar código), sem ser forçado a fazer imediatamente a grande migração de versão para o fastjson2. Esta ferramenta já fornece essa recomendação.

⚠️ Pré-requisito é JDK 8 ou superior (testado em 2026-10-14): as 274 classes do 1.2.84 são todas bytecode Java 8 (major 52), enquanto o 1.2.83 é Java 5 (major 49). No JDK 7 (Zulu 7u352), o javac apenas emite avisos e retorna código de saída 0, mas em tempo de execução lança diretamente UnsupportedClassVersionError: com/alibaba/fastjson/JSON : Unsupported major.minor version 52.0. Além disso: a constante JSON.VERSION no 1.2.84 ainda é "1.2.83", então julgar a versão por ela levará a erro; esta ferramenta lê o pom.properties, não sendo afetada.

E o ponto mais problemático é:

O fastjson geralmente é uma dependência transitiva — ninguém o instala ativamente, ele vem junto com outras bibliotecas. Muitas equipes nem sabem que o estão usando.

O mvn dependency:tree consegue listar dependências, mas é impotente em duas situações:

1. Você tem apenas um fat-JAR já empacotado, sem código-fonte e ambiente de build (o cenário mais comum em resposta a incidentes em produção)
2. O fastjson foi shadeado dentro do jar de algum SDK, e não aparece na árvore de dependências

Esta ferramenta foi escrita para essas duas situações.

Início rápido

Baixe o fastjson-check.jar em Releases e então:

# 扫一个 jar（Spring Boot fat-JAR 会自动逐层展开）
java -jar fastjson-check.jar ./myapp.jar

# 扫一整个目录（递归查找所有 jar/war）
java -jar fastjson-check.jar /opt/apps

# 输出 JSON，接入流水线
java -jar fastjson-check.jar /opt/apps --json

Não requer instalação, não requer conta, não usa rede, não envia nenhum dado.

Executar como plugin Maven (a partir da 0.3.0)

O mesmo artefato é tanto CLI quanto plugin Maven. Esse uso não requer baixar o jar primeiro:

# 在你的项目目录下直接跑，扫的是 Maven 解析后的依赖
mvn io.github.xiaoqimikko:fastjson-check:0.3.1:check

Ou vincule ao ciclo de vida de build (fase verify):

<plugin>
  <groupId>io.github.xiaoqimikko</groupId>
  <artifactId>fastjson-check</artifactId>
  <version>0.3.1</version>
  <executions>
    <execution>
      <goals><goal>check</goal></goals>
    </execution>
  </executions>
</plugin>

Por que o modo plugin é mais preciso do que deixar o CLI escanear o pom.xml

Quando o CLI escaneia o pom.xml, o que ele lê é texto, e em projetos reais a versão do fastjson frequentemente não está nesse trecho de texto:

• Escrita como propriedade: <version>${fastjson.version}</version>
• Herdada de <parent>, e no seu próprio pom não existe essa linha
• O caso mais comum: ela é uma dependência transitiva trazida por outra biblioteca, e o seu pom nunca mencionou o fastjson

O plugin recebe o conjunto de dependências do Maven após a resolução, e cada dependência traz o caminho real do jar no repositório local. Assim, ele segue exatamente o caminho em que esta ferramenta é mais competente: escanear o com/alibaba/fastjson(2)/JSON.class dentro do jar real, em vez de confiar no que está escrito no pom.

⚠️ Mas os limites de identificação não mudaram por causa disso: a chave de decisão continua sendo aquele caminho de class, portanto dependências que sofreram relocate / foram reempacotadas com nome de pacote alterado continuam não sendo identificadas (veja «O que ele não é» abaixo). O plugin resolve «onde a versão está escrita», não «o nome do pacote foi alterado».

Parâmetros

Parâmetro	Padrão	Descrição
-Dfastjson-check.failOnFound	false	Faz a build falhar quando CRITICAL / HIGH for encontrado
-Dfastjson-check.path	não definido	Não escaneia a árvore de dependências, escaneia este caminho em vez disso (diretório / jar / war / fat-jar)
-Dfastjson-check.skip	false	Pula a execução

🔴 Por padrão, não deixa o build falhar, e isso é intencional, diferente da semântica do código de saída do CLI: na linha de comando é você quem digita, e o código de saída 1 é exatamente o que você quer; já o plugin fica pendurado no pipeline, e uma ferramenta de autoverificação não deveria deixar o build vermelho quando você não está preparado. Para usá-lo como gate de CI, adicione explicitamente -Dfastjson-check.failOnFound=true.

💡 No Windows, se o relatório aparecer com caracteres corrompidos, mude o console de volta para GBK (chcp 936) — a codificação de saída do modo plugin é determinada pelo Maven, e as opções --utf8 / --gbk do CLI não alcançam aqui.

A saída é assim

fastjson-check 0.1.0  —— fastjson 应急排查（离线，不外传任何数据）

扫描目标：myapp.jar
已展开归档：3 个

发现 2 处 fastjson：