Le 21 octobre 2026 à 14h00 UTC, l'équipe de sécurité de PHP a publié en urgence — avec un jour d'avance sur le calendrier prévu, les identifiants ayant commencé à circuler dès le 20 octobre — un correctif pour deux vulnérabilités critiques que les chercheurs ont baptisées « php2shell » : CVE-2026-109618 et CVE-2026-109619, chacune notée 9,2 sur 10 en CVSS v4.0. Les deux permettent une exécution de code à distance sans authentification, et la première peut en plus divulguer de la mémoire du serveur — mots de passe, jetons de session, clés API ou clés privées TLS — via un simple cookie PHPSESSID (Tenable, Sansec).
Ce qui distingue cette alerte de la plupart des failles de sécurité web : elle ne se trouve pas dans un thème, un plugin ou une ligne de code métier mal écrite, mais dans le moteur PHP lui-même — deux bugs de type « use-after-free » déclenchés lors d'une erreur fatale en cours de requête, par exemple un dépassement de mémoire combiné à une requête d'envoi de fichier. Le chemin de code concerné remonte à PHP 5.4. Toutes les versions de PHP encore maintenues sont affectées ; les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12, et seule une mise à jour vers l'une d'elles referme réellement la faille — les mesures de contournement proposées en attendant ne font que réduire l'exposition, sans la supprimer.
Concrètement, cela touche n'importe quel site ou application reposant sur PHP, quelle que soit la qualité de son propre code : les chercheurs ont confirmé une exécution de code à distance pré-authentification sur WordPress, Drupal, Joomla et Magento, et la liste des logiciels bâtis sur PHP potentiellement concernés s'étend bien au-delà (WooCommerce, Shopware, Nextcloud, phpMyAdmin, entre autres). Cloudflare a observé des tentatives d'exploitation dès le 21 octobre à 7h43 UTC, avant même la publication officielle du correctif.
Ce que cet épisode révèle, au-delà du cas PHP :
C'est précisément sur ces deux volets que nous intervenons chez nos clients. Dans le cadre de notre infogérance, la supervision de votre parc que nous pilotons au quotidien inclut la gestion des correctifs : les mises à jour de sécurité critiques — comme celle publiée en urgence le 21 octobre pour PHP — sont suivies et déployées sans attendre que vous en entendiez parler par la presse. Et pour les sites que nous développons via notre solution de site vitrine optimum, l'absence de tout CMS intermédiaire — ni WordPress, ni Elementor, ni aucun moteur PHP à administrer — signifie qu'une faille comme php2shell n'a tout simplement aucune prise : il n'y a rien à patcher, parce qu'il n'y a rien d'intermédiaire à exploiter.
Votre site repose-t-il sur un CMS dont les mises à jour de sécurité sont vraiment suivies, ou gagnerait-il à s'en affranchir complètement ? Parlons-en.