Fastjson 1.x ne recevra jamais de correctif — votre backend Java est exposé à une RCE sans authentification

Le 21 juillet 2026, Alibaba publiait un avis de sécurité pour Fastjson. Le 24 juillet, Imperva confirmait l’exploitation active. Le 28 juillet, CISA ajoutait CVE-2026-16723 à son catalogue KEV. En une semaine, la faille est passée de « divulgation responsable » à « menace avérée » — et cette fois, il n’y aura pas de correctif.

CVE-2026-16723 est une vulnérabilité de type remote code execution non authentifiée affectant Fastjson 1.x, le parseur JSON Java d’Alibaba intégré dans des milliers d’applications Spring Boot à travers le monde. Son score CVSS 9.0 la place en criticité maximale. Mais le chiffre n’est pas le pire : Fastjson 1.x est en fin de vie. Aucun patch ne sera publié. La seule issue est une migration vers Fastjson 2.x, une réécriture complète qui casse l’API existante.

Cet article détaille le fonctionnement de la faille, les secteurs ciblés, et surtout — les trois actions immédiates à déclencher ce matin, avant que votre SI ne reçoive la requête JSON de trop.

Une requête, zéro authentification, contrôle total

CVE-2026-16723 affecte les versions 1.2.68 à 1.2.83 de Fastjson, soit la quasi-totalité de la branche 1.x en production. La vulnérabilité a été découverte par FearsOff Cybersecurity et divulguée via le programme de divulgation responsable d’Alibaba le 21 juillet 2026.

Le mécanisme d’exploitation est aussi simple que dévastateur. Fastjson utilise le champ @type dans les payloads JSON pour indiquer la classe Java à instancier lors de la désérialisation. Bien que l’AutoType — le mécanisme de désérialisation polymorphique — soit désactivé par défaut dans la branche 1.x, FearsOff a identifié un contournement complet dans la logique interne de résolution de types.

Voici ce qui se passe concrètement. Un attaquant envoie un JSON malveillant contenant un champ @type forgé. Pendant le traitement, Fastjson effectue des résolutions de ressources basées sur le nom de classe contrôlé par l’attaquant. Dans les déploiements Spring Boot en fat JAR — le mode de packaging standard des microservices Java — cette manipulation exploite le mécanisme de JAR imbriqués pour contourner les restrictions de type et atteindre un chemin d’exécution de code arbitraire.

Le pire : Fastjson 1.x traite la présence de l’annotation @JSONType comme un signal de confiance pendant la résolution de types. L’attaquant peut donc combiner la résolution de ressources contrôlée et ce signal de confiance implicite pour neutraliser toutes les protections normalement associées à la désactivation de l’AutoType.

Aucune authentification n’est requise. Aucune interaction utilisateur. Aucune bibliothèque de gadgets externes. La configuration par défaut de Fastjson 1.x est vulnérable. Les versions de Spring Boot 2.x, 3.x et 4.x sur JDK 8, 11, 17 et 21 sont toutes concernées.

Les méthodes exposées incluent JSON.parse, JSON.parseObject(String) et JSON.parseObject(String, Class) — autrement dit, tout endpoint qui accepte du JSON non filtré et le parse avec Fastjson 1.x constitue une surface d’attaque immédiate. Même spécifier une classe cible explicite lors de la désérialisation ne neutralise pas complètement la vulnérabilité : un attaquant peut placer une charge utile malveillante dans un champ typé Object ou Map.

Une exploitation réussie permet à l’attaquant d’exécuter du code arbitraire avec les privilèges du processus Java. Cela signifie : déploiement de web shells, exfiltration de données, vol de secrets, mouvement latéral, ou compromission totale du serveur sous-jacent.

Fastjson 1.x est mort, et ça change tout

Ce qui distingue CVE-2026-16723 d’une faille zero-day classique — même critique — c’est l’absence totale de perspective de correctif. La vulnérabilité est architecturale : elle est enracinée dans le mécanisme de désérialisation non sécurisé qui constitue le cœur même de Fastjson 1.x. Aucun hotfix ne peut la corriger sans casser le comportement de l’API existante pour l’ensemble des utilisateurs.

Alibaba a officiellement arrêté la maintenance de la branche 1.x. La version 1.2.83 est la release terminale de cette lignée. Le message du mainteneur est sans ambiguïté : Fastjson 1.x ne sera pas patché, point final.

La correction permanente — la seule — est la migration vers Fastjson 2.x, une bibliothèque intégralement réécrite avec une API différente. Fastjson 2.x utilise une architecture de résolution de types radicalement distincte :

• Aucune résolution de ressources sur des noms de classes contrôlés par l’utilisateur
• Aucun usage de @JSONType comme signal de confiance
• Un modèle allowlist-first pour la désérialisation polymorphique, au lieu du modèle blocklist historiquement poreux de la branche 1.x

Mais cette migration est un chantier d’ingénierie. Elle exige des modifications de code à chaque point où l’application invoque les API de parsing ou de sérialisation — un effort non trivial dans les codebases importantes, et critique dans les systèmes financiers où le code de traitement des transactions est soumis à des procédures de tests et de gestion du changement rigoureuses. Dans une banque, migrer Fastjson n’est pas un ticket Jira parmi d’autres : c’est un projet transverse qui touche la couche de sérialisation de dizaines de services.

Services financiers, santé, retail : les secteurs sous attaque

Imperva et ThreatBook ont confirmé l’exploitation active de CVE-2026-16723 à partir du 24 juillet 2026, soit trois jours après la publication de l’avis de sécurité Alibaba. Les attaques se concentrent sur quatre secteurs :

• Services financiers — banques, systèmes de paiement, plateformes fintech, assureurs
• Santé — dossiers patients électroniques, systèmes cliniques sur Spring Boot
• Commerce de détail — plateformes e-commerce à fort volume transactionnel
• Informatique et services aux entreprises — fournisseurs SaaS, infrastructures backend

Géographiquement, l’activité est massivement concentrée sur les États-Unis, avec des campagnes secondaires détectées à Singapour et au Canada. Imperva précise qu’environ 30 % du trafic d’exploitation provient d’outils automatisés écrits en Ruby et Go — des scanners et frameworks d’exploitation qui parcourent Internet à la recherche de cibles vulnérables. Les 70 % restants utilisent des user-agents imitant les navigateurs pour se fondre dans le trafic légitime.

La concentration dans les services financiers n’est pas un hasard statistique. Fastjson 1.x est massivement déployé dans les infrastructures backend Java des systèmes bancaires, des processeurs de paiement et des applications fintech, là où le parsing JSON à haute performance est une charge de travail centrale. Le packaging fat JAR de Spring Boot — le modèle de déploiement sous lequel l’exploit fonctionne le plus directement — est l’approche standard pour les backends financiers orientés microservices.

Le secteur de la santé présente un risque aggravé pour une raison réglementaire. Les systèmes de production manipulant des dossiers patients (HIPAA aux États-Unis, RGPD en Europe, HDS en France) sont soumis à des exigences de conformité qui allongent mécaniquement le délai entre l’identification d’une dépendance vulnérable et le déploiement d’une correction. Dans un hôpital, on ne redémarre pas un service clinique un mardi après-midi — ce délai supplémentaire est précisément la fenêtre que les attaquants exploitent.

Que faire ce matin : les trois actions

1. Activer SafeMode — dans l’heure

L’atténuation immédiate consiste à activer le SafeMode de Fastjson. Cette option désactive le mécanisme de désérialisation non sécurisé que CVE-2026-16723 exploite, sans modifier le comportement applicatif pour la majorité des charges de travail — SafeMode bloque le vecteur d’attaque sans casser le parsing JSON standard.

Deux méthodes, au choix selon votre capacité à modifier le code :

# Option 1 : flag JVM au démarrage (sans modification de code)
java -Dfastjson.parser.safeMode=true -jar mon-application.jar

# Option 2 : activation programmatique au point d’entrée
ParserConfig.getGlobalInstance().setSafeMode(true);

Alternative si vous ne pouvez pas redémarrer immédiatement : utilisez l’artefact com.alibaba:fastjson:1.2.83_noneautotype, qui supprime à la compilation le code vulnérable lié à l’AutoType. Cette approche nécessite un rebuild et un redéploiement, mais elle est définitive pour la branche 1.x.

Ne négociez pas le délai. Si votre politique de maintenance vous interdit de redémarrer sans fenêtre, planifiez cette fenêtre comme une intervention d’urgence — incident de sécurité. L’exploitation active est confirmée depuis le 24 juillet et s’intensifie à mesure que les PoC circulent.

2. Auditer chaque dépendance — directe et transitive

Fastjson 1.x est souvent présent dans les arbres de dépendances sans référence explicite dans le code applicatif. Il peut être tiré par un framework, une bibliothèque de logging, un connecteur base de données, un SDK tiers.

# Maven — arbre des dépendances filtré
mvn dependency:tree -Dincludes=com.alibaba:fastjson

# Gradle — toutes les configurations
gradle dependencies --configuration runtimeClasspath | grep -i fastjson

# Scan de fat JARs existants (urgence, sans rebuild)
find /opt/apps -name "*.jar" -exec sh -c 'jar tf "$1" 2>/dev/null | grep -qi fastjson && echo "TROUVÉ : $1"' _ {} \;

En parallèle, inspectez les logs applicatifs et les logs WAF pour les signatures d’exploitation :

• Champs @type dans les payloads JSON — particulièrement ceux contenant des URLs
• Patterns jar:http:// et jar:file:// — signatures du contournement de JAR imbriqués
• Connexions sortantes inexpliquées depuis le processus Java
• Créations de fichiers inattendues dans les répertoires temporaires

3. Planifier la migration vers Fastjson 2.x — avec un deadline

Une fois SafeMode activé, la migration vers Fastjson 2.x devient un projet d’ingénierie planifié avec un calendrier agressif, pas un élément de backlog maintenance. Chaque jour d’opération sur Fastjson 1.x sans SafeMode représente une exposition à une RCE en une requête, sans authentification, sans prérequis.

La migration suit un plan standard :

• Remplacer la dépendance Maven/Gradle : com.alibaba:fastjson → com.alibaba.fastjson2:fastjson2
• Adapter les appels d’API — les packages changent (com.alibaba.fastjson → com.alibaba.fastjson2)
• Tester les régressions de sérialisation/désérialisation sur les objets métier
• Déployer progressivement par service, en commençant par les plus exposés

Fastjson 2.x propose un module de compatibilité qui émule une partie de l’API 1.x, mais il ne couvre pas tous les cas. Les tests de non-régression sont impératifs — surtout si votre application utilise la sérialisation personnalisée ou des type references avancés.

Verdict

Vous utilisez Fastjson 1.x en production. Activez SafeMode dans l’heure via le flag JVM -Dfastjson.parser.safeMode=true. C’est une manipulation sans impact fonctionnel sur le parsing JSON standard — elle bloque uniquement le vecteur d’attaque de CVE-2026-16723. Redémarrez vos services par lot si vous devez le faire sans interruption, mais faites-le aujourd’hui.

Vous avez identifié une exploitation dans vos logs. Considérez le serveur comme compromis. Isolez-le du réseau, déclenchez votre processus d’incident, forensiquez le système de fichiers et les connexions sortantes. Un attaquant qui a exécuté du code arbitraire sur un backend Java a pu déposer des web shells, exfiltrer des secrets, ou établir une persistance.

Vous planifiez vos migrations techniques pour le trimestre. Remontez Fastjson 2.x en priorité absolue. La branche 1.x ne recevra jamais de correctif — c’est une certitude, pas une hypothèse. Imperva et ThreatBook observent des attaques actives ciblant les services financiers, la santé et le retail aux États-Unis, avec une expansion géographique prévisible. Le risque n’est pas théorique : il est mesuré, sectorisé, et il augmente.

La bonne nouvelle : Fastjson 2.x est plus performant que la branche 1.x, plus sûr par conception, et compatible avec l’essentiel de l’API legacy via son module de compatibilité. La migration est documentée, les gains en sécurité sont définitifs, et le coût de l’inaction — une RCE non authentifiée, sans correctif, sur vos backends Java — est simplement inacceptable.

Références

• Alibaba — Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83, 21 juillet 2026
• Imperva — Customers Protected Against CVE-2026-16723: Critical FastJson 1.x Zero-Day RCE, 24 juillet 2026
• FearsOff Cybersecurity — Fastjson 1.2.83 RCE Research, 21 juillet 2026
• The Hacker News — Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patch Available, 25 juillet 2026
• Cyber Security News — Hackers Exploiting FastJson RCE 0-Day in the Wild to Attack US-based Organizations, 28 juillet 2026
• Daily Security Review — Fastjson 1.x Zero-Day CVE-2026-16723 Under Active Exploit, No Patch, 28 juillet 2026
• NVD — CVE-2026-16723 Detail