Deux failles critiques ont été corrigées le 21 octobre 2026 dans le cœur de PHP, le langage qui fait tourner la majorité des sites web. Elles permettent à n’importe qui, sans compte ni mot de passe, d’exécuter du code sur un serveur. Des tentatives d’exploitation ont été observées dès le jour de la publication des correctifs. Si vous gérez un site — le vôtre ou celui d’un client — voici ce qu’il faut comprendre et faire, sans jargon.
Ce qui s’est passé, en trois dates
Le 20 octobre 2026, le projet PHP annonce une release de sécurité imminente pour deux vulnérabilités critiques. Les identifiants CVE fuient avec un faux score de 10,0, et la release est avancée d’un jour : le 21 octobre à 13h30 UTC, PHP publie les correctifs dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le 23 octobre, une troisième vulnérabilité — également capable de mener à une exécution de code à distance — est divulguée par le projet PHP, mais jugée trop rare pour justifier une sortie d’urgence.
Les deux failles principales sont notées 9,2 sur 10 (CVSS v4.0) par l’équipe de sécurité de PHP, le maximum d’impact possible. L’éditeur de sécurité watchTowr, relayé par Tenable, confirme une exploitation « in the wild » dès le 21 octobre, et l’équipe de recherche Amazon documente des tentatives antérieures à la divulgation publique. Le tout a été surnommé PHP2Shell.
Comment fonctionne la faille, expliqué simplement ?
Les deux failles sont des erreurs de gestion de la mémoire interne de PHP. Elles ne touchent pas votre code, ni vos plugins, ni vos thèmes : elles touchent le langage lui-même, dans des configurations par défaut.
La première (CVE-2026-109618) : la moitié d’un dossier traitée comme un dossier complet. PHP impose une limite de mémoire par requête (memory_limit). Quand une requête dépasse cette limite, PHP interrompt tout brutalement. Le problème : si l’interruption tombe au milieu de la lecture des données du formulaire — par exemple pendant le traitement d’un envoi de fichiers — les données internes sont à moitié remplies. Le nettoyage de fin de requête, lui, fait confiance à ce qu’il trouve et libère de la mémoire qui n’a jamais été correctement initialisée. Un attaquant peut orchestrer cette interruption, remplir la mémoire libérée avec ses propres données, et transformer le nettoyage en exécution de code. Les chercheurs de Datadog Security Labs ont reproduit l’attaque avec un simple POST non authentifié, sur un script PHP qui ne fait qu’afficher une réponse.
La seconde (CVE-2026-109619) : les restes du client précédent. Un serveur PHP traite des dizaines de requêtes à la suite avec le même processus. Si l’état interne d’une requête qui a échoué survit en mémoire, la requête suivante peut lire ces restes avant que l’initialisation normale ne les ait effacés. Comme si un serveur de restaurant servait au client suivant l’assiette à moitié mangée du précédent, en croyant qu’elle est neuve. Le chemin le plus documenté passe par session.upload_progress, activé par défaut dans PHP, même si votre application n’utilise jamais les sessions.
Pourquoi c'est plus grave qu'une faille de plugin habituelle ?
Deux raisons changent tout. D’abord, l’attaque se déclenche avant l’exécution de la moindre ligne de votre code : l’advisory de PHP confirme qu’une seule requête non authentifiée suffit sur Apache avec mod_php, la configuration jugée la plus à risque. Aucun plugin de sécurité, aucun pare-feu applicatif côté WordPress ne peut s’interposer, parce que l’attaque se produit en dessous de l’application. Ensuite, le périmètre est immense : toutes les versions de PHP de la 5.4 à la 8.5.11 sont touchées, soit vingt-deux ans de code. Les chercheurs de Calif, à l’origine de la découverte avec OpenAI et Wiz, ont confirmé l’exécution de code sans authentification sur WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, Magento 2.4.9, phpMyAdmin, Nextcloud, Laravel, Symfony et WHMCS.
Votre serveur est-il concerné ?
Toute installation de PHP qui sert des pages web est dans le périmètre, quel que soit le mode de fonctionnement : PHP-FPM, Apache avec mod_php, php-cgi, LiteSpeed ou FrankenPHP. Le tableau des versions :
| Version de PHP | État | Quoi faire |
|---|---|---|
| 8.5.x avant 8.5.12 | Vulnérable | Mettre à jour vers 8.5.12 |
| 8.4.x avant 8.4.27 | Vulnérable | Mettre à jour vers 8.4.27 |
| 8.3.x avant 8.3.36 | Vulnérable | Mettre à jour vers 8.3.36 |
| 8.2.x avant 8.2.35 | Vulnérable | Mettre à jour vers 8.2.35 |
| 8.1 et plus ancien | Vulnérable, plus de support | Packages de votre distribution, ou backports publiés par l’équipe PHP pour 7.4 à 8.1 |
Vous ne savez pas quelle version tourne chez votre hébergeur ? Posez la question directement : « quelle version de PHP exécutez-vous pour mon site, et a-t-elle reçu le correctif du 21 octobre 2026 ? » Si la réponse est vague, c’est mauvais signe.
Que faire, dans l'ordre ?
1. Mettre à jour PHP. C’est le seul correctif complet. L’advisory officiel est formel : la mise à jour est la seule mitigation complète. Sur un serveur mutualisé, passez par le panneau de votre hébergeur. Sur un VPS ou un serveur dédié, les distributions Linux (Debian, Ubuntu, AlmaLinux) ont reçu les correctifs : apt update && apt upgrade ou l’équivalent, puis redémarrage des processus PHP.
2. Sauvegarder avant d’agir. Une mise à jour de PHP peut casser un plugin ancien. La règle 3-2-1 — trois copies, deux supports, une hors site — que nous détaillons dans l’article sur la sauvegarde 3-2-1 s’applique mot pour mot ici : sauvegarde complète avant le changement de version, pour pouvoir revenir en arrière.
3. Si la mise à jour est impossible aujourd’hui, appliquer les mitigations officielles. Pour la première faille : fixer memory_limit=-1 au niveau administrateur (configuration du pool FPM ou d’Apache), avec un post_max_size bas — 8 Mo si le site n’accepte pas d’uploads, 32 Mo sinon. Pour la seconde : désactiver session.upload_progress.enabled=0 et redémarrer tous les workers PHP. L’advisory le répète : ces mesures réduisent l’exposition, elles ne rendent pas l’installation sûre. Si le correctif ne peut vraiment pas être appliqué rapidement, CERT-EU recommande d’isoler les serveurs exposés d’Internet jusqu’à ce que le correctif soit appliqué et vérifié.
4. Vérifier les traces d’exploitation. L’exploit documenté passe par des soumissions de formulaires ordinaires, ce qui rend la détection difficile. À surveiller dans les logs : requêtes POST anormalement volumineuses ou répétées vers n’importe quelle URL, plantages de workers PHP, processus inattendus. Après une compromission d’un site marchand, le dossier n’est plus technique mais commercial : notre article sur la fraude à la carte bancaire en e-commerce détaille ce que les attaques contre les boutiques en ligne coûtent réellement.
Une troisième faille, volontairement gardée sous silence
Le 23 octobre, le projet PHP a divulgué l’existence d’une troisième vulnérabilité, CVE-2026-115560, elle aussi capable de mener à une exécution de code à distance. La particularité : elle ne touche que des configurations inhabituelles, et PHP a choisi de ne PAS publier de correctif d’urgence. Le détail technique sera publié avec la prochaine release normale. En attendant, la mesure de contournement citée plus haut couvre aussi ce nouveau vecteur : gardez session.upload_progress désactivé et redémarrez les workers si ce n’est pas déjà fait.
Ce que cette affaire change pour la suite
La chronologie interne, documentée par les chercheurs, a de quoi méditer : une première version de ce type de bug avait été découverte en 2004, un rapport similaire était déposé en 2020, un audit indépendant commandité en 2024 avait identifié le problème sans pouvoir prouver l’exploitation — et rien n’avait été corrigé. Il aura fallu une équipe de recherche qui fouille le code avec des modèles d’IA pour que la chaîne complète soit démontrée et corrigée. Ce qui est un progrès : la faille a été découverte, signalée et corrigée dans les délais. Ce qui est une alerte : la surface d’attaque du web repose sur des composants partagés par tout le monde, et leur audit approfondi est en train de changer d’échelle. Les mises à jour de votre langage serveur ne sont plus une tâche d’entretien optionnelle.
Questions fréquentes
WordPress est-il touché ? Oui, indirectement : la faille est dans PHP, pas dans WordPress, et les chercheurs ont confirmé l’attaque sur une version récente de WordPress. Corriger PHP corrige le problème.
Je suis chez un hébergeur mutualisé, que dois-je faire ? Rien de technique : demander à votre hébergeur la version de PHP exécutée pour votre site et la confirmation que le correctif du 21 octobre 2026 est appliqué. Les grands hébergeurs ont patché dans la journée.
Les mitigations suffisent-elles si je ne peux pas patcher ? Non, et c’est écrit noir sur blanc dans l’advisory officiel : elles ne ferment que certains chemins d’attaque. Seule la mise à jour ferme la faille elle-même.
Sources
- PHP : Security Release — advisories officiels (php.net)
- Advisory PHP — RCE via OOM corruption, CVE-2026-109618 (GitHub)
- Advisory PHP — RCE via stale global state, CVE-2026-109619 (GitHub)
- CERT-EU — Security Advisory 2026-018, Critical Vulnerabilities in PHP
- Calif Research — php2shell : la recherche à l’origine de la découverte
- Datadog Security Labs — reproduction indépendante de l’exploit
- Tenable — FAQ php2shell (exploitation confirmée in the wild)
- AWS Security Blog — exploitation pré-divulgation (MadPot)
- Google Cloud — périmètre de versions et réponse
- PHP Foundation — la release et le renforcement de la sécurité de PHP