Fastjson 1.2.83 peut toujours déclencher une exécution de code à distance sans gadget traditionnel même avec AutoType=false, et a été reproduit dans un environnement isolé JDK 8/17/21/25 + Spring Boot Loader.

Auteur et source de l'article : GCSA

Résumé

Dans le système de défense traditionnel contre les vulnérabilités de désérialisation Java, l'industrie présente généralement les croyances suivantes : « Désactiver AutoType par défaut est sécurisé », « Fixer le deuxième paramètre de parseObject (type cible principal) est sécurisé », « Éliminer les dépendances Gadget de désérialisation du Classpath local est sécurisé ». Cependant, les dernières évolutions techniques en matière d'attaque et de défense ont complètement dissipé ces illusions.

L'Alliance mondiale de la cybersécurité (GCSA) publie exclusivement aujourd'hui ce rapport d'analyse technique. Le rapport retrace en profondeur la cause fondamentale permettant d'exploiter une exécution de code à distance (RCE) sans dépendre de Gadget traditionnels, même lorsque Fastjson 1.2.83 est configuré avec AutoType=false. Cette technique d'exploitation a été entièrement reproduite avec succès dans les environnements isolés JDK 8 / 17 / 21 / 25 et Spring Boot Loader. Cette vulnérabilité ne consiste pas en une contournement de liste noire suivi de la recherche de Gadget local, mais transforme directement la logique de détection des métadonnées de classes de Fastjson en canal d'obtention et d'autorisation de classes malveillantes distantes. Voici le texte principal

Organisme de publication : GCSA Global Cybersecurity Alliance

Type de rapport : Analyse technique exclusive / Rapport d'analyse approfondie des vulnérabilités

Date du rapport : 2026-07-21

Statut du rapport : audit du code source et reproductibilité dans un environnement isolé terminés

Numéro de vulnérabilité : Numéro d'étude interne FJ-GETRESOURCE-RCE (ne correspond à aucun CVE publié)

Fastjson 1.2.83 permet toujours d'exploiter une exécution de code à distance sans gadget traditionnel même avec AutoType=false, et cela a été reproduit dans un environnement isolé avec JDK 8/17/21/25 + Spring Boot Loader. Il est recommandé d'activer immédiatement SafeMode et de migrer vers Fastjson 2.x.

1. Résumé exécutif

La méthode ParserConfig.checkAutoType de Fastjson 1.2.83 convertit la valeur @type contrôlée par l'utilisateur en nom de ressource de classe et la transmet à getResourceAsStream du ClassLoader courant :

Dans un environnement ClassLoader fat-jar capable de résoudre des noms de ressources URL absolues, un attaquant peut exploiter la substitution de points pour construire des URL http:, jar:http: et jar:file: afin de télécharger depuis l'extrémité attaquante une classe malveillante annotée avec @JSONType. Fastjson, en détectant cette annotation, appelle loadClass et retourne directement la classe avant d'effectuer les vérifications de classe de base dangereuse et de compatibilité de type cible. La classe est alors instanciée et initialisée, permettant l'exécution de code arbitraire.

Cette exploitation ne dépend pas de gadgets de désérialisation traditionnels déjà présents dans le classpath cible et peut toujours être déclenchée dans l'état par défaut de Fastjson AutoType=false. La fixation du type cible de JSON.parseObject ne peut pas empêcher l'exécution ; l'activation de SafeMode peut bloquer les chemins d'exploitation normaux avant l'accès aux ressources.

Ce rapport a été reproduit dans un conteneur Linux isolé en utilisant le même payload JSON :

2. Évaluation des vulnérabilités

Il n'est pas recommandé de délivrer un CVSS 9.8 uniforme uniquement sur la base de la version du composant : le ClassLoader App normal est un témoin négatif ; la chaîne complète moderne de JDK dépend également d'un ClassLoader capable d'analyser deux URL JAR absolues et /proc/self/fd. Dans les environnements positifs décrits dans ce rapport, l'exploitation de la vulnérabilité permet un RCE réseau sans authentification.

3. Portée et conditions préalables

• Confirmation en temps réel : Fastjson 1.2.83
• JDK confirmé : 8, 17, 21, 25
• Système d'exploitation confirmé : Linux ; macOS a également reproduit JDK 17/21/25 en utilisant /dev/fd
• loader confirmation : Spring Boot 2.7.18 classic loader + JDK 8 ; Spring Boot 3.2.0 loader + JDK 17/21/25
• Confirmation de l'API : JSON.parse et JSON.parseObject avec types de niveau supérieur fixés

Les versions 1.2.68–1.2.83 dans la description externe sont plus appropriées comme plage de test connue plutôt que comme versions d'introduction de la vulnérabilité. L'analyse du code source indique que le code décisif de détection des ressources de classe existait déjà dans les versions 1.2.67 et 1.2.68. Ce rapport n'a effectué une vérification complète sur tous les environnements d'exécution JDK que pour la version 1.2.83.

1. L'attaquant peut contrôler le JSON transmis à Fastjson, et le @type dans l'entrée sera analysé.

2. SafeMode n'est pas activé.

3. Le ClassLoader de Fastjson peut résoudre le nom de ressource absolu construit en URL.

4. Le processus victime peut se connecter au service HTTP de l'attaquant.

5. Les chaînes Linux modernes nécessitent que /proc/self/fd soit lisible et que le chargeur puisse l'analyser

jar:file:/proc/self/fd/N!...。

1. JDK doit être en mesure de créer un cache temporaire distant JAR normal ; cela signifie généralement que le répertoire temporaire de la JVM est accessible en écriture.

L'attaquant n'a pas besoin :

• Écriture d'un fichier dans le classpath cible
• Le classpath cible précharge les gadgets TemplatesImpl, JNDI, C3P0, Commons Collections, etc.
• Activer Fastjson AutoType
• Contrôlez le deuxième paramètre de JSON.parseObject

4. Analyse de la cause racine

Emplacement du code source :

Code principal :

Cette logique suppose que resource est simplement un chemin classpath, sans restreindre son protocole, sa sémantique de chemin absolu ou sa source. Pour un chargeur fat-jar spécifique, les entrées suivantes deviendront une URL absolue après remplacement :

Ainsi, getResourceAsStream charge des ressources réseau contrôlées par l'attaquant en dépassant les limites de la requête de métadonnées locales.

Fastjson utilise son propre ClassReader ASM pour analyser le contenu des ressources :

L'attaque nécessite simplement que la classe distante soit annotée avec @JSONType de Fastjson pour définir jsonType sur true. Cette vérification porte sur les octets fournis par l'attaquant, et non sur une classe déjà chargée depuis un classpath de confiance.

Emplacement du code source :

TypeUtils.loadClass tente successivement le loader explicite, le loader du contexte du thread et Class.forName. Dans un environnement positif, le loader du contexte du thread réanalyse le même nom de ressource absolu, télécharge la classe et exécute defineClass.

Emplacement du code source :

• Les vérifications de classe de base dangereuse ne sont pas effectuées
• expectClass.isAssignableFrom(clazz) ne sera pas exécuté
• Le type de liaison de données fixes ne peut pas empêcher l'exécution avant l'initialisation de la classe

Emplacement du code source :

La vérification SafeMode est effectuée avant l'accès à la ressource :

5. Détails de l'utilisation de la chaîne

Forme la plus courte :

JDK 17+ effectuera également les requêtes réseau, mais refusera les segments de chemin vides dans les noms internes,

Le premier élément du tableau du payload unique :

JDK 17+ refuse ensuite le nom interne du jar : http://... , mais Fastjson continue d'analyser le tableau en raison du suffixe Exception.

Éléments candidats suivants :

Le premier hit dans les journaux de chargement de classe de JDK 17 est :

• JDK 8 accepte directement le jar de la première phase : http://... class et l'exécute
• Après l'exécution de la commande de la première phase class, une RuntimeException("stage-one-stop") est délibérément levée pour empêcher JDK 8 de continuer à tenter d'utiliser des FD socket/pipe non pertinents.
• JDK 17+ échoue lors de l'initialisation de la classe en raison d'un nom invalide au premier stade, puis revient doucement via une Exception pour entrer dans la phase d'énumération FD

6. Environnement de reproduction et preuves

Output attendu :Le script va :

• Compiler le fat jar victime ;
• Générer un JAR d'attaque avec une classe FD dédiée ;
• Générez une charge utile sous forme de tableau JSON ;
• Démarrer le service HTTP de l'attaquant dans un réseau Docker isolé ;
• Démarrer respectivement les conteneurs affectés de JDK 8/17/21/25 ;
• Vérifiez chaque conteneur mappé vers /tmp/fastjson-getresource-rce.

Burp se contente d'envoyer des JSON vers les interfaces victimes présentant des points d'analyse Fastjson ; le JAR d'attaque doit toujours être fourni par le service HTTP de l'attaquant.

Modèle de demande :

Si l'application utilise un type de niveau supérieur fixe, vous pouvez envelopper le tableau selon la structure des champs, par exemple :

Cette expérience utilise JSON.parseObject(json, BoundEnvelope.class) pour analyser l'enveloppe ci-dessus ; le résultat reste RCE-OK et retourne normalement BoundEnvelope.

Migrez prioritairement vers Fastjson 2.x en maintenance et revalidez toutes les configurations de types polymorphes, AutoType et modes de compatibilité. Ne vous contentez pas de remplacer le JAR sans effectuer de tests de régression.

Configuration du code :

Paramètres JVM :

Remarque : Si l'application a enregistré AutoTypeCheckHandler, il faut auditer ou supprimer ce dernier, car le handler s'exécute avant la vérification SafeMode.

• Ne passez pas directement les demandes non fiables à JSON.parse/JSON.parseObject
• Rejeter tout type de métadonnées spéciales sur la passerelle ou l'entrée de l'application
• Ne pas fixer uniquement les types Java de niveau supérieur n'est pas une protection suffisante, car les objets imbriqués peuvent toujours traiter @type, et le jsonType de cette vulnérabilité retourne tôt pour contourner les vérifications de compatibilité.

Intercepter temporairement les requêtes dont la clé JSON, après décodage, est égale à @type, et remplacer les paramètres d'URL, le corps de la requête et les objets imbriqués. Ne pas rechercher uniquement le texte brut "@type", car le lexer Fastjson décode d'abord les noms de champs, par exemple :

Les règles WAF ne peuvent servir qu'à atténuer les risques et ne remplacent pas la mise à niveau des composants ni le SafeMode.

1. Interdire à la JVM métier d'établir des connexions HTTP/HTTPS vers des adresses externes non nécessaires.
2. Appliquer une stratégie réseau minimale aux conteneurs d'application.
3. Restreindre l'exposition ou l'utilisation de /proc/self/fd lorsque la compatibilité le permet, ou utiliser un sandbox de conteneur plus strict.
4. Auditer le traitement des noms de ressources URL absolues par ClassLoader, en rejetant les protocoles tels que http:, https:, jar:, file: etc.
5. Surveiller les activités anormales dans le répertoire temporaire JVM avec jar_cache*.

8. Suggestions de détection et IOC

Faites particulièrement attention aux valeurs décodées de @type contenant :

L'apparition isolée d'une exception ne suffit pas à déclencher une alerte ; elle doit être analysée en conjonction avec le format du protocole, @type et les candidats FD consécutifs dans le tableau.

• JVM demande un fichier JAR ou .class sans extension à un hôte anormal
• 1 à 3 répétitions de GET/HEAD survenant pendant la même demande d'analyse
• Le chemin de la requête peut contenir /x, /a.class ou des chemins équivalents définis par l'attaquant

• Création du répertoire temporaire JVM jar_cache*
• Le processus Java réouvre son propre fichier via /proc/self/fd/N
• Les journaux class-load affichent des éléments similaires à :

9. Conclusion

Cette vulnérabilité n'est pas un « contournement de liste noire suivi de recherche de gadget local » traditionnel, mais transforme la logique de détection des métadonnées de classe de Fastjson en un canal de récupération et d'autorisation de classes distantes. Le retour anticipé de @JSONType permet d'accepter la classe fournie par l'attaquant avant les vérifications de classe de base dangereuse et de liaison de type ; le canal doux d'échec Exception et le cache temporaire JDK jar:http: étendent les primitives de chargement direct de JDK 8 à JDK 17/21/25.

Ainsi, les jugements courants suivants ne sont pas valables :

• « AutoType est désactivé par défaut, donc sécurisé » — incorrect
• « Fixer le deuxième paramètre de parseObject, donc sécurisé » — invalide
• « La classpath ne contient aucun gadget connu, donc elle est sécurisée » — incorrect
• « JKD 17+ rejette les noms internes http://, donc ce n'est au mieux qu'un SSRF » — incorrect



Dans les déploiements satisfaisant les conditions de chargeur vérifié, réseau et descripteurs de fichiers, ce problème peut évoluer depuis une seule requête JSON non authentifiée vers une exécution de code à distance réelle. Il est prioritaire de migrer vers Fastjson 2.x et d'activer immédiatement SafeMode, tout en resserrant les limites de résolution des ressources de sortie et de ClassLoader.

10. Chemins des pièces jointes et des preuves

Copyright et autorisation de reproduction : Ce rapport et les analyses techniques associées sont publiés exclusivement par le GCSA, Alliance mondiale de cybersécurité. Toute reproduction doit conserver intégralement la source officielle du GCSA et le lien original, et ne doit pas altérer de manière malveillante les points de vue principaux du rapport.

Source : GCSA Alliance mondiale de la cybersécurité

Site officiel : www.gcsa.org