La classe fantôme : Utilisation de l'injection de conteneur CVE-2025-32432 Yii2 dans le CMS Craft

Dans la hiérarchie des vulnérabilités de PHP, Injection de dépendance (DI) Injection de conteneur se situe au sommet - complexe à détecter, élégante à exploiter et d'un impact dévastateur.

La divulgation de CVE-2025-32432 ciblage Artisanat CMS (et, par extension, les Cadre Yii2) nous rappelle brutalement que lorsque l'utilisateur contrôle l'instanciation de la classe, l'application appartient à l'attaquant.

Alors que de nombreux scanners de sécurité signalent ce problème comme un "problème de configuration", les ingénieurs d'élite en sécurité le reconnaissent pour ce qu'il est vraiment : Exécution de code à distance (RCE) par le biais d'une désérialisation d'objet non sécurisée. Cet article procède à une autopsie technique de la vulnérabilité, en reconstituant la chaîne des gadgets et en démontrant que l'analyse pilotée par l'IA est le seul moyen de détecter ces failles logiques à grande échelle.

L'architecture de l'échec : A l'intérieur du conteneur Yii2

Pour comprendre CVE-2025-32432, il faut comprendre le cœur de Yii2 : la fonction yii\\\\NContainer.

Craft CMS s'appuie sur le conteneur DI de Yii2 pour gérer les dépendances des classes. Ce conteneur permet aux développeurs de configurer les objets à l'aide de tableaux. Par exemple, le conteneur DI permet aux développeurs de configurer des objets à l'aide de tableaux :

PHP

// Utilisation légitime $object = Yii::createObject(['class' => 'app\models\NUser', 'name' => 'Admin', ]) ;

La vulnérabilité survient lorsqu'un attaquant peut influencer ce tableau de configuration. Si une action du contrôleur prend une entrée JSON brute et la transmet aveuglément à Yii::createObject() ou Yii::$container->set(), l'attaquant peut forcer l'application à instancier des toute classe disponibles dans le chemin d'accès à l'autoload, avec tout bien valeurs.

La surface d'attaque

La faille réside généralement dans les contrôleurs de CMS Craft qui traitent les demandes d'API ou les configurations de plugins où la vérification des entrées se concentre sur les XSS (balises HTML) plutôt que sur la logique (définitions de classes).

• Source : JSON fourni par l'utilisateur (par ex, POST /actions/vulnerable-plugin/save-config).
• L'évier : Yii::createObject($userInput).

Construire la chaîne de la mort : Le PoC

L'exploitation nécessite de trouver un Gadget-une classe qui effectue des opérations dangereuses (comme l'écriture de fichiers ou l'exécution de commandes) dans ses méthodes de cycle de vie (__construire, init, __destructou Réveil).

Dans le contexte de CVE-2025-32432, nous utilisons une chaîne de gadgets commune trouvée dans l'écosystème Yii2 impliquant yii\\rest\NIndexAction ou d'autres classes similaires nécessitant de nombreux appels.

Le concept

Nous voulons instancier une classe qui nous permette d'exécuter une fonction de rappel PHP (comme système ou exécuter) sur un argument fourni.

Charge utile JSON militarisée

On trouvera ci-dessous une démonstration de faisabilité conceptuelle montrant comment déclencher un RCE en injectant une définition de classe malveillante.

JSON

{"rce_trigger" : {"class" : "yii\\\\rest\\\\IndexAction", "checkAccess" : "system", "id" : "rce", "controller" : {"class" : "yii\\\\web\\\\Controller", "id": "dummy" }, "modelClass" : "yii\\\\base\\\\Model", "run" : "id ; uname -a" } }

Répartition de la charge utile :

1. classe: Nous demandons au conteneur DI d'instancier yii\\rest\NIndexAction.
2. Vérifier l'accès: C'est notre propriété dangereuse. Dans ce gadget spécifique, le Vérifier l'accès est conçue pour contenir un objet à appeler. Nous lui attribuons la valeur système.
3. Déclenchement de l'exécution: Lorsque l'application traite cet objet (souvent au cours de l'exécution de l'ordre de priorité), il est possible d'obtenir des informations sur l'objet. exécuter() ou la validation d'une propriété), il invoque la fonction de rappel (callback) stockée dans le fichier Vérifier l'accès avec des arguments fournis par le contexte (ou l'attaquant).
4. Résultat: Le serveur exécute system('id ; uname -a').

Note : Dans un environnement durci, les attaquants pourraient enchaîner avec yii\\caching\\FileCache pour écrire un shell web PHP sur le site web/ répertoire.

Pourquoi les scanners traditionnels n'y parviennent pas

La détection de CVE-2025-32432 est notoirement difficile pour les outils DAST existants.

• Pas de signature : La charge utile est un JSON valide. Il ne contient pas de syntaxe d'injection SQL (OR 1=1) ou des balises XSS ().
• Dépend du contexte : La vulnérabilité ne se trouve pas dans l'entrée elle-même, mais dans le système comment le cadre interprète la classe clé. Un scanner standard ne comprend pas que classe les cartes de Yii::createObject.

Détection pilotée par l'IA : L'avantage de la négligence

C'est ici que Penligent.ai change le paradigme. Penligent utilise Agents d'intelligence artificielle tenant compte du contexte qui comprennent la logique propre au cadre.

1. Reconnaissance du cadre : Les agents de Penligent identifient que la cible utilise Craft CMS / Yii2. Il connaît les "Dangerous Sinks" spécifiques à ce framework (e.g., Yii::createObject).
2. Inférence logique : Au lieu de procéder à une analyse aveugle, l'IA analyse le schéma de l'API. Si elle voit un objet JSON acceptant des paramètres de type configuration, elle injecte intelligemment des "charges utiles de sondage", par exemple en tentant d'instancier une classe bénigne telle que yii\\\\N- VarDumper-pour tester si le conteneur est accessible.
3. Vérification automatisée : Si la sonde réussit (par exemple, l'application se comporte différemment ou renvoie une erreur spécifique indiquant l'instanciation de la classe), Penligent signale le point d'accès comme étant vulnérable aux éléments suivants Injection dans un conteneur et génère la charge utile RCE spécifique pour la validation de la remédiation.

Remédiation et défense

Sécuriser Craft CMS contre CVE-2025-32432 et les attaques DI similaires :

1. Vérification stricte des types : Ne jamais transmettre de tableaux d'entrée utilisateur bruts à Yii::createObject. Il faut toujours s'assurer que le classe est soit absente (codée en dur dans le backend), soit strictement listée.
2. Mise à jour du CMS Craft : Appliquez immédiatement les derniers correctifs. Le fournisseur a probablement renforcé les action afin de rejeter les définitions de classes arbitraires.
3. Désactiver les fonctions dangereuses : Dans votre php.ini, utiliser désactiver_fonctions pour bloquer système, exécuter, passeret proc_open pour atténuer l'impact du CRE.

Conclusion

CVE-2025-32432 est un rappel brutal que les frameworks PHP modernes, bien que puissants, introduisent des surfaces d'attaque complexes. L'injection de conteneur est la "SQL Injection des années 2020" - une faille logique qui permet un contrôle total.

Pour les ingénieurs en sécurité, la leçon est claire : si vous laissez les utilisateurs définir les objets, ils définiront votre destruction. Il ne suffit plus de valider la "forme" des données, il faut en valider le "type".

Références fiables

• Guide de sécurité du framework Yii2
• Avis de sécurité de Craft CMS
• OWASP : Aide-mémoire sur la désérialisation
• NIST NVD - CVE-2025-32432