xiaoqimikko/fastjson-checkZero-dependency, offline CLI scanner that finds fastjson inside JARs and Spring Boot fat-JARs, flags CVE-2026-16723 exposure, and detects shaded dependencies for CI gating.
Une seule commande pour déterminer si votre application Java contient fastjson, où il se cache et si elle est affectée par CVE-2026-16723.
Zéro dépendance · Entièrement hors ligne · Un seul jar de 23 Ko · Compatible Java 8+
Le 21 juillet 2026, l'équipe officielle de fastjson a publié CVE-2026-16723 (CVSS 9.0, exécution de code à distance) :
De nombreux avis de sécurité (y compris plusieurs médias de sécurité anglophones) affirment encore aujourd'hui que « la branche 1.x est EOL, il n'y aura jamais de correctif, il faut migrer vers fastjson2 ». Cette affirmation n'est plus valable depuis le 2026-07-29. À vérifier par vous-même :
| Preuve | Lien |
|---|---|
Le dépôt central Maven contient com.alibaba:fastjson:1.2.84, jar mis en ligne le 2026-07-29 | repo1 |
Release GitHub 1.2.84, publiée le 2026-07-29T08:24:51Z | release |
Commit clé fix: strengthen autoType type name validation and whitelist verification | 2026-07-29T07:02:55Z |
La 1.2.83 est sortie en mai 2022 ; depuis, la branche 1.x est restée quatre ans sans aucun commit — la 1.2.84 est une publication exceptionnelle dédiée à cette vulnérabilité.
Le titre de sa release n'indique pas de correctif de sécurité : celui de la 1.2.83 mentionnait « (correctif de sécurité) », tandis que la 1.2.84 indique seulement
« Publication de la version 1.2.84 ». Mais le corps du texte le mentionne — il contient une section complète Security Fixes, énumérant quatre renforcements d'AutoType,
et c'est ainsi depuis le jour de la publication (2026-07-29) (vérifiable dans l'archive Wayback 20260729094935).
Quant à la raison pour laquelle la plupart des avis de sécurité et des scanners n'ont toujours pas suivi après la publication du correctif, je ne l'ai pas déterminée et je ne fais aucune supposition ici.
📌 Correction du 2026-08-14 : il était écrit ici « le texte ne mentionne nulle part la sécurité, d'où l'absence de suivi ». La première moitié s'est révélée fausse après vérification du corps de la release et de l'archive Wayback du jour même (seul le titre ne l'indiquait pas) ; la seconde moitié perd donc aussi sa base et a été supprimée.
👉 Impact concret pour les utilisateurs de 1.x : passer à 1.2.84 est la remédiation la moins coûteuse (même branche, version mineure, généralement sans modification de code), sans être contraint de migrer immédiatement vers la version majeure fastjson2. Cet outil formule ses recommandations en ce sens.
⚠️ Sous réserve d'un JDK 8 ou supérieur (vérifié le 2026-10-14) : les 274 classes de la 1.2.84 sont toutes en bytecode Java 8 (major 52), alors que la 1.2.83 est en Java 5 (major 49). Sur un JDK 7 (Zulu 7u352),
javacn'émet qu'un avertissement avec un code de sortie 0, mais à l'exécution il lève directementUnsupportedClassVersionError: com/alibaba/fastjson/JSON : Unsupported major.minor version 52.0. Autre point : la constanteJSON.VERSIONdans la 1.2.84 vaut toujours"1.2.83", ce qui fausse la détection de version si on s'y fie ; cet outil litpom.propertieset n'est pas affecté.
Et le point le plus délicat :
fastjson est généralement une dépendance transitive — personne ne l'installe volontairement, il est amené par une autre bibliothèque. Beaucoup d'équipes ignorent totalement qu'elles l'utilisent.
mvn dependency:tree peut lister les dépendances, mais reste impuissant dans deux cas :
Cet outil a été écrit pour ces deux cas.
Téléchargez fastjson-check.jar depuis Releases, puis :
# 扫一个 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
Aucune installation, aucun compte, aucune connexion réseau, aucune donnée téléversée.
Le même artefact est à la fois une CLI et un plugin Maven. Cette utilisation ne nécessite pas de télécharger le jar au préalable :
# 在你的项目目录下直接跑，扫的是 Maven 解析后的依赖
mvn io.github.xiaoqimikko:fastjson-check:0.3.1:check
ou lier au cycle de vie de build (phase 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>
pom.xmlLorsque le CLI scanne pom.xml, il lit du texte, or dans un vrai projet la version de fastjson ne figure souvent pas dans ce texte :
<version>${fastjson.version}</version><parent>, cette ligne n'existe pas dans votre propre pomLe plugin obtient l'ensemble des dépendances Maven après résolution, chaque dépendance portant le chemin réel du jar dans le dépôt local.
On emprunte donc précisément la voie que cet outil maîtrise le mieux : scanner com/alibaba/fastjson(2)/JSON.class dans le vrai jar,
plutôt que de croire ce qui est écrit dans le pom.
⚠️ Mais la frontière de détection ne change pas pour autant : la clé de décision reste ce chemin de classe, donc les dépendances relocalisées (relocate) / repackagées avec un nom de paquet modifié restent indétectables (voir « Ce qu'il n'est pas » ci-dessous). Le plugin résout la question « où la version est-elle écrite », pas « le nom du paquet a-t-il été changé ».
| Paramètre | Valeur par défaut | Description |
|---|---|---|
-Dfastjson-check.failOnFound | false | Fait échouer la compilation en cas de détection de CRITICAL / HIGH |
-Dfastjson-check.path | non défini | Ne scanne pas l'arbre de dépendances, scanne plutôt ce chemin (répertoire / jar / war / fat-jar) |
-Dfastjson-check.skip | false | Ignore l'exécution |
🔴 Par défaut, le build n'échoue pas, c'est délibéré, et cela diffère de la sémantique du code de sortie du CLI :
la ligne de commande, c'est vous qui la tapez, et un code de sortie 1 est exactement ce que vous voulez ; tandis que le plugin est branché sur la chaîne d'intégration,
et un outil d'auto-vérification ne devrait pas faire échouer le build alors que vous ne vous y attendez pas. Pour en faire un garde-fou CI, ajoutez explicitement
-Dfastjson-check.failOnFound=true.