Failles critiques dans PHP : la menace se précise, mais le pire scénario s’éloigne pour nos sites web

Après vingt-quatre heures de rumeurs, de notes contradictoires et d’une fausse alerte sur les Freebox, le texte officiel met enfin les choses au clair. Cette publication précise change agréablement des captures d’écran parcellaires qui circulaient la veille. Pour mémoire, l’équipe de PHP avait prévenu mardi qu’elle déploierait ce mercredi des correctifs d’urgence pour deux vulnérabilités majeures, en gardant jusque-là le silence sur leur fonctionnement exact pour ne pas donner d’indice aux attaquants.

Pour aller plus loin
Failles critiques dans PHP : alerte maximale et mise à jour d’urgence ce mercredi à 16 h

Dans le détail, les versions corrigées (PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35) viennent colmater deux brèches permettant d’exécuter du code malveillant à distance sur un serveur, sans avoir besoin d’un compte ni d’un mot de passe. Le projet maintient d’ailleurs un score de gravité (CVSS) de 9,2 sur 10, un niveau très élevé mais en deçà de la note maximale de 10 évoquée mardi.

Concrètement, la première faille (CVE-2026-109618) provient d’un défaut d’allocation mémoire au tout début du traitement d’une requête web, lorsque les données du serveur ne sont encore qu’à moitié initialisées. La seconde (CVE-2026-109619) est une erreur de gestion mémoire (de type use-after-free) qui autorise une requête à piocher dans les résidus d’informations laissés par la requête précédente, alors même que cet espace mémoire est censé avoir été nettoyé.

Pour aller plus loin
Failles critiques dans PHP : alerte maximale et mise à jour d’urgence ce mercredi à 16 h

Apache et mod_php en première ligne

Or, dans les faits, toutes les installations qui hébergent des pages web ne sont pas logées à la même enseigne. L’équipe de PHP désigne les serveurs Apache équipés du module historique mod_php comme les plus vulnérables : sur cette architecture, une attaque complète a pu être démontrée avec les réglages par défaut, se déclenchant avant même que le code du site web ne soit exécuté.

À l’inverse, sur les serveurs utilisant PHP-FPM (la configuration moderne la plus courante, notamment derrière Nginx), le risque demeure théorique et dépend de réglages bien spécifiques, aucune attaque de bout en bout n’ayant pu être validée sur la première faille.

Dans les deux cas, l’opération reste délicate pour un pirate, car elle exige de manipuler finement la mémoire vive du serveur en envoyant une salve de requêtes qui doivent toutes atterrir exactement dans le même processus informatique.

Si de prétendues preuves de concept circulent déjà sur GitHub et X sans avoir pu être authentifiées, l’éditeur de sécurité Sophos indique pour l’heure n’avoir détecté aucune attaque réelle.

Un casse-tête persistant pour les vieilles versions de PHP

Pour les administrateurs système, il ne faut pas du tout tarder mettre à jour, car aucune parade temporaire ne protège intégralement un serveur vulnérable. Les principales distributions Linux ayant reçu les correctifs sous embargo, une simple mise à jour classique des paquets suffit sur les systèmes récents. En revanche, le sort des branches obsolètes (PHP 8.1 et antérieures) reste particulièrement épineux.

Faute de nouvelles versions officielles clés en main, les administrateurs sous PHP 7.4, 8.0 et 8.1 doivent récupérer le code source des correctifs et recompiler eux-mêmes leur environnement, tandis que les versions encore plus anciennes dépendent entièrement d’éventuels contrats de support étendu payants. En guise de pansement provisoire, désactiver l’option session.upload_progress.enabled dans la configuration permet tout de même de verrouiller l’un des principaux vecteurs d’attaque identifiés.

Du côté des internautes, le constat reste identique à ce que nous détaillions concernant les risques pesant sur nos achats en ligne et nos données bancaires. Si la complexité technique de l’attaque évite un piratage de masse instantané et offre un précieux répit aux hébergeurs qui appliquent les patchs dès ce soir, elle ne fait que repousser l’échéance pour les nombreux sites marchands qui tournent encore sur de vieilles versions de PHP non maintenues.

Pour aller plus loin
Failles critiques dans PHP : voici les réflexes à adopter pour vos paiements en ligne ces prochains jours