Artigo de referência para análise da vulnerabilidade: https://mp.weixin.qq.com/s/_4Tnren1hIBToZvHlaKq8w

📖 Visão geral do projeto

Este projeto monta um ambiente completo de reprodução da vulnerabilidade do fastjson 1.2.83 em torno de CVE-2026-16723:

• demo/ — aplicação Web Spring Boot 2.7.18 vulnerável (com dependência do fastjson 1.2.83), que expõe o endpoint POST /parse e chama diretamente JSON.parse(json);
• exp/ — gerador de jar de sonda maliciosa baseado em ASM (duas variantes: protocolo HTTP / protocolo FILE);
• 环境/ — FatJars de três middlewares pré-compilados (Tomcat / Jetty / Undertow), prontos para uso.

Ideia central da exploração: ao construir um JSON especial com @type apontando para uma URL de jar, o fastjson percorre o ramo de confiança da anotação @JSONType → getResourceAsStream baixa o jar remoto/local → defineClass carrega a classe maliciosa → a inicialização da classe aciona <clinit> → execução arbitrária de comandos (RCE).

🎯 Visão geral da vulnerabilidade

Condições de exploração

1. Código alvo: utiliza JSON.parse(json) ou JSON.parseObject(json) para analisar diretamente entrada não confiável, com fastjson nas versões 1.2.66 ~ 1.2.83 e safeMode não ativado;
2. Forma de execução do alvo: Spring Boot FatJar (iniciado com java -jar, LaunchedURLClassLoader; apenas Spring Boot ≤ 2.7 mantém a capacidade de fallback do Handler do protocolo jar:);
3. JVM do alvo: JDK 8 (com JDK 9+, o defineClass lança ClassFormatError; no máximo, é possível apenas SSRF);
4. Acessibilidade de rede: o alvo consegue acessar a porta HTTP da máquina do atacante (cadeia via protocolo HTTP) ou consegue ler um arquivo jar local (cadeia via protocolo FILE).

🧩 Princípio da vulnerabilidade

O checkAutoType do fastjson entra no ramo de confiança ao encontrar uma classe com anotação @JSONType, ignorando a maior parte das verificações da blacklist e permitindo o carregamento. Este projeto aproveita esse comportamento usando ASM para escrever o bytecode diretamente, gravando um [nome de classe interna ilegal] no this_class do constant pool da classe, alinhando perfeitamente os três nomes:

Estrutura da classe maliciosa:

1. Anotação @JSONType — a chave que abre o ramo de confiança do checkAutoType do fastjson;
2. Construtor padrão <init>()V — garante que o fastjson consiga instanciar a classe normalmente;
3. Bloco de inicialização estática <clinit> — durante a inicialização do carregamento da classe, executa Runtime.exec(new String[]{"/bin/bash", "-c", "<cmd>"}), realizando a execução de comandos.

Nomes de classe ilegais não podem ser escritos com javac; apenas o ASM consegue gravar a URL diretamente no constant pool — é por isso que o gerador deste projeto depende do asm-9.6.jar.

📁 Estrutura do projeto

Endpoint do laboratório

demo/src/main/java/com/example/demo/controller/VulController.java:

🚀 Início rápido

1. Iniciar o laboratório vulnerável

O laboratório deve ser executado em ambiente JDK 8 (consistente com as condições de exploração).

Após a inicialização, o endereço do endpoint é: http://127.0.0.1:8080/parse

💥 Exploração da vulnerabilidade

Método 1: Cadeia via protocolo HTTP (jar:http, recomendado)

① Compilar o gerador

② Gerar o jar de sonda maliciosa

• 19090 — porta HTTP de hospedagem do jar malicioso;
• open -a Calculator — comando a ser executado na máquina alvo (abre a calculadora no macOS; no Linux, use id > /tmp/pwned 2>&1 e verifique se o arquivo foi criado).

Por padrão, o arquivo gerado é x (sem extensão), contendo y.class; o payload é:

③ Hospedar o jar malicioso (serviço HTTP)

Certifique-se de iniciar o python3 -m http.server no diretório onde o arquivo x foi gerado.

④ Enviar o payload ao alvo

⑤ Verificação

O resultado da execução do comando não é refletido na resposta HTTP; é preciso confirmar na máquina alvo:

Método 2: Cadeia via protocolo FILE (jar:file)

Cenário de aplicação: o alvo não consegue acessar a porta HTTP da máquina do atacante (isolamento da rede interna / saída de rede restrita), mas é possível colocar o arquivo jar no sistema de arquivos da máquina alvo.

① Compilar o gerador

② Gerar o jar de sonda no diretório correspondente ao alvo

O gerador calcula a URL jar:file: com base no diretório atual (o separador de diretórios / é substituído por .). Por exemplo, se gerado em /tmp/project/exp, o payload será:

③ Colocar o jar gerado no diretório correspondente da máquina alvo

Envie/copie o arquivo y gerado para o caminho absoluto correspondente ao @type na máquina alvo (por exemplo, /tmp/project/exp/y), mantendo a estrutura de diretórios consistente.

④ Enviar o payload ao alvo

Atenção: o caminho da cadeia via protocolo FILE deve ser exatamente igual ao caminho real do arquivo na máquina alvo; caso contrário, a sondagem de recursos falha e o carregamento não é acionado.

⚙️ Parâmetros dos geradores

GenProbeHttp (cadeia via protocolo HTTP)

GenProbefile (cadeia via protocolo FILE)

Conversão do IP para forma de inteiro

2130706433 é o inteiro sem sinal de 32 bits de 127.0.0.1; escrever como inteiro evita que o . do IP seja corrompido pela lógica de substituição . → / do fastjson. Quando a máquina do atacante não é a máquina local:

🔍 Perguntas frequentes

Erro autoType is not support. jar:http:...

Indica que o jar consegue ser baixado (SSRF confirmado), mas TypeUtils.loadClass retornou null. Praticamente há apenas dois motivos:

1. A classe maliciosa não possui a anotação @JSONType — a sondagem não passa pelo ramo de confiança e nem chega a entrar no loadClass;
2. O nome da classe interna da classe maliciosa não está alinhado com o @type — o nome da classe no defineClass não corresponde à realidade e o carregamento falha.

O gerador deste projeto já resolve esses dois pontos: anotação @JSONType + alinhamento dos três nomes.

Um único jar:http ainda não resulta em RCE?

Se o ClassLoader do alvo não for LaunchedURLClassLoader (por exemplo, execução direta pela IDE, pacote war comum, Spring Boot 3.x), a cadeia jar:http única não alcança RCE; no máximo, apenas SSRF pode ser confirmado.

Por que o JDK 8 é necessário?

O defineClass do JDK 9+ faz uma validação mais rígida de nomes de classe ilegais e lança ClassFormatError, interrompendo a cadeia na fase de carregamento.

🛡 Recomendações de correção

1. Atualize o componente: o fastjson 1.x está descontinuado; recomenda-se migrar para fastjson2 (ou atualizar para uma versão corrigida) e acompanhar os avisos de segurança oficiais;
2. Ative o safeMode: ParserConfig.getGlobalInstance().setSafeMode(true); desativa completamente o autoType;
3. Evite analisar entrada não confiável: não chame JSON.parse(json) / JSON.parseObject(json) diretamente sobre a entrada do usuário; sempre que possível, use JSON.parseObject(json, Xxx.class) especificando explicitamente o tipo alvo;
4. Use lista negra/branca: por meio de ParserConfig.addAccept(...), permita apenas classes confiáveis;
5. Atualize Spring Boot / JDK: usar versões mais recentes de JDK e Spring Boot reduz a superfície de exploração;
6. Minimize a exposição: aplique autenticação nos endpoints expostos à internet e utilize WAF para bloquear payloads suspeitos de @type.

📚 Referências

• GitHub oficial do fastjson: https://github.com/alibaba/fastjson
• Avisos de segurança / informações de vulnerabilidades do fastjson: https://github.com/alibaba/fastjson/wiki/security_update_guidance