← Toutes les ressources

Failles critiques PHP : votre site web est concerné (21/10/2026)

Publié le 22 octobre 2026 · 7 min de lecture · CyberNovaLabs.io

Deux vulnérabilités critiques dans PHP, le moteur sous la plupart des sites de PME, permettent une exécution de code à distance sans authentification. Les correctifs sont sortis le 21 octobre 2026. Ce qu'il faut vérifier cette semaine, et ce qui ne sera jamais corrigé.

En bref

Le 20 octobre 2026, l'équipe de sécurité de PHP a fait une chose qu'elle fait rarement : annoncer une mise à jour critique avant de la publier, pour laisser le temps de se préparer. Elle corrige deux vulnérabilités notées 9,2 sur 10 en CVSS v4.0^[1]. Les correctifs sont sortis le 21 octobre 2026, dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35^[3], et les deux failles — CVE-2026-109618 et CVE-2026-109619 — permettent d'exécuter du code à distance sans aucun identifiant^[3][5][6].

Pourquoi une faille PHP concerne votre site web, même si vous ne « faites pas de PHP »

PHP n'est pas un choix que la plupart des PME ont fait consciemment : c'est le moteur sous WordPress, Drupal, Joomla, Adobe Commerce (Magento), Nextcloud, et sous une bonne partie des intranets, extranets et portails clients développés sur mesure. Vous ne voyez jamais PHP, mais il exécute chaque visite de votre site.

Le CERT-EU est explicite : toute installation PHP qui sert des requêtes web est exposée, qu'elle tourne en PHP-FPM, en Apache avec mod_php, en php-cgi, en FrankenPHP ou en LiteSpeed ; l'équipe PHP considère mod_php comme la configuration la plus risquée^[3]. Et le point qui change tout pour une PME : l'attaque aboutit avant que le code de votre application ne s'exécute, en une seule requête non authentifiée^[3]. Autrement dit, ni une page de connexion, ni un plugin de sécurité, ni un mot de passe solide ne s'interposent. Ce n'est pas une faille de WordPress : c'est une faille sous WordPress.

Les deux failles, en clair

CVE-2026-109618 (« RCE via OOM corruption », 9,2)^[5] : PHP interrompt brutalement une requête qui dépasse la limite mémoire configurée. Cette interruption peut survenir alors que les données internes de la requête ne sont qu'à moitié initialisées — par exemple pendant l'analyse d'un formulaire d'envoi de fichier. Le nettoyage de fin de requête traite alors ces données invalides comme valides, et libère de la mémoire qui n'a jamais été initialisée et qui peut encore contenir des données choisies par l'attaquant^[3].

CVE-2026-109619 (« RCE via stale global state », 9,2)^[6] : un état interne appartenant à une requête survit à la libération de sa mémoire, par exemple après une erreur fatale. Une requête suivante, traitée par le même processus, peut utiliser cet état périmé avant que l'initialisation normale ne le remette à zéro^[3][4].

Un mot d'honnêteté sur l'exploitation : à l'heure où nous écrivons, aucun des avis que nous avons lus n'annonce une exploitation confirmée dans la nature. Le CERT-EU indique en revanche que les détails techniques sont désormais discutés publiquement et que des preuves de concept ont commencé à circuler, ce qui rend probable une exploitation en cours, et il recommande de corriger immédiatement^[3].

Le piège des versions qui n'auront jamais de correctif

C'est la vraie mauvaise nouvelle pour les PME. Le CERT-FR liste comme affectées « PHP toutes versions 5.x, 6.x, 7.x, 8.0.x, 8.1.x », branches dont l'éditeur n'assure plus le support, et recommande d'isoler les équipements concernés puis de migrer vers une version maintenue^[2].

Branche PHP	Version corrigée	Statut
8.5.x	8.5.12	maintenue
8.4.x	8.4.27	maintenue
8.3.x	8.3.36	maintenue
8.2.x	8.2.35	maintenue
8.1.x et antérieures (8.0.x, 7.x, 6.x, 5.x)	aucune	fin de vie, pas de correctif

Si votre site tourne en PHP 7.4 ou 8.1 — ce qui reste courant sur des sites vitrines installés il y a quelques années et jamais retouchés — il n'y a pas de correctif à appliquer. Ce n'est plus une mise à jour de sécurité, c'est une migration : compatibilité des extensions et du thème, environnement de test, parfois des corrections de code. Comptez des semaines, pas des heures. C'est aussi pour cela que la version de PHP n'est pas un détail technique à laisser au prestataire sans suivi : lisez ce que l'accès distant de votre prestataire IT expose réellement, et le cas des outils auto-hébergés comme Jira et Confluence, qui pose exactement la même question de responsabilité.

Les contournements provisoires du CERT-FR, et leur limite

Le CERT-FR propose deux mesures d'atténuation, en précisant lui-même qu'elles ne sont pas qualifiées par ses services^[2] :

• dans php.ini, désactiver le suivi de progression des envois : session.upload_progress.enabled = Off ; si le processus PHP-FPM tourne, il faut aussi positionner php_admin_flag[session.upload_progress.enabled] = off. Point important à lire deux fois : cette mesure ne réduit la surface d'attaque que contre une des deux vulnérabilités^[2] ;
• bloquer toutes les requêtes HTTP dont l'en-tête Content-Type vaut multipart ; si le blocage est impossible, superviser ce type de requêtes. Les deux mesures peuvent être portées par un pare-feu applicatif (WAF)^[2].

Attention à l'effet de bord : bloquer le multipart coupe aussi les envois de fichiers légitimes — formulaire de contact avec pièce jointe, dépôt de documents, médiathèque. À tester hors production avant de l'activer, et à surveiller si vous dépendez d'un formulaire pour recevoir des demandes.

Quatre pays, mêmes versions, autorités différentes

Les numéros de version à atteindre sont identiques aux Pays-Bas, en Belgique, en France et au Luxembourg. Ce qui change, c'est qui publie l'avis et qui vous devez prévenir en cas d'incident.

• France : alerte CERT-FR CERTFR-2026-ALE-014 du 21 octobre 2026, risque retenu « exécution de code arbitraire à distance »^[2].
• Pays-Bas : avis NCSC-2026-0443 du 21 octobre 2026, coté « élevé / élevé » par le NCSC néerlandais^[4].
• Belgique : le CCB (CERT.be) est l'autorité nationale à suivre ; les versions corrigées sont les mêmes.
• Luxembourg : l'avis CERT-EU 2026-018 du 21 octobre 2026 est la référence lisible des quatre pays^[3].

Si votre entité entre dans le champ de NIS2, une compromission significative passant par cette faille peut déclencher vos obligations de notification auprès de votre autorité nationale. Le périmètre et les délais dépendent de la loi de transposition de chaque pays : vérifiez-le avant d'en avoir besoin, avec nos repères pour NIS2 en Belgique et NIS2 aux Pays-Bas, ou avec les outils de notre dossier cybersécurité.

Chez CyberNovaLabs.io

Nous faisons ce relevé pour nos clients : inventaire des sites exposés, version de PHP réellement servie par chaque serveur, et la liste de ce qui doit migrer parce qu'aucun correctif n'arrivera. C'est souvent la première fois qu'une PME voit, sur une seule page, l'âge du socle technique de son site. Si vous voulez ce relevé sur votre parc, ou refaire un site qui ne sera plus un passager clandestin de PHP 7.4, parlons-en en vingt minutes — et voyez d'abord notre dossier cybersécurité et nos sites pour PME et artisans.

Sources

1. PHP — Upcoming Critical PHP Security Release (20/10/2026)
2. CERT-FR — CERTFR-2026-ALE-014, Multiples vulnérabilités dans PHP (21/10/2026)
3. CERT-EU — Security Advisory 2026-018, Critical Vulnerabilities in PHP (21/10/2026)
4. NCSC-NL — NCSC-2026-0443, Kwetsbaarheden verholpen in PHP (21/10/2026)
5. CVE-2026-109618 — RCE via OOM corruption (CVSS v4.0 9.2, 21/10/2026)
6. CVE-2026-109619 — RCE via stale global state (CVSS v4.0 9.2, 21/10/2026)

À lire aussi