Una vulnerabilidad crítica, CVE-2026-16723, se explota de forma activa en Fastjson 1.x para lograr ejecución remota de código en servidores que procesan JSON. La rama 1.x no tiene parche oficial, así que la contención pasa por activar SafeMode, usar una build noneautotype o migrar a fastjson2.
La explotación activa de CVE-2026-16723 ha puesto bajo presión a equipos de seguridad y desarrollo que mantienen servicios Java con Fastjson 1.x en producción. El fallo permite ejecución remota de código (RCE) sin autenticación, sin interacción del usuario y sin necesidad de privilegios elevados, un cóctel especialmente peligroso cuando el servidor expone endpoints que aceptan JSON desde Internet.
El alcance es concreto, pero amplio en la práctica. El problema afecta a Fastjson 1.2.68 a 1.2.83, incluida 1.2.83, la última versión de la rama 1.x. La condición que marca la diferencia está en el despliegue: la cadena de explotación funciona cuando la aplicación se ejecuta como Spring Boot executable fat JAR, por ejemplo al arrancar con java -jar. La verificación de la explotación se ha reproducido en Spring Boot 2.x, 3.x y 4.x, y en JDK 8, 11, 17 y 21, lo que reduce el margen para ‘esquivar’ el riesgo por versión.
El ataque se apoya en la deserialización y en el uso de @type. Aunque muchas organizaciones desactivaron AutoType hace tiempo, aquí no basta: la explotación funciona con una configuración habitual, con AutoType desactivado y SafeMode desactivado. La lógica de resolución de tipos permite búsquedas de recursos controladas por el atacante antes de aplicar restricciones, lo que abre la puerta al payload.
La actividad se ha observado sobre todo contra organizaciones en Estados Unidos, con señales adicionales en Singapur y Canadá, y con impacto transversal en sectores como servicios financieros, sanidad, comercio minorista y entornos empresariales de computación. En este escenario, un compromiso no se queda en un simple fallo de aplicación: un RCE puede traducirse en control total del servidor, robo de credenciales o despliegue de otras cargas maliciosas.
El problema operativo llega con la respuesta: no existe una actualización oficial que corrija CVE-2026-16723 en Fastjson 1.x, y se considera poco probable que esa rama reciba parche. Tampoco sirve como apaño deserializar a una clase ‘segura’ con JSON.parseObject(String, Class), porque el payload puede anidarse en campos de tipo Object o Map.
La mitigación inmediata pasa por activar SafeMode, ya sea con -Dfastjson.parser.safeMode=true, mediante ParserConfig.getGlobalInstance().setSafeMode(true) o con fastjson.properties. Cuando sea viable, conviene sustituir la dependencia por una build noneautotype, como com.alibaba:fastjson:1.2.83_noneautotype, y planificar la migración a fastjson2, que no se ve afectado gracias a un diseño más restrictivo por defecto, basado en allowlist y sin confiar en @JSONType como señal de confianza.
A corto plazo, las organizaciones deberían localizar ya dónde usan Fastjson 1.x y qué versión ejecutan realmente, con prioridad en servicios expuestos. También ayuda recortar superficie: revisar y limitar endpoints que deserializan JSON controlado por el cliente, reforzar validaciones de entrada y aplicar controles perimetrales para bloquear intentos de forzar @type. Y, dado que se explota activamente, toca buscar señales de compromiso en los sistemas que cumplan la condición crítica del fat JAR de Spring Boot.
Más información
- BleepingComputer – Hackers target US firms in FastJson RCE zero-day attacks : https://www.bleepingcomputer.com/news/security/hackers-target-us-firms-in-fastjson-rce-zero-day-attacks/
- SecurityWeek – Unpatched Fastjson Vulnerability Exploited in Attacks : https://www.securityweek.com/unpatched-fastjson-vulnerability-exploited-in-attacks/
- GitHub, alibaba/fastjson2 Wiki – Security Advisory: Remote Code Execution in fastjson 1.2.68-1.2.83 : https://github.com/alibaba/fastjson2/wiki/Security-Advisory%3A-Remote-Code-Execution-in-fastjson-1.2.68%E2%80%931.2.83
Deja una respuesta