Faille PHP-CGI : comment une vulnérabilité critique a semé le chaos sur Internet

La faille : quand un caractère devient une option de commande

La vulnérabilité CVE-2024-4577 concerne les branches PHP 8.1 antérieures à 8.1.29, PHP 8.2 antérieures à 8.2.20 et PHP 8.3 antérieures à 8.3.8, lorsqu’elles sont utilisées avec Apache et PHP-CGI sous Windows dans certaines configurations linguistiques.

Le problème vient du mécanisme Windows dit de « meilleur ajustement » (Best-Fit). Lorsqu’un caractère Unicode ne peut pas être représenté exactement dans une page de codes locale, Windows peut le remplacer par un caractère approchant. Dans ce contexte, un caractère apparemment inoffensif peut être transformé en tiret, puis interprété par PHP-CGI comme le début d’une option de ligne de commande.

Un attaquant peut alors tenter de modifier le comportement de PHP à travers une requête HTTP : affichage du code source, activation d’options dangereuses ou exécution d’un contenu PHP fourni dans la requête. Aucun compte administrateur n’est nécessaire lorsque la configuration est vulnérable.

Pourquoi cela a rapidement créé du chaos sur Internet

Une vulnérabilité distante, sans authentification, facile à automatiser et présente dans un composant très répandu constitue une cible idéale. Dès qu’une preuve de concept devient publique, des robots parcourent les adresses IP, testent plusieurs variantes d’URL et classent les serveurs qui répondent.

Le danger ne dépend donc pas de la notoriété d’un site. Un petit site associatif, un serveur de test oublié ou une interface accessible uniquement par une URL peu connue peuvent être découverts par balayage automatique. Les attaquants ne cherchent pas d’abord une marque : ils cherchent une réponse technique.

La CISA a ajouté CVE-2024-4577 à son catalogue des vulnérabilités connues comme exploitées le 12 juin 2024, seulement quelques jours après sa publication. Son catalogue indique également un usage connu dans des campagnes de rançongiciel. C’est la différence entre une faiblesse théorique et une urgence opérationnelle.

Les traces qu’une attaque PHP peut laisser

Le fichier malveillant visible n’est parfois que la première étape. Après l’exécution initiale, l’attaquant cherche généralement à conserver l’accès et à survivre à une mise à jour.

• fichiers PHP dans les répertoires d’images ou de téléversement ;
• code obfusqué avec Base64, compression, fonctions dynamiques ou longues chaînes illisibles ;
• comptes administrateurs WordPress créés en série ;
• modification des clés d’authentification ou création de mots de passe d’application ;
• compte Linux possédant des privilèges anormaux ;
• clé SSH ajoutée sans validation ;
• tâche cron, service systemd ou script de démarrage inconnu ;
• processus utilisant fortement le processeur ou connexion sortante inhabituelle ;
• archives et sauvegardes contenant encore le code compromis.

Une base de données peut aussi porter la persistance : comptes administrateurs, options modifiées, contenu injecté ou sessions actives. Comparer uniquement les fichiers avec une sauvegarde ne couvre donc pas tout le périmètre.

Pourquoi supprimer le fichier suspect ne suffit pas

Trois réactions donnent une impression de sécurité sans traiter l’incident :

1. Effacer le webshell et remettre le site en ligne. Une autre porte d’entrée ou un compte caché peut rester actif.
2. Restaurer la dernière sauvegarde. Si la date d’intrusion est inconnue, la sauvegarde peut déjà contenir la compromission.
3. Mettre PHP à jour, puis s’arrêter. Le correctif bloque l’exploitation initiale, mais ne révoque ni les sessions, ni les clés, ni les comptes ajoutés auparavant.

La bonne question n’est pas seulement « le fichier a-t-il disparu ? », mais « l’attaquant dispose-t-il encore d’un moyen de revenir ? ».

La réponse technique efficace, étape par étape

1. Contenir. Réduire l’exposition, isoler le service touché si nécessaire et bloquer les points d’entrée évidents.
2. Préserver les preuves utiles. Copier les journaux et les éléments suspects avec leurs dates et empreintes avant suppression.
3. Mettre à jour PHP. Installer une version corrigée et retirer PHP-CGI lorsque cette architecture n’est pas nécessaire. Sous Linux, PHP-FPM derrière Nginx ou Apache constitue généralement une séparation plus maîtrisable.
4. Contrôler l’intégrité. Comparer le cœur WordPress aux sommes de contrôle officielles, inventorier les extensions, thèmes et fichiers PHP inconnus.
5. Auditer la base. Vérifier les administrateurs, inscriptions, sessions, mots de passe d’application, options et contenus injectés.
6. Auditer le système. Examiner les comptes UID 0, clés SSH, cron, services, processus, ports, fichiers exécutables récents et modifications de paquets.
7. Révoquer les accès. Renouveler les mots de passe, secrets d’application et clés WordPress ; détruire les sessions existantes.
8. Supprimer la persistance. Retirer comptes, tâches, services et fichiers non légitimes, puis redémarrer les services concernés.
9. Vérifier en production. Tester les sites, les formulaires, les API, les en-têtes de sécurité et surveiller les journaux après remise en ligne.

Réduire fortement le risque de récidive

• Maintenir PHP, WordPress, les thèmes et les extensions dans des versions prises en charge.
• Supprimer les extensions inactives et les anciens environnements de démonstration.
• Interdire l’exécution PHP dans les répertoires de téléversement.
• Utiliser try_files ou un équivalent pour ne jamais transmettre à PHP un fichier inexistant.
• Désactiver dans PHP-FPM les fonctions d’exécution système inutiles aux sites hébergés.
• Limiter l’administration par adresse IP, VPN ou authentification forte lorsque c’est possible.
• Utiliser SSH par clé, interdire la connexion root distante et surveiller les tentatives.
• Activer pare-feu, limitation de débit, Fail2Ban ou CrowdSec selon l’architecture.
• Conserver des sauvegardes externes et tester réellement leur restauration.
• Surveiller les nouveaux fichiers PHP, administrateurs, services et ports.

Aucune mesure ne remplace toutes les autres. La sécurité vient de plusieurs couches : correctifs, réduction de surface, permissions, contrôle d’intégrité, journalisation et capacité de restauration.

Sources et références

• NIST NVD — CVE-2024-4577 : versions touchées, mécanisme et score CVSS 9,8.
• CISA — Known Exploited Vulnerabilities Catalog : exploitation active, ajout du 12 juin 2024 et usage connu par des rançongiciels.
• PHP 8.3.8 ChangeLog : version corrective publiée par le projet PHP.
• NIST NVD — CVE-2012-1823 : vulnérabilité PHP-CGI historique contournée par CVE-2024-4577.