// FRANDROID — CYBERSECURITY
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
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.
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.