En avril 2025, Orange Cyberdefense a découvert une vulnérabilité critique dans Craft CMS lors d'une enquête sur un incident, désormais référencée sous le numéro CVE-2025-32432. Cette faille permet l'exécution de code à distance (RCE) sans authentification et a reçu la note maximale de 10,0 (critique) selon le score CVSS v3.1 de la NVD (National Vulnerability Database).
Dans le cadre du programme de bourses d'études supérieures en cybersécurité des infrastructuresOPSWAT , nos boursiers ont mené une étude approfondie de cette vulnérabilité, notamment en reproduisant l'exploit, en validant son impact, en évaluant les risques organisationnels et en analysant les stratégies de protection recommandées.
Ce blog propose une analyse approfondie et complète de la vulnérabilité CVE-2025-32432, en examinant sa cause première, son mode d'exploitation et ses implications plus larges en matière de sécurité, tout en offrant des conseils pratiques aux entreprises pour se défendre contre cette menace.
CVE-2025-32432 Introduction
CVE-2025-32432 affecte les versions 3.0.0-RC1 à 3.9.14, 4.0.0-RC1 à 4.14.14 et 5.0.0-RC1 à 5.6.16 de Craft CMS. Classée CWE-94 : injection de code, cette faille résulte d'une mauvaise gestion des entrées non fiables, permettant finalement une exécution de code à distance non authentifiée.
Craft CMS et le framework Yii
Craft CMS est un système de gestion de contenu moderne qui permet aux développeurs et aux équipes de contenu de créer des sites Web flexibles et entièrement personnalisés plutôt que de s'appuyer sur des modèles rigides et prédéfinis. Adopté par plus de 46 000 sites Web à travers le monde, il est à la fois largement utilisé et fréquemment ciblé par les pirates à la recherche de vulnérabilités à fort impact.
Craft CMS est basé sur le framework Yii, un framework PHP rapide et puissant conçu pour le développement web moderne. Yii fournit la structure et les outils de base, tandis que Craft CMS les complète pour offrir un système de gestion de contenu flexible.
L'une des principales fonctionnalités du framework Yii est son conteneur d'injection de dépendances (DI). L'injection de dépendances est un modèle de conception qui fournit aux composants les ressources dont ils ont besoin, au lieu de leur demander de construire eux-mêmes ces ressources. Le conteneur DI de Yii est très flexible et capable de construire des objets complexes à partir de règles de configuration relativement simples.
Cependant, cette flexibilité comporte des risques. Dans le cas de CVE-2025-32432, le conteneur DI a été utilisé de manière abusive en combinaison avec des entrées utilisateur non fiables, créant ainsi une voie d'accès à l'exécution de code à distance. Ce cas démontre que même les fonctionnalités sûres et puissantes d'un framework peuvent devenir dangereuses si elles sont intégrées sans une compréhension complète de leurs implications en matière de sécurité.
Analyse approfondie de CVE-2025-32432
Craft CMS comprend une fonctionnalité appelée Image Transforms, conçue pour optimiser les performances en générant des images redimensionnées directement sur le serveur. Au lieu de fournir une image volumineuse de 4,5 Mo à afficher sous forme de vignette 300×300, Craft CMS crée et fournit automatiquement une version optimisée plus petite. Cette approche réduit l'utilisation de la bande passante et améliore considérablement la vitesse de chargement des pages.
Pour rendre cette fonctionnalité largement accessible, Craft CMS expose le point de terminaison actions/assets/generate-transform sans exiger d'authentification. Si cela permet aux utilisateurs authentifiés et anonymes de bénéficier d'images optimisées, cela introduit également une surface d'attaque accessible au public, où n'importe qui peut fournir des données spécialement conçues à l'application.
Grâce à une analyse détaillée de ce flux de travail, nos collègues ont identifié que la méthode AssetsController::actionGenerateTransform est invoquée chaque fois qu'une requête POST est envoyée au point de terminaison exposé. Cette fonction récupère le paramètre handle directement dans le corps de la requête et le transmet en aval pour un traitement ultérieur à l'étape suivante.
À l'étape suivante, la méthode ImageTransforms::normalizeTransform() est appelée. Cette méthode prend le paramètre handle fourni par l'utilisateur et le convertit en un objet ImageTransform. Étant donné que l'objet est créé directement à partir d'une entrée non fiable, cela représente un point critique de risque dans le flux d'exécution.
Au cours de ce processus, toutes les paires clé-valeur du tableau $transform contrôlé par l'utilisateur (provenant du paramètre handle) sont fusionnées dans un tableau de configuration. La méthode normalizeTransform transmet ensuite ce tableau à Craft::createObject(), qui est chargé d'instancier un nouvel objet ImageTransform.
La vulnérabilité provient de la manière dont Craft::createObject() (qui encapsule Yii::createObject() de Yii) traite les tableaux de configuration. Étant donné que ce mécanisme utilise le conteneur DI pour instancier et configurer des objets directement à partir du tableau non validé, les attaquants peuvent prendre le contrôle du processus de construction des objets.
Lorsqu'une charge utile malveillante est transmise, le constructeur de l'objet (hérité de la classe Model ) invoque la méthode App::configure().
Cette méthode itère sur chaque propriété du tableau contrôlé par l'attaquant et les attribue au nouvel objet.
When App::configure() assigns properties from the attacker-controlled configuration array, most keys are mapped directly onto the object. However, if a key begins with the prefix as, the assignment is routed through Component::__set, Yii’s magic setter. This method interprets as <name> as an instruction to attach a behavior (mixin) to the object.
Une telle charge utile malveillante peut être conçue pour exploiter la manière dont Component::__set traite les propriétés préfixées par « as », comme dans l'exemple suivant:
D'après notre analyse, la mise en œuvre de Component::__set comprend une mesure de sécurité : lorsqu'un comportement est associé à une telle propriété, le framework vérifie que la classe spécifiée dans le tableau de configuration est une sous-classe valide de yii\base\Behavior. Cette vérification vise à empêcher que des classes arbitraires soient directement associées à des composants.
Cependant, cette protection n'est pas aussi efficace qu'elle le paraît. La faiblesse provient de la manière dont Yii::createObject gère les tableaux de configuration.
Lors de l'instanciation d'un objet, Yii::createObject donne la priorité au paramètre spécial __class. Si cette clé est présente, sa valeur est utilisée comme classe cible pour l'instanciation, et la clé de classe standard dans le tableau de configuration est ignorée.
L'attaquant peut créer une charge utile pour le comportement d'exploitation qui comprend deux clés :
- « class » => « \craft\behaviors\FieldLayoutBehavior » - Une classe légitime qui étend yii\base\Behavior. Cette valeur existe uniquement pour satisfaire la vérification is_subclass_of dans Component::__set, permettant à l'exécution de se poursuivre sans générer d'erreur.
- '__class' => '\yii\rbac\PhpManager' - La cible réelle de l'attaquant. Il s'agit de la classe « gadget » qu'il souhaite instancier.
Lorsque le code est exécuté, Component::__set passe le contrôle de sécurité car il inspecte uniquement la clé de classe. Cependant, lorsque le framework appelle ensuite Yii::createObject pour attacher le comportement, il donne la priorité à __class, ce qui entraîne l'instanciation de l'objet \yii\rbac\PhpManager choisi par l'attaquant.
L'utilisation de \yii\rbac\PhpManager est intentionnelle. La simple création d'un objet ne suffit pas pour l'exploitation ; pour parvenir à un RCE, il faut une classe gadget avec des effets secondaires pouvant être utilisés comme arme. PhpManager est une cible courante dans les attaques POI (PHP Object Injection) en raison de son flux d'initialisation. Lors de l'instanciation, sa méthode init() appelle load(), qui invoque ensuite loadFromFile($this->itemFile). En contrôlant $this->itemFile, un attaquant peut forcer l'application à charger un fichier malveillant, transformant ainsi la création d'objet en exécution de code.
Le danger réside dans la méthode loadFromFile. En PHP, une instruction require exécute le fichier cible en tant que code. Ainsi, si un attaquant contrôle le chemin d'accès au fichier, il peut déclencher l'exécution d'un code arbitraire.
Pour placer du code malveillant sur le serveur, l'attaquant exploite les fichiers de session PHP. En injectant du PHP dans un paramètre de requête, Craft CMS enregistre la charge utile dans un fichier de session pendant le processus de redirection. Plus tard, lorsque PhpManager charge ce fichier, le code de l'attaquant peut être exécuté.
La chaîne d'attaque complète fonctionne en trois étapes. Tout d'abord, l'attaquant implante un code PHP malveillant en envoyant une URL spécialement conçue, que Craft CMS enregistre dans un fichier de session. Ensuite, il exploite le contournement __class dans le point de terminaison de transformation d'image pour charger le gadget PhpManager et le diriger vers le fichier de session infecté. Enfin, lorsque PhpManager charge le fichier, la charge utile de l'attaquant s'exécute, lui accordant un RCE et le contrôle total du serveur, souvent via un webshell ou un reverse shell.
Atténuation et remédiation
Pour atténuer efficacement les risques associés à CVE-2025-32432, les organisations doivent disposer d'une visibilité et d'un contrôle sur leurs composants open source. Sans un inventaire clair des composants, l'application de correctifs relève de la conjecture.
OPSWAT , une technologie exclusive intégrée àla plateforme MetaDefender®, répond à ce besoin en fournissant un inventaire de tous les composants logiciels, bibliothèques, conteneurs Docker et dépendances utilisés. Elle permet aux organisations de suivre, sécuriser et mettre à jour leurs composants de manière proactive.
Dans l'exemple ci-dessus,la technologie SBOM de MetaDefender a analysé le package nginx-ingress-controller qui contenait la vulnérabilité CVE-2025-32432. Le système a automatiquement signalé le problème comme critique et a fourni des conseils sur les versions corrigées disponibles, permettant aux équipes de hiérarchiser rapidement les priorités et de corriger la vulnérabilité avant qu'elle ne puisse être exploitée.
OPSWAT est disponible dans MetaDefender Core et MetaDefender Software Chain™,ce qui permet aux équipes de sécurité d'identifier et de traiter plus rapidement les vulnérabilités. Avec OPSWAT , les équipes de sécurité peuvent :
- Localisez rapidement les composants vulnérables - Identifiez immédiatement les composants open source affectés par les attaques de désérialisation. Cela permet d'agir rapidement pour corriger ou remplacer les bibliothèques vulnérables.
- Assurez-vous que les correctifs et les mises à jour sont proactifs - Surveillez en permanence les composants open source à l'aide OPSWAT afin de garder une longueur d'avance sur les vulnérabilités liées à la désérialisation. OPSWAT peut détecter les composants obsolètes ou non sécurisés, ce qui permet d'effectuer des mises à jour en temps opportun et de réduire l'exposition aux attaques.
- Maintenir la conformité et la déclaration – OPSWAT aide les organisations à respecter les exigences de conformité, alors que les cadres réglementaires imposent de plus en plus la transparence dans les chaînes d'approvisionnement logicielles.
Prêt à renforcer votre chaîne logistique logicielle contre les menaces émergentes ?
