Introduction
Fastjson, la bibliothèque de sérialisation JSON développée par Alibaba et largement intégrée dans les applications Java d'entreprise, fait l'objet d'exploitations actives depuis la semaine du 21 juillet 2026. La faille concernée, CVE-2026-16723, affiche un score CVSS de 9.0. Sa particularité : elle n'obtiendra probablement jamais de correctif sur la branche 1.x.
Une chaîne d'exploitation minimaliste
La vulnérabilité affecte les versions 1.2.68 à 1.2.83 — soit l'intégralité de la gamme maintenue de Fastjson 1.x. Pour être exploitable, trois conditions suffisent : l'application tourne dans un fat-JAR exécutable Spring Boot, elle expose un endpoint réseau acceptant du JSON contrôlé par l'attaquant, et SafeMode est désactivé — ce qui correspond au comportement par défaut.
Ce dernier point mérite d'être souligné. Contrairement aux précédentes vulnérabilités Fastjson qui nécessitaient l'activation d'AutoType ou la présence d'un gadget spécifique dans le classpath, CVE-2026-16723 contourne ces prérequis. L'attaquant n'a besoin d'aucune authentification, et le code s'exécute avec les privilèges du processus Java cible. Spring Boot 2.x, 3.x et 4.x sont concernés, sur JDK 8 à 21 inclus.
24 heures entre l'advisory et les premières attaques
Alibaba a publié son avis de sécurité le 21 juillet 2026, à la suite d'une divulgation responsable menée par FearsOff Cybersecurity. Dès le lendemain, les équipes de threat intelligence de ThreatBook détectaient des tentatives d'exploitation en conditions réelles.
Les secteurs les plus ciblés sont les services financiers, la santé et le retail. Géographiquement, les États-Unis concentrent la majorité du trafic malveillant, avec des volumes secondaires en provenance de Singapour et du Canada. Les outils employés par les attaquants se répartissent entre impersonateurs de navigateurs, qui représentent la majorité des requêtes, et des outils spécialisés écrits en Ruby et Go, qui totalisent environ 30 % du trafic d'attaque combiné.
Le problème structurel des bibliothèques figées
Alibaba n'a pas publié de version corrigée de Fastjson 1.x et n'en a pas annoncé. La stratégie du mainteneur est lisible depuis plusieurs années : la branche 1.x n'est plus le vecteur d'investissement prioritaire. Fastjson2, réécriture complète de la bibliothèque avec une architecture fondamentalement différente, n'est pas affectée par cette vulnérabilité.
Ce scénario illustre un risque que les équipes techniques connaissent mais sous-estiment souvent : le passif de dépendances figées dans les applications Java d'entreprise. Fastjson 1.x est intégré dans d'innombrables projets, souvent par des couches de dépendances transitives, hors du périmètre de surveillance habituel. L'absence de correctif transforme cette faille en problème de gouvernance autant que de sécurité.
Ce que les équipes doivent faire maintenant
Trois actions sont disponibles, dans l'ordre croissant de complexité.
Activer SafeMode immédiatement. L'ajout du paramètre JVM -Dfastjson.parser.safeMode=true au démarrage de l'application coupe la chaîne d'exploitation. C'est la mesure palliative la plus rapide, applicable sans redéploiement complet du code.
Basculer vers le build restreint. L'artifact com.alibaba:fastjson:1.2.83_noneautotype désactive nativement AutoType et réduit la surface d'attaque, en remplacement drop-in du JAR standard.
Planifier la migration vers Fastjson2. Alibaba fournit un package de compatibilité permettant une transition progressive, mais sans garantie de compatibilité à 100 % : des tests de régression approfondis sont nécessaires. Pour les applications critiques exposées sur Internet, cette migration doit être inscrite au planning avec une priorité haute.
SafeMode achète du temps. La migration résout le problème à la racine.