Una sola petición JSON puede convertir un servidor Java en territorio del atacante. Esa es la síntesis incómoda de CVE-2026-16723, un fallo crítico de ejecución remota de código (CVSS 9,0) en Fastjson 1.x, la veterana librería de serialización JSON de Alibaba que sigue viva dentro de miles de aplicaciones empresariales. La firma FearsOff lo descubrió y los responsables de Fastjson publicaron el aviso el 21 de julio de 2026. Pocos días después ya se explotaba en Internet contra organizaciones estadounidenses.
Lo que lo vuelve urgente no es solo la puntuación, sino la ausencia de una salida cómoda: Fastjson 1.x ha llegado al final de su vida útil y no habrá parche para esa rama. Firmas como ThreatBook e Imperva confirmaron ataques reales a los pocos días del aviso. Y como Fastjson suele viajar escondida como dependencia transitiva —nadie la instaló a propósito, llegó de la mano de otra librería—, muchos equipos ni siquiera saben que la están ejecutando.
Lo esencial
- CVE-2026-16723 es un fallo de ejecución remota de código en Fastjson 1.x que se dispara al procesar un JSON malicioso, sin autenticación previa.
- Afecta a Fastjson de la 1.2.68 a la 1.2.83 en aplicaciones Spring Boot empaquetadas como JAR ejecutable (fat-JAR), con SafeMode en su valor por defecto: desactivado.
- No hay parche para la rama 1.x. La mitigación inmediata es activar SafeMode; la solución de fondo es migrar a Fastjson 2.x, que no está afectada.
- El riesgo mayor está en lo que no se ve: la librería aparece a menudo como dependencia transitiva, así que el primer trabajo es de inventario, no de parcheo.
Cómo funciona, sin dar la receta
Fastjson convierte JSON en objetos Java. Su punto débil histórico es el campo @type, que le indica a la librería qué clase Java debe instanciar al leer un documento. Para frenar el abuso de ese campo, el proyecto añadió con el tiempo el mecanismo AutoType y, más tarde, SafeMode. La novedad de este fallo es que la cadena confirmada funciona con la configuración de fábrica: sin AutoType activado y sin necesidad de una cadena de clases encadenadas —lo que en el argot se llama gadget chain— presente en el classpath, el conjunto de rutas donde la máquina virtual Java busca las clases que carga.
A nivel conceptual, un valor @type manipulado se transforma en una búsqueda de recurso de clase que permite cargar código compilado —bytecode— desde una ruta anidada dentro de un JAR, y la anotación @JSONType termina actuando como señal de confianza que deja pasar esa clase por delante de los controles de seguridad de la librería. El resultado es ejecución de código en el contexto de la aplicación. No reproducimos aquí la petición concreta: el mecanismo basta para entender el riesgo y priorizar la defensa, que es lo que nos interesa.
Para que la cadena confirmada funcione tienen que darse, a la vez, estas condiciones:
- Fastjson en el rango 1.2.68 a 1.2.83.
- Una aplicación Spring Boot empaquetada como fat-JAR (se ha confirmado en Spring Boot 2.x, 3.x y 4.x, sobre JDK 8, 11, 17 y 21).
- Una ruta accesible por red que entregue JSON controlado por el atacante a un analizador afectado.
- SafeMode en su valor por defecto, es decir, desactivado.
Los datos, con su fuente
El registro oficial recoge CVE 2026-16723 con CVSS 9,0, afectando a Fastjson de la 1.2.68 a la 1.2.83. El hallazgo es de la firma de seguridad FearsOff, y los mantenedores de Fastjson publicaron el aviso el 21 de julio de 2026, según recoge la ficha de Tenable.
La explotación en Internet, dirigida sobre todo a organizaciones de Estados Unidos, la recogen BleepingComputer y The Hacker News, que citan a proveedores de seguridad como ThreatBook e Imperva entre quienes han observado los ataques. El punto que más pesa para un responsable de seguridad es el que subrayan varios análisis: Fastjson 1.x está descontinuada y no llegará un parche para esta rama, así que la vía correcta es la migración a la 2.x.
Por qué los controles de siempre no bastan
La gestión de parches, el reflejo habitual ante un CVE, aquí no tiene a qué agarrarse: no hay parche que aplicar. Cuando un componente llega al final de su vida, el proceso de gestión de vulnerabilidades tiene que cambiar de registro y pasar de «parchear» a «mitigar y sustituir».
El segundo problema es de visibilidad. Fastjson rara vez se declara a mano; llega como dependencia transitiva arrastrada por otra librería, un patrón clásico de ataque a la cadena de suministro. Un inventario «a ojo» no la encuentra, y por eso el análisis de composición de software y el SBOM dejan de ser buenas prácticas para convertirse en el único modo fiable de saber si estás expuesto. Lo desarrollamos en las lecciones de la cadena de suministro digital.
Y el tercero es que la carga puede resolverse desde una ruta interna al propio fat-JAR, lo que complica las reglas de red o de WAF pensadas para bloquear cargas de clases desde servidores externos. Aquí es donde pasar un scanner no equivale a gestionar el riesgo.
Detección operativa
Sin necesidad de esperar a un parche, hay señales concretas que un equipo puede vigilar desde ya:
- Revisar registros de aplicación y de proxy en busca de valores sospechosos en los cuerpos JSON: cadenas @type, jar:http: o jar:file:.
- Vigilar procesos hijos inesperados de la máquina virtual Java —una instancia lanzando un intérprete de comandos, PowerShell o /bin/sh es una anomalía clara— y correlacionarlos en el EDR.
- Buscar conexiones salientes anómalas desde servidores de aplicaciones (por ejemplo hacia LDAP, RMI o HTTP a destinos desconocidos), ficheros nuevos en directorios de la aplicación y posibles webshells.
- Inventariar la superficie: listar las dependencias directas y transitivas de Fastjson con las herramientas de construcción (árbol de dependencias de Maven o Gradle) o con una plataforma de SCA.
Defensa práctica
La mitigación inmediata es activar SafeMode, que cierra la ruta confirmada de un plumazo. Se aplica con la propiedad de arranque de la JVM -Dfastjson.parser.safeMode=true o, por código, con ParserConfig.getGlobalInstance().setSafeMode(true). Conviene probarlo antes: SafeMode desactiva el procesamiento de @type, así que romperá cualquier funcionalidad que dependa de instanciar tipos declarados en el JSON.
A partir de ahí, y en este orden, el plan razonable es:
- Si SafeMode rompe algo crítico, valorar el artefacto de compatibilidad com.alibaba:fastjson:1.2.83_noneautotype como paso intermedio.
- Planificar la migración a Fastjson 2.x, que por arquitectura no está afectada, tras pruebas de compatibilidad: la API cambia y no es un reemplazo directo.
- Mantener un parche virtual en el WAF mientras dura la migración; varios proveedores publicaron reglas para este CVE, pero es un puente, no el destino.
- Restringir el tráfico de salida de los servidores de aplicaciones: limitarlo reduce el impacto de una carga de clase remota si algo se escapa.
Si la vigilancia detecta indicios de explotación, conviene tratar el caso como incidente y no como simple hallazgo: aislar, preservar evidencias y activar el procedimiento de respuesta. Priorizar qué mitigar primero cuando hay varias exposiciones abiertas es justo el terreno de marcos como KEV, EPSS y SSVC.
Qué miran NIS2 y DORA aquí
Este caso no se juzga solo por el CVE, sino por la gestión de dependencias y de software sin mantenimiento. NIS2 exige a las entidades cubiertas gestionar el riesgo de la cadena de suministro y el ciclo de vida de las vulnerabilidades; DORA pide a las entidades financieras un control equivalente sobre el riesgo TIC y de terceros, con inventario y resiliencia demostrables. Un componente descontinuado en producción deja de ser un detalle técnico y se convierte en un hallazgo de auditoría.
Y hay un reloj: si se confirma explotación con impacto, los plazos de notificación —las ventanas de NIS2 y las obligaciones de reporte de DORA— empiezan a correr. Tener localizado el componente, documentada la mitigación y trazado el plan de sustitución es lo que separa una respuesta ordenada de una carrera a ciegas.
En resumen
Fastjson 1.x es el ejemplo perfecto de la deuda que no aparece en ningún plan: código que funciona, que nadie mira y que un día se convierte en la vía de entrada. La respuesta rápida se llama SafeMode. La respuesta seria consiste en saber, en cualquier momento, qué librerías ejecutas de verdad y cuáles ya no tienen quien las arregle. Lo primero se hace en una tarde; lo segundo es un músculo que se entrena.
Este análisis se ofrece con fines defensivos. Las opciones de configuración y mitigación descritas deben probarse en un entorno controlado antes de llevarlas a producción: activar SafeMode o recurrir al artefacto noneautotype puede alterar el comportamiento de aplicaciones que dependan del campo @type.