Failles critiques PHP : mettez votre site à jour maintenant

Votre site internet, votre boutique en ligne ou votre extranet tourne très probablement sur PHP : c’est le langage qui fait fonctionner WordPress, PrestaShop et une grande partie des applications web. Le 21 octobre 2026, l’équipe PHP a publié en urgence des correctifs pour deux vulnérabilités critiques qui permettent à un attaquant d’exécuter du code sur le serveur sans aucun identifiant. Le CERT-FR a émis une alerte le jour même. La seule protection complète est la mise à jour.

Ce qui s’est passé

• 20 octobre 2026 : l’équipe PHP annonce deux vulnérabilités critiques et la sortie des correctifs pour le lendemain.
• 21 octobre 2026, 14 h 00 UTC (10 h 00 en Guadeloupe) : publication de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent les deux failles.

Selon le CERT-EU, les détails techniques sont désormais discutés publiquement et de premières preuves de concept circulent, ce qui rend probable une exploitation par des attaquants. Autrement dit : la fenêtre entre la publication du correctif et les premières attaques se compte en heures, pas en semaines.

Les deux vulnérabilités

Les deux failles sont notées 9.2 sur 10 (CVSS v4) par l’équipe PHP, niveau « critique » :

• CVE-2026-109618 — « RCE via OOM corruption » : lorsqu’une requête épuise la mémoire allouée, PHP peut s’interrompre alors que des données internes ne sont que partiellement initialisées. Le nettoyage qui suit les traite comme valides, ce qui ouvre la voie à l’exécution de code.
• CVE-2026-109619 — « RCE via stale global state » : un état interne lié à une requête peut survivre après la libération de sa mémoire. Une requête suivante traitée par le même processus peut alors réutiliser cet état périmé.

Le point qui doit faire réagir un dirigeant : d’après l’avis de l’équipe PHP, toutes les installations PHP qui servent des pages web sont à risque — PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php, pour lequel une exploitation a été démontrée avant même que le code de votre site ne s’exécute. Un site parfaitement développé, avec des extensions à jour, reste donc vulnérable si la version de PHP qui le fait tourner ne l’est pas.

Quelles versions sont concernées

Branche PHP	Vulnérable	Version corrigée
8.5	antérieure à 8.5.12	8.5.12
8.4	antérieure à 8.4.27	8.4.27
8.3	antérieure à 8.3.36	8.3.36
8.2	antérieure à 8.2.35	8.2.35
8.1, 8.0, 7.x, 6.x, 5.x	toutes versions	aucune version officielle

Les branches 8.1 et antérieures ne sont plus maintenues par le projet PHP. Vu la gravité, l’équipe PHP a tout de même fourni des correctifs minimaux sous forme de code source pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes. Pour tous les autres, le CERT-FR recommande d’isoler les équipements concernés puis de migrer vers une version maintenue.

Ce qu’il faut faire aujourd’hui

1. Identifier qui gère PHP. Sur un hébergement mutualisé, ce n’est pas vous qui installez PHP : c’est l’hébergeur. Sur un serveur dédié ou un VPS, c’est vous ou votre prestataire. Les distributions Linux ont reçu les correctifs à l’avance : la mise à jour passe par le gestionnaire de paquets habituel.

2. Vérifier la version réellement utilisée par le site. Attention à un piège classique : la commande php -v en ligne de commande peut indiquer une autre version que celle qui sert les pages web. C’est la version du site qui compte — votre prestataire ou votre hébergeur peut vous la confirmer.

3. Demander une confirmation écrite. Si un prestataire ou un hébergeur gère votre site, demandez-lui noir sur blanc : quelle version de PHP fait tourner le site, et est-elle au niveau 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou disposant du correctif rétroporté de la distribution) ? Une réponse vague n’est pas une réponse.

4. Sortir des versions abandonnées. Si votre site tourne encore en PHP 8.1 ou plus ancien, c’est le moment de passer à une branche maintenue. Cela demande souvent de vérifier la compatibilité du thème et des extensions : c’est un chantier, mais rester sur une version qui ne reçoit plus de correctifs revient à laisser cette faille — et les suivantes — ouvertes.

5. Redémarrer les processus PHP après la mise à jour. Un PHP-FPM mis à jour mais pas redémarré continue de servir l’ancienne version.

Si la mise à jour ne peut pas être faite tout de suite

L’équipe PHP et le CERT-FR décrivent des mesures de contournement, avec une mise en garde claire : elles réduisent l’exposition à certains chemins d’attaque mais ne rendent pas une installation sûre. Les principales :

• Contre CVE-2026-109619 : désactiver session.upload_progress.enabled dans php.ini ou dans la configuration du pool FPM, puis redémarrer chaque processus. L’équipe PHP précise que la configuration doit s’appliquer avant le traitement de la requête : ne pas compter sur ini_set() ni sur un fichier .user.ini. Le CERT-FR précise que cette mesure ne réduit la surface d’attaque que contre l’une des deux failles.
• Contre CVE-2026-109618 : imposer memory_limit=-1 de façon que les applications ne puissent pas le modifier, et abaisser post_max_size. L’équipe PHP reconnaît qu’une défaillance d’allocation sous-jacente peut tout de même atteindre le chemin vulnérable.
• Au niveau du pare-feu applicatif : le CERT-FR suggère de bloquer les requêtes HTTP de type multipart — ce qui coupe aussi l’envoi de fichiers par formulaire — ou, à défaut, de les surveiller.

Ces mesures s’appliquent sur la configuration du serveur. Sur un hébergement mutualisé, elles relèvent de l’hébergeur. Et dans tous les cas, ce sont des rustines en attendant la mise à jour, pas une alternative.

À retenir

Cette alerte ne concerne pas une extension mal codée ou un mot de passe faible : elle touche le moteur qui fait tourner le site. Une seule question compte cette semaine — votre site tourne-t-il sur une version de PHP corrigée ? Si vous ne savez pas qui peut y répondre, c’est en soi le problème à régler. Le suivi des alertes de sécurité et l’application des correctifs font partie de la maintenance des sites web et de l’infogérance que nous assurons pour nos clients.

Sources : CERT-FR, alerte CERTFR-2026-ALE-014 « Multiples vulnérabilités dans PHP » ; PHP, « Security advisory: Critical remote code execution vulnerabilities, update now » (21 octobre 2026) ; PHP, avis GHSA-w8hw-w9fx-j79w « RCE via OOM corruption » ; PHP, avis GHSA-6wmf-4rv5-p3rp « RCE via stale global state » ; CERT-EU, « Critical Vulnerabilities in PHP ».