pescada-dev/cve-2025-61505Désérialisation non sécurisée dans e107 CMS install.php
Signalé : 18 septembre 2025
CVE attribué : 9 octobre 2025
Publié : 2 février 2026
Identifiant CVE : CVE-2025-61505
Découvreur : Anas Abderrahman Benbarek
Une vulnérabilité d'injection d'objets PHP (CWE-502 : Désérialisation de données non fiables) a été découverte dans le script d'installation (install.php) d'e107 CMS version 2.3.3.
La vulnérabilité permet à des attaquants distants non authentifiés de fabriquer des données sérialisées malveillantes, pouvant potentiellement conduire à une exécution de code arbitraire, une manipulation de données ou d'autres actions malveillantes — selon la présence de classes gadgets exploitables dans la base de code d'e107 ou ses dépendances.
Ce problème provient de l'utilisation dangereuse de la fonction PHP unserialize() sur une entrée contrôlée par l'utilisateur, sans aucune restriction (comme l'option allowed_classes). Bien que limité à la phase d'installation, il présente un risque important lors de la configuration sur des serveurs exposés, car le programme d'installation gère des opérations sensibles telles que la création de base de données et l'écriture de fichiers.
install.php)Le processus d'installation d'e107 CMS se déroule en plusieurs étapes. Les saisies utilisateur (langue, informations d'identification de la base de données, détails administrateur, etc.) sont conservées d'une étape à l'autre à l'aide d'un tableau sérialisé stocké dans le paramètre previous_steps de type POST. Ces données sont encodées en base64 pour la transmission et décodées/désérialisées sur le serveur.
Le problème principal est le passage direct de l'entrée utilisateur décodée à unserialize() sans validation, assainissement ni liste blanche de classes. Cela se produit à deux endroits :
if(isset($_POST['previous_steps']))
{
$tmp = unserialize(base64_decode($_POST['previous_steps']));
$override = (isset($tmp['paths']) && isset($tmp['paths']['hash'])) ? array('site_path'=>$tmp['paths']['hash']) : array();
unset($tmp);
}
Le script suppose que previous_steps contient des données sérialisées fiables provenant des étapes précédentes du formulaire. Mais comme il s'agit d'un simple paramètre POST, un attaquant le contrôle entièrement. base64_decode() transforme l'entrée en binaire, et unserialize() la reconstruit en objets ou tableaux PHP. Si l'entrée contient une notation d'objet (commençant par O:), PHP instancie ces classes si elles existent dans la portée actuelle ou sont chargées automatiquement. Cela peut immédiatement déclencher __wakeup() ou d'autres méthodes magiques, entraînant potentiellement des effets secondaires comme l'écriture de fichiers ou des appels inattendus à la base de données si des chaînes de gadgets sont présentes.
Note sur l'exploitabilité : Le succès dépend des classes gadgets disponibles. Sans elles, l'impact peut se limiter à des plantages ou à une corruption de données.
if(isset($_POST['previous_steps']))
{
$this->previous_steps = unserialize(base64_decode($_POST['previous_steps']));
// ... (logique de filtrage et de restauration du mot de passe)
unset($_POST['previous_steps']);
}
Cette instance est plus dangereuse car les données désérialisées font partie de l'état de l'objet ($this->previous_steps) et influencent les actions ultérieures du programme d'installation (configuration MySQL, création d'administrateur, génération de fichier de configuration). L'injection d'objets ici peut persister tout au long du processus d'installation et affecter des opérations à privilèges élevés. Là encore, aucune restriction allowed_classes n'est appliquée, ce qui signifie que toute classe chargée automatiquement (noyau, gestionnaires, plugins, bibliothèques) peut être instanciée.
Note sur l'exploitabilité : L'exploitation dans le monde réel nécessite généralement de chaîner plusieurs objets (une « chaîne de gadgets ») pour atteindre un comportement dangereux comme l'exécution de code. Par exemple, le __wakeup() d'une classe pourrait appeler une autre méthode qui évalue des chaînes contrôlées par l'utilisateur. Sans ces chaînes, l'impact pourrait se limiter à un déni de service (par exemple, épuisement des ressources dans les destructeurs). Le contexte à privilèges élevés du programme d'installation (écriture de e107_config.php, création de répertoires) amplifie les risques, mais la suppression du script après installation réduit l'exposition à long terme.
La vulnérabilité est accessible via des requêtes HTTP POST non authentifiées vers /install.php à n'importe quelle étape de la configuration.
install.php — Supprimez ou renommez le script immédiatement après l'installation..htaccess, des règles nginx, ou déplacez le fichier en dehors de la racine web lors du déploiement.unserialize() par json_decode() pour la persistance de l'état, ou au minimum utilisez :unserialize($data, ['allowed_classes' => false]);
Ajoutez une signature/validation HMAC des données pour une intégrité supplémentaire.