Fastjson 1.2.83 aún puede activar la ejecución remota de código sin gadgets tradicionales con AutoType=false por defecto, y se ha reproducido en entornos aislados con JDK 8/17/21/25 + Spring Boot Loader.

Autor y fuente del artículo: GCSA

Resumen

En el sistema de defensa contra vulnerabilidades de deserialización Java tradicional, la industria comúnmente tiene las siguientes ciegas: “Desactivar AutoType por defecto es seguro”, “Fijar el segundo parámetro de parseObject (tipo objetivo principal) es seguro”, “Eliminar todas las dependencias de Gadget de deserialización del Classpath local es seguro”. Sin embargo, los últimos avances en ataque y defensa han desmentido por completo esta mentalidad de complacencia.

La Alianza Global de Ciberseguridad (GCSA) publica hoy exclusivamente este informe de insights técnicos. El informe analiza en profundidad la causa raíz subyacente por la cual Fastjson 1.2.83, incluso con AutoType=false activado por defecto, permite ejecutar código remoto (RCE) sin depender de Gadget tradicionales. Actualmente, esta técnica de explotación ha sido replicada con éxito de extremo a extremo en entornos aislados de JDK 8 / 17 / 21 / 25 y Spring Boot Loader. Esta vulnerabilidad no es una “bypass de lista negra y búsqueda de Gadget local”, sino que convierte directamente la lógica de detección de metadatos de clases de Fastjson en un canal para obtener y autorizar clases remotas maliciosas. A continuación, el texto completo

Organización emisora: GCSA Alianza Global de Ciberseguridad

Tipo de informe: Insight técnico exclusivo / Informe de análisis profundo de vulnerabilidades

Fecha del informe: 2026-07-21

Estado del informe: Auditoría del código fuente y reproducción en entorno aislado completadas

Número de vulnerabilidad: Número de investigación interna FJ-GETRESOURCE-RCE (no corresponde a ningún CVE público)

Fastjson 1.2.83 puede ejecutar código remoto sin necesidad de gadgets tradicionales incluso con AutoType=false, y ya se ha reproducido en entornos aislados de JDK 8/17/21/25 + Spring Boot Loader. Se recomienda activar inmediatamente SafeMode y migrar a Fastjson 2.x.

1. Resumen ejecutivo

El ParserConfig.checkAutoType de Fastjson 1.2.83 convierte el valor @type controlable por el usuario en un nombre de recurso de clase y lo pasa a getResourceAsStream del ClassLoader actual:

En un entorno ClassLoader de fat-jar capaz de resolver nombres de recursos de URL absolutos, un atacante puede utilizar la sustitución de puntos para construir URLs http:, jar:http: y jar:file: y descargar una clase maliciosa con @JSONType desde el lado del atacante. Al detectar esta anotación, Fastjson llama a loadClass y devuelve directamente la clase antes de realizar la verificación de clases base peligrosas y la verificación de compatibilidad de tipo. Cuando la clase se instancia e inicializa, puede ejecutar código arbitrario.

Esta explotación no depende de gadgets de deserialización tradicionales ya presentes en el classpath objetivo y aún puede activarse en el estado predeterminado de Fastjson AutoType=false. Fijar el tipo objetivo de JSON.parseObject no impide la ejecución; habilitar SafeMode puede bloquear la ruta de explotación normal antes del acceso a recursos.

Este informe ha replicado lo siguiente en un contenedor Linux aislado utilizando el mismo payload JSON:

2. Calificación de vulnerabilidad

No se recomienda asignar un CVSS 9.8 uniforme basado únicamente en la versión del componente: el AppClassLoader normal es un control negativo, y la cadena completa moderna de JDK aún depende de un loader capaz de analizar dos URLs absolutas de JAR y /proc/self/fd. En aplicaciones que cumplen con el entorno positivo de este informe, el efecto de la vulnerabilidad es un RCE de red sin autenticación.

3. Alcance e condiciones previas

• Confirmación en tiempo de ejecución: Fastjson 1.2.83
• JDK confirmado: 8, 17, 21, 25
• Sistema operativo confirmado: Linux; macOS también reprodujo 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
• Confirmación de API: JSON.parse, y JSON.parseObject con tipos superiores fijos

Las versiones 1.2.68–1.2.83 en la descripción externa son más adecuadas como rango de prueba conocido, en lugar de como versión de introducción de la vulnerabilidad. La revisión del código fuente indica que el código decisivo de detección de recursos de clase ya existía en las versiones 1.2.67 y 1.2.68. Este informe solo completó la validación completa a través de los entornos de ejecución JDK para la versión 1.2.83.

1. El atacante puede controlar el JSON que se envía a Fastjson, y el @type en la entrada será analizado.

2. SafeMode no está habilitado.

3. El ClassLoader de Fastjson puede resolver el nombre de recurso absoluto construido en una URL.

4. El proceso afectado puede conectarse al servicio HTTP del atacante.

5. Los enlaces modernos de Linux requieren que /proc/self/fd sea legible y que el cargador pueda interpretarlo

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

1. JDK debe poder crear una caché temporal remota JAR normal; esto generalmente significa que el directorio temporal de la JVM es escribible.

Los atacantes no necesitan:

• Escribir archivo en el classpath de destino
• Clase de destino preinstalada con TemplatesImpl, JNDI, C3P0, Commons Collections y otros gadget
• Habilitar Fastjson AutoType
• Controlar el segundo parámetro de JSON.parseObject

4. Análisis de la causa raíz

Ubicación del código fuente:

Código principal:

Esta lógica asume que resource es simplemente una ruta de classpath, pero no restringe su protocolo, semántica de ruta absoluta ni su origen. Para un cargador de fat-jar específico, las siguientes entradas se convertirán en URL absolutas tras la sustitución:

Por lo tanto, getResourceAsStream carga recursos de red controlables por el atacante al superar la consulta de metadatos locales.

Fastjson utiliza su propio ClassReader ASM para analizar el contenido del recurso:

El lado atacante solo necesita hacer que la clase remota tenga la anotación @JSONType de Fastjson para establecer jsonType en true. Aquí se verifica el bytecode proporcionado por el atacante, no una clase ya cargada desde un classpath confiable.

Ubicación del código fuente:

TypeUtils.loadClass intenta secuencialmente el loader explícito, el loader del contexto del hilo y Class.forName. En un entorno positivo, el loader del contexto del hilo vuelve a resolver el mismo nombre de recurso absoluto, descarga la clase y ejecuta defineClass.

Ubicación del código fuente:

• La verificación de la clase base peligrosa no se ejecutará
• expectClass.isAssignableFrom(clazz) no se ejecutará
• El tipo de enlace de datos fijo no puede impedir la ejecución antes de la inicialización de la clase

Ubicación del código fuente:

La verificación de SafeMode se realiza antes del acceso al recurso:

5. Explicación detallada de la cadena

Forma más corta:

JDK 17+ también completará las solicitudes de red, pero rechazará los segmentos de ruta vacíos en los nombres internos,

El primer elemento del array del payload único:

JDK 17+ rechazó posteriormente el nombre interno del jar: http://... , pero Fastjson continuó analizando la matriz debido al sufijo Exception.

Elementos candidatos siguientes:

La primera coincidencia en el registro de carga de clases de JDK 17 es:

• JDK 8 acepta directamente el jar de la fase uno: http://... class y lo ejecuta
• Después de ejecutar el comando de la fase uno, se lanza intencionadamente una RuntimeException("stage-one-stop") para impedir que JDK 8 siga intentando con FD de socket/tubería irrelevantes.
• JDK 17+ falla en la fase uno por un nombre inválido antes de la inicialización de la clase, luego regresa suavemente mediante Exception para entrar en la fase de enumeración FD

6. Entorno y evidencia de reproducción

Expected output:The script will:

• Compilar el fat jar de la víctima;
• Generar un JAR de ataque con clase especial para FD;
• Genera un payload de matriz JSON;
• Iniciar el servicio HTTP del atacante en la red Docker aislada;
• Iniciar contenedores afectados de JDK 8/17/21/25;
• Verifique cada mapa de contenedor en /tmp/fastjson-getresource-rce.

Burp solo se encarga de enviar JSON a las interfaces afectadas que tienen puntos de análisis Fastjson; el JAR de ataque aún debe proporcionarse mediante el servicio HTTP del atacante.

Plantilla de solicitud:

Si la aplicación utiliza un tipo superior fijo, puede envolver el arreglo según la estructura de los campos, por ejemplo:

Esta prueba utiliza JSON.parseObject(json, BoundEnvelope.class) para analizar el envoltorio anterior, y el resultado sigue siendo RCE-OK, devolviendo normalmente BoundEnvelope.

Migre prioritariamente a Fastjson 2.x en mantenimiento y vuelva a validar todas las configuraciones de tipos polimórficos, AutoType y modo de compatibilidad. No solo reemplace el JAR sin realizar pruebas de regresión.

Configuración de código:

Parámetros JVM:

Nota: Si la aplicación registró AutoTypeCheckHandler, debe auditarlo o eliminarlo simultáneamente, ya que el handler se ejecuta antes de la verificación de SafeMode.

• No entregues directamente las solicitudes no confiables a JSON.parse/JSON.parseObject
• Rechazar cualquier tipo de metadatos especiales en la puerta de enlace o entrada de la aplicación
• Solo fijar tipos Java de nivel superior no es una defensa suficiente, ya que los objetos anidados aún pueden procesar @type, y el jsonType de esta vulnerabilidad devuelve antes para omitir la verificación de compatibilidad.

Interceptar temporalmente las solicitudes cuya clave JSON, tras ser decodificada, sea igual a @type, y sobrescribir los parámetros de URL, el cuerpo de la solicitud y los objetos anidados. No basta con buscar el texto plano "@type", ya que el lexer de Fastjson decodifica primero los nombres de los campos, por ejemplo:

Las reglas WAF solo pueden servir como mitigación, no como sustituto de la actualización de componentes y SafeMode.

1. Prohibir que la JVM de la empresa inicie conexiones HTTP/HTTPS a direcciones externas no necesarias.
2. Implementar políticas de red mínimas para contenedores de aplicaciones.
3. Restringir la exposición o el uso de /proc/self/fd cuando sea compatible, o utilizar un entorno de contenedor más estricto.
4. Auditar el tratamiento de nombres de recursos URL absolutos por ClassLoader, rechazando protocolos como http:, https:, jar:, file:, etc.
5. Monitorear actividades anormales en el directorio temporal de JVM con jar_cache*.

8. Recomendaciones de detección y IOC

Enfócate en los valores decodificados de @type que contienen:

Solo aparecer Exception no es suficiente para generar una alerta; debe asociarse con el formato del protocolo, @type y los candidatos FD consecutivos dentro del arreglo para su análisis.

• JVM solicita un archivo JAR o .class sin extensión desde un host anómalo
• Se produjeron 1 a 3 repeticiones de GET/HEAD durante el mismo pedido de análisis.
• En la ruta de solicitud pueden aparecer /x, /a.class o rutas equivalentes definidas por el atacante

• Se crea el directorio temporal JVM con jar_cache*
• El proceso Java vuelve a abrir su propio archivo a través de /proc/self/fd/N
• Los registros de class-load muestran algo similar a:

9. Conclusión

Esta vulnerabilidad no es el tradicional "bypass de la lista negra y búsqueda de gadgets locales", sino que convierte la lógica de detección de metadatos de clase de Fastjson en un canal remoto para obtener clases y autorizarlas. El retorno anticipado de @JSONType permite que la clase proporcionada por el atacante sea aceptada antes de las comprobaciones de clase base peligrosa y enlace de tipo; el canal suave de fallo de Exception y la caché temporal de JDK jar:http: extienden los primitivos de carga directa de JDK 8 a JDK 17/21/25.

Por lo tanto, las siguientes afirmaciones comunes no son válidas:

• “AutoType está desactivado por defecto, por lo que es seguro” — no es cierto
• "Fijar el segundo parámetro de parseObject, por lo tanto es seguro" — no es válido
• "La classpath no tiene gadgets conocidos, por lo tanto es segura" — no es cierto
• “JKD 17+ rechazará los nombres internos con http://, así que máximo sería SSRF” — no es válido



En despliegues que cumplan con los requisitos de loader verificado, red y descriptores de archivo, este problema puede escalarse desde una sola solicitud JSON no autenticada hasta una ejecución remota de código real. Se debe priorizar la migración a Fastjson 2.x y habilitar inmediatamente SafeMode, restringiendo los límites de salida de red y la resolución de recursos de ClassLoader.

10. Rutas de archivos adjuntos y evidencias

Reproducción y derechos de autor: Este informe y su análisis técnico son publicados exclusivamente por la GCSA Global Cybersecurity Alliance. Para reproducirlo, debe conservar integralmente la fuente oficial de la GCSA y el enlace original, y no modificar maliciosamente los puntos clave del informe.

Fuente: GCSA Global Cybersecurity Alliance

Sitio web: www.gcsa.org