Fastjson 1.2.83 ainda pode desencadear execução remota de código sem gadgets tradicionais mesmo com AutoType=false, já reproduzido em ambientes isolados com JDK 8/17/21/25 + Spring Boot Loader.

Autor e fonte do artigo: GCSA

Resumo

No sistema tradicional de defesa contra vulnerabilidades de desserialização Java, existe amplamente a seguinte crença equivocada: “Desativar o AutoType por padrão é seguro”, “Fixar o segundo parâmetro de parseObject (tipo alvo principal) é seguro”, “Remover todas as dependências de Gadget de desserialização do Classpath local é seguro”. No entanto, os mais recentes avanços em ataque e defesa derrubaram completamente essas ilusões.

A Aliança Global de Segurança Cibernética (GCSA) publica hoje exclusivamente este relatório de insights técnicos. O relatório analisa profundamente a causa raiz subjacente pela qual o Fastjson 1.2.83, mesmo com AutoType=false por padrão, ainda pode desencadear execução remota de código (RCE) sem depender de Gadget tradicionais. Atualmente, essa técnica de exploração foi reproduzida com sucesso em ambientes isolados do JDK 8 / 17 / 21 / 25 e do Spring Boot Loader. Esta vulnerabilidade não é uma “bypass de lista negra seguida pela busca por Gadget local”, mas sim uma inversão direta da lógica de detecção de metadados de classe do próprio Fastjson, transformando-a em um canal para obtenção e autorização de classes remotas maliciosas. A seguir, o texto completo.

Organização emissora: GCSA Global Cybersecurity Alliance

Tipo de relatório: Insights Técnicos Exclusivos / Relatório de Análise Profunda de Vulnerabilidades

Data do relatório: 2026-07-21

Status do relatório: auditoria do código-fonte e reprodução em ambiente isolado concluídas

Número da vulnerabilidade: Número interno de pesquisa FJ-GETRESOURCE-RCE (não corresponde a nenhum CVE público)

Fastjson 1.2.83 ainda pode desencadear execução remota de código sem gadgets tradicionais mesmo com AutoType=false, já reproduzido em ambientes isolados com JDK 8/17/21/25 + Spring Boot Loader. Recomenda-se ativar imediatamente o SafeMode e migrar para o Fastjson 2.x.

1. Resumo executivo

O ParserConfig.checkAutoType do Fastjson 1.2.83 converte o valor @type controlável pelo usuário em um nome de recurso de classe e o passa para getResourceAsStream do ClassLoader atual:

Em um ambiente ClassLoader fat-jar capaz de resolver nomes de recursos URL absolutos, um atacante pode utilizar substituição de pontos para construir URLs http:, jar:http: e jar:file: para baixar uma classe maliciosa com @JSONType da extremidade do ataque. Após detectar essa anotação, o Fastjson chama loadClass e retorna diretamente a classe antes das verificações de classe base perigosa e compatibilidade de tipo alvo. Quando a classe é instanciada e inicializada, pode executar código arbitrário.

Esta exploração não depende de gadgets de desserialização tradicionais já presentes no classpath alvo e ainda pode ser acionada no estado padrão do Fastjson AutoType=false. Fixar o tipo de destino do JSON.parseObject não impede a execução; habilitar o SafeMode pode bloquear o caminho de exploração normal antes do acesso aos recursos.

Este relatório reproduziu o seguinte usando o mesmo payload JSON em um contêiner Linux isolado:

2. Classificação da vulnerabilidade

Não recomenda-se atribuir um CVSS 9.8 unificado com base apenas na versão do componente: o AppClassLoader padrão é um controle negativo; a cadeia completa moderna do JDK ainda depende de um loader capaz de interpretar dois URLs absolutos de JAR e /proc/self/fd. Em aplicações que atendem ao ambiente positivo deste relatório, o impacto da vulnerabilidade é um RCE em rede sem autenticação.

3. Alcance e pré-requisitos

• Confirmação em tempo de execução: Fastjson 1.2.83
• JDK confirmado: 8, 17, 21, 25
• Confirmação do sistema operacional: Linux; macOS também reproduziu JDK 17/21/25 usando /dev/fd
• loader confirmado: Spring Boot 2.7.18 classic loader + JDK 8; Spring Boot 3.2.0 loader + JDK 17/21/25
• Confirmação da API: JSON.parse e JSON.parseObject com tipos superiores fixos

As versões 1.2.68–1.2.83 no descritivo externo são mais apropriadas como intervalo de teste conhecido, em vez de versões de introdução da vulnerabilidade. A verificação do código-fonte indica que o código decisivo de detecção de recursos da classe já existia nas versões 1.2.67 e 1.2.68. Este relatório realizou a validação completa em todos os ambientes de execução JDK apenas para a versão 1.2.83.

1. O atacante pode controlar o JSON enviado ao Fastjson, e o @type na entrada será interpretado.

2. SafeMode não está ativado.

3. O ClassLoader do Fastjson pode resolver o nome de recurso absoluto construído como URL.

4. O processo vítima pode se conectar ao serviço HTTP do atacante.

5. The modern Linux chain requires /proc/self/fd to be readable and the loader to be able to parse it.

jar:file:/proc/self/fd/N!...。

1. O JDK precisa ser capaz de criar um cache temporário remoto JAR normal; isso geralmente significa que o diretório temporário da JVM é gravável.

Os atacantes não precisam de:

• Escrever arquivo no classpath de destino
• Classe de destino pré-instalada com TemplatesImpl, JNDI, C3P0, Commons Collections e outros gadgets
• Ativar Fastjson AutoType
• Controle o segundo parâmetro de JSON.parseObject

4. Análise da causa raiz

Localização do código-fonte:

Código principal:

Esta lógica assume que resource é apenas um caminho classpath comum, mas não restringe seu protocolo, semântica de caminho absoluto ou origem. Para um carregador fat-jar específico, as seguintes entradas se tornarão URLs absolutas após substituição:

Portanto, getResourceAsStream carrega recursos de rede controláveis pelo atacante devido a uma consulta fora dos limites aos metadados locais.

Fastjson usa seu próprio ClassReader ASM para analisar o conteúdo do recurso:

O lado do ataque precisa apenas fazer com que a classe remota tenha a anotação @JSONType do Fastjson para definir jsonType como true. Aqui, é verificado o byte fornecido pelo atacante, e não uma classe já carregada pelo classpath confiável.

Localização do código-fonte:

TypeUtils.loadClass tenta sequencialmente o loader explícito, o loader do contexto da thread e Class.forName. Em um ambiente positivo, o loader do contexto da thread reanalisa o mesmo nome de recurso absoluto, faz o download da classe e executa defineClass.

Localização do código-fonte:

• A verificação da classe base perigosa não será executada
• expectClass.isAssignableFrom(clazz) não será executado
• O tipo de vinculação de dados fixos não pode impedir a execução antes da inicialização da classe

Localização do código-fonte:

A verificação do SafeMode ocorre antes do acesso ao recurso:

5. Detalhes do uso da cadeia

Forma mais curta:

JDK 17+ também completará a requisição de rede, mas rejeitará segmentos de caminho vazios nos nomes internos,

O primeiro elemento do array do payload único:

JDK 17+ posteriormente rejeita o nome interno do jar: http://... na primeira fase, mas o Fastjson continua a analisar o array devido ao sufixo Exception.

Elementos candidatos subsequentes:

O primeiro acerto no log de class-load do JDK 17 é:

• JDK 8 aceita diretamente o jar da primeira fase: http://... class e executa
• Após a execução do comando da classe da primeira fase, é lançado intencionalmente um RuntimeException("stage-one-stop") para impedir que o JDK 8 continue tentando FDs de socket/tubo irrelevantes
• JDK 17+ falha na inicialização da classe devido a um nome inválido na primeira fase, retornando suavemente por meio de Exception para a fase de enumeração FD

6. Ambiente e evidências para reprodução

Expected output:The script will:

• Compile the victim fat jar;
• Gerar JAR de ataque com classe FD dedicada;
• Gerar um payload de matriz JSON;
• Iniciar o serviço HTTP do atacante na rede Docker isolada;
• Iniciar contêineres afetados do JDK 8/17/21/25;
• Verifique cada mapeamento do contêiner para /tmp/fastjson-getresource-rce.

Burp apenas envia JSON para as interfaces vulneráveis que possuem pontos de análise Fastjson; o JAR de ataque ainda precisa ser fornecido pelo serviço HTTP do atacante.

Modelo de solicitação:

Se o aplicativo usar um tipo superior fixo, a matriz pode ser embalada conforme a estrutura do campo, por exemplo:

Este experimento usou JSON.parseObject(json, BoundEnvelope.class) para analisar o pacote acima, e o resultado ainda foi RCE-OK, retornando normalmente BoundEnvelope.

Migre prioritariamente para o Fastjson 2.x em manutenção e revalide todas as configurações de tipos polimórficos, AutoType e modo de compatibilidade. Não substitua apenas o JAR sem realizar testes de regressão.

Configuração do código:

Parâmetros JVM:

Atenção: Se a aplicação registrou o AutoTypeCheckHandler, deve-se auditar ou remover sincronicamente, pois o handler é executado antes da verificação do SafeMode.

• Não envie solicitações não confiáveis diretamente para JSON.parse/JSON.parseObject
• Rejeite qualquer forma de metadados de tipo especial na gateway ou na entrada do aplicativo.
• Apenas fixar tipos Java de nível superior não é uma defesa suficiente, pois objetos aninhados ainda podem processar @type, e o jsonType desta vulnerabilidade retorna cedo para contornar a verificação de compatibilidade.

Interceptar temporariamente solicitações cuja chave JSON, após decodificação, seja igual a @type, e substituir os parâmetros da URL, o corpo da solicitação e os objetos aninhados. Não basta procurar "@type" em texto plano; o lexer do Fastjson decodifica primeiro os nomes dos campos, por exemplo:

As regras WAF só podem ser usadas como mitigação e não substituem a atualização de componentes e o SafeMode.

1. Proibir a JVM da empresa de estabelecer conexões HTTP/HTTPS com endereços externos não necessários.
2. Implemente políticas de rede mínimas para contêineres de aplicativos.
3. Restrinja a exposição ou use um sandbox de contêiner mais rigoroso quando permitido pela compatibilidade.
4. Auditar o tratamento do ClassLoader para nomes de recursos de URL absoluta, rejeitando protocolos como http:, https:, jar:, file:.
5. Monitorar atividades anormais no diretório temporário do JVM com jar_cache*.

8. Sugestões de detecção e IOC

Foque-se nos valores decodificados de @type que contêm:

A ocorrência isolada de Exception não é suficiente para alerta; deve ser analisada em conjunto com o formato do protocolo, @type e candidatos FD consecutivos dentro do array.

• JVM solicita JAR ou .class sem extensão do host anômalo
• 1 a 3 repetições de GET/HEAD ocorreram durante o mesmo pedido de análise
• O caminho da solicitação pode conter /x, /a.class ou caminhos equivalentes definidos pelo atacante

• Criação do diretório temporário JVM jar_cache*
• O processo Java reabre o próprio arquivo através de /proc/self/fd/N
• logs de class-load aparecem semelhantes a:

9. Conclusão

Esta vulnerabilidade não é o tradicional “bypass da lista negra e busca de gadgets locais”, mas sim transforma a lógica de detecção de metadados de classe do Fastjson em um canal remoto para obtenção e autorização de classes. O retorno antecipado do @JSONType permite que a classe fornecida pelo atacante seja aceita antes das verificações de classe base perigosa e vinculação de tipo; o canal de falha suave da Exception e o cache temporário do JDK jar:http: expandem os primitivos de carregamento direto do JDK 8 para o JDK 17/21/25.

Portanto, as seguintes suposições comuns não se aplicam:

• "AutoType está desativado por padrão, então é seguro" — não é verdade
• “Fixar o segundo parâmetro de parseObject, portanto seguro” — não é válido
• "O classpath não tem gadgets conhecidos, portanto é seguro" — não é verdade
• “JKD 17+ rejeitará nomes internos com http://, então será apenas SSRF” — incorreto



Em implantações que atendam aos requisitos de carregador verificado, rede e descritores de arquivo, esse problema pode evoluir de um único pedido JSON não autenticado para execução remota de código real. A migração para o Fastjson 2.x deve ser priorizada, e o SafeMode deve ser imediatamente ativado, com os limites de saída da rede e resolução de recursos do ClassLoader reforçados.

10. Caminhos dos anexos e evidências

Direitos autorais e permissão de reprodução: Este relatório e as respectivas análises técnicas são publicados exclusivamente pela GCSA Global Cybersecurity Alliance. Para reprodução, é necessário manter integralmente a fonte oficial da GCSA e o link original, e não alterar de forma maliciosa as ideias centrais do relatório.

Fonte: GCSA Global Cybersecurity Alliance

Site oficial: www.gcsa.org