Alibaba publicó su aviso aquí el 21 de julio tras la divulgación responsable de Kirill Firsov aquí de FearsOff Cybersecurity. Los mantenedores describieron la vulnerabilidad como una que "no requiere la activación de AutoType" y "ningún gadget de classpath". Verificaron la cadena en Spring Boot 2.x, 3.x y 4.x con JDK 8, 11, 17 y 21.

Firsov rastreó el problema hasta la ruta de resolución de tipos de Fastjson. Un valor @type controlado por un atacante puede convertirse en una búsqueda de recurso de clase. En un fat-JAR de Spring Boot compatible, una ruta de JAR anidada manipulada puede obtener el bytecode controlado por el atacante. Una anotación @JSONType en ese recurso puede entonces tratarse como una señal de confianza, permitiendo que la clase supere los controles de tipo de Fastjson y se cargue.

Su análisis técnico aquí también describe una ruta para JDKs más recientes que descarga un JAR remoto y hace referencia a él a través de /proc/self/fd.

El exploit depende del cargador fat-JAR ejecutable de Spring Boot. Alibaba indica que los JAR normales (no-fat), los uber-JAR genéricos y los despliegues WAR de Tomcat o Jetty no están afectados. Los puntos de entrada accesibles incluyen JSON.parse, JSON.parseObject(String) y JSON.parseObject(String, Class). Vincular la entrada a una clase fija no es suficiente cuando un objeto contiene un campo Object o Map donde la carga útil puede estar anidada.

ThreatBook señaló aquí el 22 de julio que su plataforma había capturado explotaciones en el mundo real después de añadir soporte de detección dos días antes. Sus resultados de laboratorio fueron más limitados: reprodujeron la ejecución completa de código en un fat-JAR de Spring Boot en JDK 8, mientras que su prueba con Tomcat embebido solo produjo una obtención de JAR remoto o una falsificación de solicitud del lado del servidor (SSRF).

Imperva informó aquí actividad contra servicios financieros, salud, informática, comercio minorista y otras organizaciones, principalmente en Estados Unidos, con volúmenes menores en Singapur y Canadá. Afirmó que los imitadores de navegadores generaron la mayoría de las solicitudes, mientras que las herramientas de Ruby y Go representaron aproximadamente el 30% colectivamente.



Ninguno de los proveedores publicó recuentos de ataques, solicitudes brutas, evidencia de ejecución, víctimas nombradas o compromisos confirmados. Sus informes establecen que se ha observado actividad de exploit, no una prueba de ejecución de código exitosa contra un objetivo real o una brecha de seguridad.

Una evaluación de CISA-ADP del 23 de julio aquí marcó, no obstante, que la explotación era inexistente. Se confirmó el 25 de julio que el fallo estaba ausente del catálogo actual de Vulnerabilidades Explotadas Conocidas de CISA aquí. Las fuentes disponibles no explican esta discrepancia.

Tampoco se encontró ningún artefacto de Fastjson 1.x parcheado en las etiquetas de GitHub del proyecto aquí o en el repositorio Maven Central aquí hasta el 25 de julio. La versión 1.2.83 sigue siendo el último lanzamiento estándar de la serie 1.x, mientras que 1.2.83_noneautotype sigue siendo la compilación restringida disponible.

Debes inventariar las dependencias directas y transitivas de Fastjson e inspeccionar los sistemas afectados en busca de valores @type sospechosos, URLs de JAR anidados, conexiones salientes inesperadas, procesos hijos, cambios de archivos y web shells. Fastjson2 no se ve afectado porque no utiliza la misma ruta de sondeo de recursos o de confianza basada en anotaciones.

Se ha contactado a Alibaba para obtener aclaraciones sobre las versiones afectadas y los planes de parcheo de Fastjson 1.x, y a Imperva para obtener detalles sobre la actividad de explotación reportada. Actualizaremos la historia con cualquier respuesta.

Fastjson 1.2.83 fue la actualización recomendada por Alibaba para un bypass de AutoType independiente revelado en 2022. Ese lanzamiento final de la serie 1.x ahora se encuentra dentro del rango afectado por el CVE-2026-16723.

Fuente:
THN