fastjson-check

Un solo comando para averiguar si tu aplicación Java contiene fastjson, dónde está escondido y si se ve afectada por CVE-2026-16723.

Sin dependencias · Completamente offline · Un único jar de 23KB · Compatible con Java 8+

English | Descargar

---

Por qué es necesario

El 21 de julio de 2026, el equipo oficial de fastjson publicó CVE-2026-16723 (CVSS 9.0, ejecución remota de código):

• Afecta a fastjson 1.2.68 ~ 1.2.83
• Explotable con la configuración por defecto — no requiere habilitar AutoType, ni gadgets en el classpath, ni autenticación
• El aviso apareció en explotaciones en la naturaleza en cuestión de días, dirigidas principalmente a despliegues Spring Boot fat-JAR

⚠️ El parche oficial 1.2.84 ya se publicó, pero casi nadie lo sabe

Numerosos avisos de seguridad (incluidos varios medios de seguridad en inglés) siguen afirmando hasta hoy que «la rama 1.x está EOL, nunca habrá parche y solo queda migrar a fastjson2». Esa afirmación dejó de ser cierta desde el 2026-07-29. Puedes verificarlo tú mismo:

Evidencia	Enlace
El repositorio central de Maven tiene com.alibaba:fastjson:1.2.84, jar subido el 2026-07-29	repo1
Release de GitHub 1.2.84, publicado el 2026-07-29T08:24:51Z	release
Commit clave fix: strengthen autoType type name validation and whitelist verification	2026-07-29T07:02:55Z

La 1.2.83 se publicó en mayo de 2022 y, desde entonces, la rama 1.x estuvo cuatro años sin commits — la 1.2.84 se publicó como excepción específicamente para esta vulnerabilidad.

El título de su release no indica que sea una corrección de seguridad: el título de la 1.2.83 decía «(corrección de seguridad)», mientras que el de la 1.2.84 solo dice «Publicación de la versión 1.2.84». Pero el cuerpo sí lo indica — incluye una sección completa de Security Fixes que enumera cuatro refuerzos de AutoType, y así ha sido desde el mismo día de la publicación (2026-07-29) (consultable en el archivo de Wayback 20260729094935).

En cuanto a por qué la mayoría de los avisos de seguridad y escáneres no se han actualizado tras la publicación del parche, no lo he averiguado y no haré conjeturas al respecto.

📌 Corrección del 2026-08-14: aquí se decía originalmente «el texto completo no menciona seguridad, por lo que no se le hizo seguimiento». La primera mitad resultó ser falsa tras comprobarla con el cuerpo del release y el archivo de Wayback de ese mismo día (solo el título no lo indicaba), y la segunda mitad perdió por ello su fundamento, por lo que se elimina también.

👉 Impacto real para los usuarios de 1.x: actualizar a 1.2.84 es la medida de menor coste (una subversión de la misma rama, normalmente sin cambios de código), sin necesidad de verse forzado a hacer de inmediato la gran migración de versión mayor a fastjson2. Esta herramienta ofrece recomendaciones en ese sentido.

⚠️ El requisito es JDK 8 o superior (verificado el 2026-10-14): las 274 clases de la 1.2.84 son todas bytecode de Java 8 (major 52), mientras que la 1.2.83 es Java 5 (major 49). En JDK 7 (Zulu 7u352), javac solo emite advertencias y devuelve código de salida 0, pero en tiempo de ejecución lanza directamente UnsupportedClassVersionError: com/alibaba/fastjson/JSON : Unsupported major.minor version 52.0. Además: la constante JSON.VERSION de la 1.2.84 sigue siendo "1.2.83", por lo que juzgar la versión por ella daría un resultado erróneo; esta herramienta lee pom.properties, por lo que no se ve afectada.

Y lo más problemático es que:

fastjson suele ser una dependencia transitiva — nadie lo instala a propósito, viene arrastrado por otra biblioteca. Muchos equipos ni siquiera saben que lo están usando.

mvn dependency:tree puede listar las dependencias, pero no sirve para dos situaciones:

1. Solo tienes un fat-JAR ya empaquetado, sin código fuente ni entorno de compilación (el escenario más habitual en una respuesta de emergencia en producción)
2. fastjson ha sido incluido mediante shade dentro del jar de algún SDK, y no aparece en el árbol de dependencias

Esta herramienta está escrita precisamente para estas dos situaciones.

Inicio rápido

Descarga fastjson-check.jar desde Releases y luego:

# 扫一个 jar（Spring Boot fat-JAR 会自动逐层展开）
java -jar fastjson-check.jar ./myapp.jar

# 扫一整个目录（递归查找所有 jar/war）
java -jar fastjson-check.jar /opt/apps

# 输出 JSON，接入流水线
java -jar fastjson-check.jar /opt/apps --json

No requiere instalación, no requiere cuenta, no requiere conexión a internet, no sube ningún dato.

Ejecutar como plugin de Maven (desde 0.3.0)

El mismo artefacto es tanto CLI como plugin de Maven. Este uso no requiere descargar el jar primero:

# 在你的项目目录下直接跑，扫的是 Maven 解析后的依赖
mvn io.github.xiaoqimikko:fastjson-check:0.3.1:check

O vincularlo al ciclo de vida de compilación (fase verify):

<plugin>
  <groupId>io.github.xiaoqimikko</groupId>
  <artifactId>fastjson-check</artifactId>
  <version>0.3.1</version>
  <executions>
    <execution>
      <goals><goal>check</goal></goals>
    </execution>
  </executions>
</plugin>

Por qué el modo plugin es más preciso que dejar que la CLI escanee pom.xml

Cuando la CLI escanea pom.xml, lo que lee es texto, y en proyectos reales la versión de fastjson a menudo no está en ese texto:

• Escrita como propiedad: <version>${fastjson.version}</version>
• Heredada de <parent>, en tu propio pom no existe esa línea
• El caso más común: es una dependencia transitiva introducida por otra biblioteca, tu pom ni siquiera menciona fastjson

Lo que obtiene el plugin es el conjunto de dependencias de Maven ya resueltas, y cada dependencia trae la ruta real del jar en el repositorio local. Así que se sigue exactamente el camino en el que esta herramienta es más fuerte: escanear com/alibaba/fastjson(2)/JSON.class dentro del jar real, en lugar de confiar en lo que dice el pom.

⚠️ Pero el límite de identificación no cambia por esto: la clave de decisión sigue siendo esa ruta de class, así que las dependencias relocalizadas / repaquetadas con otro nombre de paquete siguen sin poder identificarse (ver «Qué no es» más abajo). El plugin resuelve «dónde está escrita la versión», no «el nombre del paquete fue cambiado».

Parámetros

Parámetro	Predeterminado	Descripción
-Dfastjson-check.failOnFound	false	Hace que la compilación falle cuando se detecta CRITICAL / HIGH
-Dfastjson-check.path	Sin establecer	No escanea el árbol de dependencias, en su lugar escanea esta ruta (directorio / jar / war / fat-jar)
-Dfastjson-check.skip	false	Omite la ejecución

🔴 Por defecto no hace fallar la compilación, y esto es intencional, a diferencia de la semántica del código de salida de la CLI: la línea de comandos la escribes tú, y un código de salida 1 es justo lo que quieres; en cambio, el plugin está enganchado en la cadena de integración, y una herramienta de autoverificación no debería poner en rojo la compilación cuando no estás preparado. Para usarlo como puerta de CI, añade explícitamente -Dfastjson-check.failOnFound=true.

💡 En Windows, si el informe sale con caracteres corruptos, cambia la consola de vuelta a GBK (chcp 936) — la codificación de salida del modo plugin la decide Maven, y los interruptores --utf8 / --gbk de la CLI no llegan aquí.