Retour au blog
CVEJavaRCEtechnique

Fastjson 1.x CVE-2026-16723 : une RCE critique sans correctif, exploitée activement

Publié le 2026-07-257 min de lectureCleanIssue

> En bref : CVE-2026-16723 est une faille critique d'exécution de code à distance (CVSS 9.0) dans Fastjson 1.2.68 à 1.2.83 d'Alibaba, la librairie JSON pour Java. Sur une application Spring Boot fat-JAR affectée, une requête JSON malveillante exécute du code avec les privilèges du process Java — sans AutoType activé, sans gadget de classpath, sans authentification. Au 25 juillet 2026, aucune release 1.x corrigée n'existe. Contournement : activer SafeMode ou migrer vers Fastjson2.

Pourquoi ça vous concerne

Fastjson est l'une des librairies JSON les plus utilisées de l'écosystème Java. Si votre backend (ou celui d'un partenaire, ou d'un client) est Java/Spring, il y a de fortes chances qu'il tire Fastjson en dépendance transitive. Cette CVE s'inscrit dans la lignée directe de Log4Shell et Spring4Shell : une librairie Java omniprésente, une config par défaut qui n'est pas sûre, et un chemin d'exploitation sans authentification.

L'angle distinctif ici, c'est que le mainteneur n'a pas de correctif 1.x. La recommandation officielle est de migrer vers Fastjson2 — un travail d'ingénierie de plusieurs semaines pour la plupart des équipes, pas un simple bump de dépendance. En attendant, chaque endpoint Fastjson 1.2.68–1.2.83 exposé est une cible vivante.

La faille en deux phrases

Le bug est dans le chemin de résolution de types de Fastjson. Une valeur @type contrôlée par l'attaquant est transformée en lookup de ressource de classe, et sur un Spring Boot fat-JAR un chemin de JAR imbriqué forgé peut récupérer du bytecode contrôlé par l'attaquant. Une annotation @JSONType dans cette ressource est alors traitée comme un signal de confiance, permettant à la classe de passer les contrôles de type de Fastjson et de se charger — d'où exécution de code.

De façon critique, AutoType n'a pas besoin d'être activé et aucune classe gadget n'a besoin d'exister sur le classpath. Ça retire les deux contrôles que la plupart des équipes pensaient les protéger. La chaîne a été reproduite sur Spring Boot 2.x, 3.x et 4.x avec JDK 8, 11, 17 et 21. Les points d'entrée incluent JSON.parse, JSON.parseObject(String) et JSON.parseObject(String, Class) — et binder l'entrée sur une classe fixe ne suffit pas si un champ Object ou Map permet au payload de nicher.

Ce qui la rend pire qu'une RCE normale

Trois facteurs aggravants s'empilent :

  • Aucun correctif. La version 1.2.83 était déjà la mise à niveau recommandée par Alibaba pour un contournement AutoType de 2022 — elle est désormais elle-même dans la plage affectée. Il n'existe pas de 1.x plus récent.
  • Exploitation active. ThreatBook a capté de l'activité in-the-wild dès le 20 juillet ; Imperva a rapporté du ciblage sur les services financiers, la santé, l'informatique et la retail, principalement aux US.
  • Incertitude de périmètre. Une évaluation CISA-ADP du 23 juillet marquait l'exploitation à none, contredisant les rapports des éditeurs. La faille est absente du catalogue KEV de la CISA. La contradiction n'est pas expliquée — traitez les rapports des éditeurs comme la source de vérité.
  • Ce qu'il faut faire

  • Inventorier Fastjson partout, y compris les dépendances transitives. Lancez mvn dependency:tree | grep fastjson (ou l'équivalent Gradle). Beaucoup d'équipes ignorent le tirer via une autre librairie.
  • Activer SafeMode immédiatement sur tout Fastjson 1.x que vous ne pouvez pas remplacer : -Dfastjson.parser.safeMode=true, ou utilisez l'artefact restreint com.alibaba:fastjson:1.2.83_noneautotype. Alibaba liste les deux comme mitigations. Notez que l'advisory précise qu'aucun ne « remédie totalement » — ils achètent du temps.
  • Planifier la migration vers Fastjson2, qui n'est pas affectée (elle n'utilise pas le même chemin de probing de ressource et de confiance par annotation). Scopez la surface de breaking changes — les sémantiques de parseObject diffèrent.
  • Bloquer `@type` en bordure (WAF / API gateway) en defense-in-depth. Cherchez "@type" et les patterns d'URL de JAR imbriqué dans le JSON entrant. C'est un palliatif, pas un correctif.
  • Chercher la compromission sur les services Spring Boot fat-JAR exposés : connexions sortantes inattendues, process enfants, valeurs @type suspectes dans les logs, changements de fichiers, web shells.
  • Le pattern que ça confirme

    Fastjson CVE-2026-16723 est le troisième rappel en cinq ans que « parser du JSON non fiable avec une librairie qui résout des types contrôlés par l'attaquant » est un défaut fondamentalement dangereux. Log4Shell nous a appris le JNDI, Spring4Shell le data binding, et Fastjson rappelle maintenant que même avec AutoType off, le chemin de résolution de types est lui-même une surface d'attaque. Pour un éditeur SaaS, la leçon est opérationnelle : toute librairie de désérialisation qui a connu deux RCE sérieuses dans sa vie appartient à une watchlist avec un plan de migration déjà rédigé.

    Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit