La faille Fastjson exploitée dans les applications Spring Boot permet une exécution de code à distance non authentifiée, et aucun correctif n’est disponible pour la branche 1.x. Des attaques ont déjà été observées en production : ce tutoriel explique comment identifier vos applications vulnérables, appliquer une mitigation immédiate et durcir durablement votre chaîne de désérialisation Java.
Pourquoi la faille Fastjson menace vos applications Spring Boot
Fastjson est une bibliothèque de sérialisation JSON très répandue dans l’écosystème Java, souvent embarquée comme dépendance transitive sans que l’équipe de développement en ait conscience. La branche 1.x active par défaut un mécanisme d’AutoType qui instancie des classes Java arbitraires à partir du champ @type présent dans le JSON reçu.
Concrètement, un attaquant qui atteint un endpoint acceptant du JSON — un webhook, une API REST publique, un formulaire — peut faire instancier une classe « gadget » présente dans votre classpath et déclencher une exécution de code sous l’identité du processus applicatif. Aucune authentification n’est requise. C’est le scénario le plus défavorable pour une PME-ETI : la faille Fastjson transforme un service métier exposé en point d’entrée réseau complet.
- Impact : RCE non authentifiée, souvent avec les droits du service applicatif.
- Exposition : toute application Spring Boot embarquant Fastjson 1.x, y compris en dépendance indirecte.
- Difficulté d’exploitation : faible, des chaînes de gadgets publiques circulent depuis des années.
- Correctif éditeur : absent sur 1.x — la migration est la seule voie propre.
Étape 1 — Inventorier vos dépendances Fastjson
On ne corrige pas ce que l’on ne voit pas. Commencez par un inventaire exhaustif, y compris les dépendances transitives.
Avec Maven
Depuis la racine de chaque projet, listez l’arbre de dépendances et filtrez sur la bibliothèque :
mvn dependency:tree -Dincludes=com.alibaba:fastjson- Notez la version exacte et le module parent qui l’introduit.
Avec Gradle
./gradlew dependencies --configuration runtimeClasspath | grep -i fastjson
Sur les artefacts déjà déployés
Les JAR en production sont la source de vérité. Inspectez-les directement sur les serveurs :
find / -name "fastjson*.jar" 2>/dev/nullunzip -l votre-app.jar | grep -i fastjsonpour les fat-JAR Spring Boot.
Constituez un tableau simple : application, version de Fastjson, exposition réseau (interne ou Internet), criticité métier. Cette matrice pilotera l’ordre de vos remédiations.
Étape 2 — Mitigation immédiate sans redéploiement lourd
Si la migration ne peut pas être livrée dans les heures qui suivent, réduisez la surface d’attaque dès maintenant. Ces mesures sont cumulables.
Désactiver AutoType explicitement
Au démarrage de l’application, forcez la désactivation du mécanisme responsable :
- Propriété JVM :
-Dfastjson.parser.safeMode=true - Ou dans le code d’initialisation :
ParserConfig.getGlobalInstance().setSafeMode(true);
Le mode safeMode refuse tout champ @type, quelle que soit la classe visée. Testez en recette : certaines applications reposent volontairement sur le typage polymorphe et casseront. C’est justement le signal qu’il faut refactorer.
Filtrer en amont au niveau du reverse proxy
Sur votre NGINX, HAProxy ou WAF, bloquez les corps de requête contenant la signature d’exploitation. Un filtre sur la chaîne "@type" dans les requêtes JSON arrête la majorité des tentatives opportunistes. Ce n’est pas une protection suffisante à elle seule, mais elle achète du temps et génère des journaux exploitables.
Réduire le rayon d’action du processus
- Faites tourner l’application sous un compte de service dédié, jamais en
root. - Restreignez les flux sortants du serveur applicatif : la plupart des chaînes de gadgets exigent un rappel réseau (LDAP, RMI, HTTP) vers l’infrastructure de l’attaquant.
- Activez un durcissement systemd :
NoNewPrivileges=yes,PrivateTmp=yes,ProtectSystem=strict.
Étape 3 — Migrer pour éliminer la faille Fastjson
La correction durable consiste à quitter la branche 1.x. Deux trajectoires réalistes :
- Migration vers Fastjson 2.x : l’API a changé (
com.alibaba.fastjson2), le modèle de sécurité est nettement plus restrictif par défaut. Effort modéré, gain immédiat. - Migration vers Jackson : c’est le sérialiseur natif de Spring Boot, déjà présent dans votre classpath. Supprimer Fastjson réduit d’autant votre surface d’attaque et votre dette de dépendances.
Dans les deux cas, encadrez le chantier : tests de non-régression sur les contrats d’API, revue des points où du JSON externe est désérialisé, et interdiction explicite du typage polymorphe sur les entrées non fiables.
Étape 4 — Détecter les tentatives d’exploitation
Partez du principe que vos applications exposées ont déjà été sondées. Recherchez les traces suivantes dans votre SIEM :
- Requêtes HTTP dont le corps contient
@typeassocié à des classes de typeJdbcRowSetImpl,TemplatesImplou des chaînes JNDI (ldap://,rmi://). - Connexions sortantes inhabituelles depuis un serveur applicatif Java vers Internet, en particulier sur des ports non standard.
- Processus enfants d’une JVM : un
bash,sh,curlouwgetlancé parjavaest un signal fort de compromission. - Écritures de fichiers dans les répertoires temporaires ou les dossiers de déploiement web.
Une règle de corrélation simple — JVM générant un shell — capture la phase post-exploitation quelle que soit la chaîne de gadgets utilisée. C’est le type de détection comportementale que notre SOC agentique priorise, plutôt qu’une signature spécifique à une bibliothèque.
Ce qu’il faut retenir sur la faille Fastjson
La faille Fastjson illustre un schéma récurrent : une dépendance transitive oubliée, une fonctionnalité de confort activée par défaut, et une branche abandonnée par l’éditeur. La séquence est toujours la même — inventorier, mitiger en quelques heures, migrer en quelques jours, détecter en continu. Les organisations qui savent répondre en moins d’une heure à ce type d’alerte sont celles qui ont déjà cartographié leurs dépendances avant l’incident. Pour aller plus loin sur cette compression du délai de correction, lisez notre analyse sur la réduction de la fenêtre de patch, et notre retour d’expérience sur les RCE non authentifiées.