Fastjson CVE-2026-16723 : RCE par défaut en Spring Boot
Que fait exactement cette faille ?
Fastjson est une bibliothèque Java de lecture et d'écriture de JSON. Selon l'avis d'Alibaba, la cause est le contrôle checkAutoType de Fastjson 1.x, qui appelle getResourceAsStream sur des noms de type fournis par l'utilisateur. Dans un fat-JAR Spring Boot, un chemin de JAR imbriqué forgé permet de récupérer des octets choisis par l'attaquant. L'annotation @JSONType qu'ils contiennent est alors lue comme un signal de confiance, la classe passe les contrôles et se charge, d'où l'exécution de code.
Les points d'entrée sont JSON.parse, JSON.parseObject(String) et JSON.parseObject(String, Class). Indiquer une classe cible ne protège pas, puisque la charge utile peut se loger dans un champ de type Object ou Map. La chaîne a été décrite par Kirill Firsov (FearsOff Cybersecurity), qui a signalé la faille.
Qui est concerné ?
Sont concernées les applications qui cumulent trois conditions : Fastjson 1.2.68 à 1.2.83, un déploiement en exécutable Spring Boot fat-JAR, et un chemin réseau par lequel du JSON contrôlé par l'attaquant atteint l'analyseur. Selon Alibaba, les JAR simples, les uber-JAR génériques et les WAR sous Tomcat ou Jetty ne sont pas concernés, et Fastjson2 non plus pour cette CVE. La version 1.2.83, longtemps recommandée comme version sûre, est donc elle-même dans la plage touchée.
Côté exploitation, ThreatBook a signalé une exploitation dans la nature le 22 juillet et Imperva a décrit une activité visant la finance, la santé, l'informatique et le commerce, surtout aux États-Unis. Ni l'un ni l'autre n'a publié de nombre d'attaques ni de victime confirmée : ces rapports montrent des tentatives, pas des compromissions prouvées. Une évaluation CISA-ADP du 23 juillet marquait l'exploitation comme « none » et la faille n'était pas au catalogue KEV le 25 juillet, sans explication publique de cet écart.
Comment la détecter dans vos applications ?
- Inventoriez Fastjson, y compris en dépendance transitive :
mvn dependency:tree | grep fastjsonougradle dependencies. - Identifiez le mode de déploiement : un fat-JAR Spring Boot lancé avec
java -jarest le cas à risque. - Repérez les endpoints qui analysent du JSON non fiable : API publiques, webhooks, files de messages, importations.
- Cherchez dans les journaux des valeurs
"@type"inattendues ou des chemins de JAR imbriqués dans les corps JSON, ainsi que des connexions sortantes inhabituelles, des processus enfants du processus Java, des modifications de fichiers et des web shells.
Comment corriger ?
- Passez à Fastjson 1.2.84, indiquée comme correctif dans l'avis mis à jour. Vérifiez la version publiée et son empreinte avant de déployer.
- Activez SafeMode si la mise à jour est impossible tout de suite :
-Dfastjson.parser.safeMode=true,ParserConfig.getGlobalInstance().setSafeMode(true)ou le fichierfastjson.properties. - Utilisez l'artefact `com.alibaba:fastjson:1.2.83_noneautotype` comme alternative provisoire.
- Planifiez la migration vers Fastjson2, qui retire cette cause racine. Alibaba note que la version 2.0.63 ou ultérieure corrige un autre problème d'AutoType : visez au moins celle-ci.
- Filtrez en bordure les corps contenant
"@type"comme défense en profondeur, sans en faire le seul rempart.
Pourquoi ce motif revient-il ?
La résolution de types pilotée par l'entrée est un défaut classique des bibliothèques de désérialisation Java, de Log4Shell à Spring4Shell en passant par les contournements AutoType passés de Fastjson. Notre article sur Log4Shell et celui sur Spring4Shell montrent la même logique. Une bibliothèque qui a déjà connu plusieurs exécutions de code mérite une surveillance et un plan de remplacement écrit.
Que change un agent IA qui exploite une application Java ?
Beaucoup d'agents IA s'appuient sur des services Java : passerelles d'outils, connecteurs vers des bases ou des CRM, services de workflow. Ces services analysent du JSON en permanence, y compris celui que produit un modèle. Les scénarios suivants sont des hypothèses de test, pas des faits rapportés sur cette CVE.
Le JSON de l'agent est une entrée non fiable. Un agent construit des appels d'outils en JSON à partir d'un texte qu'un tiers peut influencer (e-mail, page web, document). Si un outil Java transmet ce JSON à Fastjson 1.x, le contenu choisi par l'attaquant atteint l'analyseur sans passer par une API publique. C'est la définition de l'injection de prompt indirecte, détaillée sur notre page prompt injection.
Le processus Java porte les identifiants de l'agent. Une exécution de code sur le service d'outils donne accès aux clés d'API, jetons de bases de données et identifiants cloud que l'agent utilise. Le rayon d'action est celui de l'agent, pas celui d'un simple service web.
Les actions automatiques amplifient l'impact. Un attaquant qui contrôle l'outil peut renvoyer à l'agent des réponses falsifiées et déclencher des actions suivantes (écritures, envois) sans validation humaine. Le mécanisme relève de l'excès d'autonomie (LLM06, OWASP Top 10 for LLM Applications 2025) : l'agent enchaîne écritures et envois sur la foi d'une réponse d'outil falsifiée.
L'inventaire des dépendances d'outils est rarement fait. Les serveurs MCP et connecteurs écrits en Java ajoutent leurs propres dépendances transitives. Voir notre page sécurité MCP.
Contrôles utiles : valider chaque appel d'outil contre un schéma strict avant analyse, isoler le service d'outils avec des identifiants à portée minimale, bloquer la sortie réseau non nécessaire et journaliser les appels. Notre page sécurité des agents IA détaille ces mesures.
Comment tester cette exposition sur un agent ?
On cartographie les outils de l'agent, leur langage et leurs bibliothèques, on identifie ceux qui analysent du JSON issu du modèle, puis on vérifie ce qu'un texte injecté peut leur faire parvenir. On mesure aussi ce que le processus compromis peut atteindre : secrets, bases, actions sans validation.
Pour une application Spring Boot qui alimente un agent, notre Red Team Agent Express vérifie en 5 jours (1 900 €) ce qu'une désérialisation piégée peut faire déclencher, après un rendez-vous découverte gratuit de 30 minutes.
Votre produit embarque un agent IA ? CleanIssue teste ce qu’un inconnu peut lui faire faire avec le Red Team Agent Express (5 jours, 1 900 €), ou un red team sur mesure pour plusieurs agents et serveurs MCP. Premier échange : un rendez-vous découverte de 30 minutes, gratuit.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Adobe Campaign Classic CVE-2026-48449 : RCE CVSS 10.0
CVE-2026-48449 (CVSS 10.0) dans Adobe Campaign Classic : autorisation défaillante et exécution de code. Versions, correctif 9398, risque agent IA.
PaperCut CVE-2026-81578 et 82078 : RCE en chaîne, agents IA
Deux zero-days PaperCut NG/MF s'enchaînent en exécution de code sans authentification. Chaîne, indicateurs, patchs contournés et risques pour un agent IA.
N-central CVE-2026-86218 : RCE pré-auth CVSS 10
CVE-2026-86218 : exécution de code sans authentification dans N-able N-central, corrigée par le Hotfix 4. Détection, correctifs et risque côté agents IA.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.