Ces deux CVE sont liées : ce sont deux failles critiques dans PHP lui-même, publiées le 21 octobre 2026.

Ce qu’elles ont en commun

• Elles permettent à un attaquant d’exécuter du code sur le serveur avec une requête HTTP forgée, sans authentification. PHP leur attribue à chacune un score de 9,2 (critique).
• Elles sont surnommées « PHP2Shell ».
• Elles sont corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toute application sur une version plus ancienne est concernée, quel que soit le framework.

Ce qui les distingue

• CVE-2026-109618 : elle s’appuie sur la limite mémoire de PHP. Un dépassement de memory_limit pendant le traitement de la requête déclenche une sortie brutale (un longjmp) qui laisse le moteur dans un état incohérent.
• CVE-2026-109619 : elle exploite un état résiduel de requête. PHP libère en fin de requête certains éléments (gestionnaires d’erreurs utilisateur, superglobales), mais laisse les pointeurs en place jusqu’à la requête suivante. Un avertissement levé trop tôt, par exemple par une directive .htaccess ou .user.ini invalide, peut alors les atteindre. L’attaque démontrée passe par la fonction de suivi de progression d’upload de session, et sur PHP 8.5 par les backtraces d’erreurs fatales.

De mon côté, tout est patché.

J’ai mis à jour mes serveurs et mes applications pour corriger ces failles de sécurité.

Pourquoi le monde est affolé ?

PHP équipe 80 % du web.

Le mode d’emploi de l’attaque a été publié de sorte que même un apprenti développeur peut potentiellement l’exécuter.

Ces failles permettent de prendre le contrôle d’un serveur web PHP en s’offrant la base de données par exemple, avec toutes les informations personnelles des individus.

Mais aussi, les pirates peuvent éventuellement détourner un serveur pour mener des attaques sur une autre cible.

Également des petits logiciels peuvent être installés sur les serveurs pour mettre en marche des mauvaises actions ultérieurement.

C’est pourquoi tous les sites sensibles ont été stoppés : sites gouvernementaux, bancaires, e-commerces, etc.

Depuis la sortie des correctifs, il suffit de comparer l’ancienne version du code avec la nouvelle pour identifier les anciennes failles.

Et comme de nombreuses applications PHP sont dites “legacy”, c’est-à-dire qu’elles n’ont pas été mises à jour depuis longtemps, il est difficile de les mettre à jour rapidement.

Certaines entreprises ignorent même qu’elles ont certaines applications et serveurs PHP en ligne.

Donc il va y avoir du boulot pour les développeurs et la cyber-sécurité !