Ce qui s’est passé
Le 21 octobre, le projet PHP a publié des correctifs pour deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619. Toutes deux sont notées CVSS 9.2 et, selon l’analyse d’Arctic Wolf, peuvent permettre à un attaquant non authentifié d’exécuter du code sur un serveur qui traite des requêtes web avec PHP.
Les bugs se trouvent dans le cycle de traitement des requêtes de PHP lui-même, pas dans un framework ou un plugin :
- CVE-2026-109618 est une corruption mémoire déclenchée lorsqu’une condition de mémoire insuffisante interrompt PHP alors que les données de la requête ne sont que partiellement initialisées.
- CVE-2026-109619 est un use-after-free : l’état d’une requête peut survivre et être lu par une requête ultérieure sur le même worker, ce qui peut aussi faire fuiter le contenu de la mémoire.
Ce second point mérite qu’on s’y arrête. Qualys note que la mémoire d’un worker qui fuit peut contenir des mots de passe, des jetons et des clés API. Donc même si personne n’obtient de shell sur votre machine, des secrets peuvent s’échapper.
Tout est allé très vite après le correctif, et l’ampleur est considérable : The Hacker News cite des estimations de Censys selon lesquelles plus de 32 millions de services PHP tournent encore sur une version affectée.
- L’équipe de threat intelligence d’Amazon indique que le ciblage a commencé quatre jours avant la publication des correctifs, comme le rapporte BleepingComputer.
- Le 24 octobre, un chercheur de Perplexity a confirmé une exécution de code réussie contre des honeypots (The Hacker News).
- Le 26 octobre, la CISA a ajouté les deux CVE à son catalogue Known Exploited Vulnerabilities et a donné aux agences fédérales américaines jusqu’au 29 octobre pour les corriger.
Pourquoi c’est important même pour les petites apps
Ici, les attaquants ne choisissent pas leurs cibles selon la taille de l’entreprise. Ils scannent Internet à la recherche de tout ce qui répond comme du PHP et tentent l’exploit. Un projet annexe oublié sur un VPS est tout aussi accessible qu’un grand site e-commerce.
Quelques détails rendent celle-ci particulièrement urgente :
- Cela ne dépend pas de votre code. Arctic Wolf souligne que, puisque les failles se trouvent dans le traitement des requêtes de PHP, l’exposition ne dépend pas de l’application que vous faites tourner. Une app Laravel parfaitement écrite sur un ancien build de PHP reste exposée.
- De nombreuses configurations serveur sont concernées. Apache avec mod_php est considéré comme le plus à risque, mais PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont tous cités comme affectés, tout comme les produits et appliances qui embarquent PHP.
- Les vieilles versions de PHP sont courantes. Qualys rapporte qu’environ 71 % des installations PHP dont il a pu déterminer la version étaient déjà en fin de vie. Si vous êtes en 8.1 ou plus ancien, il n’existe pas de correctif upstream régulier pour vous.
Comment vérifier votre app
Vous cherchez une réponse par serveur : quelque chose sert-il des requêtes web avec PHP, et dans quelle version exacte ?
1. Listez tout ce que vous hébergez. Pas seulement l’app principale. Incluez les sites marketing, blogs, docs, environnements de staging, outils d’administration et tout ce qui se trouve sur un sous-domaine. Ce sont les oubliés qui sont dangereux.
2. Regardez les en-têtes de réponse. Beaucoup de configurations PHP se trahissent dans un en-tête X-Powered-By ou Server. Pas d’en-tête ne signifie pas pas de PHP (on peut le désactiver avec expose_php = Off), mais un en-tête est un oui rapide. Les pages d’erreur verbeuses sont un autre indice : une stack trace PHP en production dit exactement à un attaquant ce que vous faites tourner.
curl -sI https://your-site.example | grep -i -E 'x-powered-by|server'
# X-Powered-By: PHP/8.3.20 <- PHP, and an old patch level3. Vérifiez la version qui sert le trafic web, pas seulement la CLI. php -v sur le serveur peut indiquer un autre build que celui réellement utilisé par Apache ou PHP-FPM ; Qualys le signale explicitement. Vérifiez le binaire FPM ou le module PHP de votre serveur web, ou demandez à votre hébergeur.
php-fpm8.3 -v # or php-fpm -v, depending on your distro
apache2ctl -M | grep php # is mod_php loaded?4. Comparez avec les versions corrigées. Si vous installez PHP depuis votre distribution Linux, le correctif peut être rétroporté dans un paquet dont le numéro de version semble plus ancien ; consultez donc l’avis de sécurité de votre distribution plutôt que la seule chaîne de version. Sinon, il vous faut au minimum :
- PHP 8.5 : 8.5.12
- PHP 8.4 : 8.4.27
- PHP 8.3 : 8.3.36
- PHP 8.2 : 8.2.35
5. Hébergement managé ? Si vous êtes chez un hébergeur WordPress managé ou sur un PaaS, consultez sa page de statut ou son changelog pour une notice PHP2Shell. La plupart appliqueront le correctif pour vous, mais « la plupart » ne veut pas dire « tous », et un VPS autogéré est entièrement sous votre responsabilité.
Comment corriger
Corrigez, puis redémarrez. Mettre à jour PHP est la seule correction complète.
Le redémarrage compte : les workers en cours d’exécution gardent l’ancien code en mémoire jusqu’à leur remplacement. Avec Docker, reconstruisez sur une image de base à jour (par exemple un tag php:8.3-fpm récent) et redéployez. Ne vous contentez pas de redémarrer l’ancien conteneur.
Sur Debian ou Ubuntu avec PHP-FPM, cela ressemble généralement à ceci :
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if you use mod_phpSi vous ne pouvez pas corriger aujourd’hui, Qualys résume les mesures d’atténuation temporaires de PHP. Elles réduisent le risque mais ne rendent pas sûr un serveur non corrigé. Définissez-les dans php.ini ou la configuration du pool FPM (pas dans .user.ini ni via ini_set), puis redémarrez tous les workers.
Si un service n’est pas corrigé et n’a pas besoin d’être public, placez-le derrière un VPN ou une liste d’IP autorisées, ou mettez-le hors ligne jusqu’à ce que vous puissiez le mettre à jour.
; php.ini or FPM pool config (not .user.ini or ini_set)
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M if you need uploads
upload_max_filesize = 6M ; keep below post_max_sizeEn PHP 8.1 ou plus ancien ? Planifiez la mise à niveau maintenant. Des rétroportages limités existent pour certaines anciennes branches, mais vous comptez sur la chance chaque fois que quelque chose de ce genre arrive.
Cherchez des signes de compromission. Vérifiez les processus inattendus, les nouveaux fichiers dans les racines web, les tâches cron inconnues et les connexions sortantes depuis le serveur web. Arctic Wolf note aussi que de nombreuses requêtes « PHP2Shell » dans les logs réutilisent d’anciennes techniques ; une ligne de log inquiétante ne signifie donc pas automatiquement une intrusion réussie.
Changez vos secrets si vous avez été exposé. Comme CVE-2026-109619 peut faire fuiter la mémoire des workers, considérez comme potentiellement vus les secrets passés par un processus PHP non corrigé et exposé sur Internet : mots de passe de base de données, clés API, clés de signature de session et clés de prestataires de paiement. Laravel et les frameworks similaires les conservent dans .env ; vérifiez donc aussi que ce fichier n’a jamais été accessible depuis le web.
Checklist rapide
Passez-la en revue pour chaque domaine que vous possédez :
- Chaque domaine et sous-domaine que vous possédez est listé, y compris les anciens sites marketing et de staging.
- Vous savez lesquels utilisent PHP, et la version exacte qui sert le trafic web.
- Chacun est en 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou sur un build corrigé par l’éditeur.
- Les workers PHP et les serveurs web ont été redémarrés après la mise à jour.
- Tout ce qui n’est pas corrigé est restreint ou hors ligne, avec les atténuations appliquées.
- Les secrets des hôtes exposés ont été changés.
- La production n’affiche plus sa version de PHP ni de stack traces.
La leçon à retenir
PHP2Shell sera corrigé et oublié d’ici quelques semaines. Le schéma, lui, restera. L’écart entre « correctif publié » et « exploité » se compte désormais en jours, parfois il est même négatif. Les petites équipes ne peuvent pas suivre ce rythme à coups d’héroïsme. Ce qui fonctionne : savoir ce que vous faites tourner et remarquer rapidement quand quelque chose change.
C’est la même logique que derrière notre checklist de lancement pour les apps créées avec l’IA : la plupart des incidents réels viennent de choses faciles à vérifier, à condition de les vérifier vraiment.
AppSafe analyse votre site en ligne de l’extérieur, comme un attaquant le verrait. Il recherche des problèmes comme des en-têtes de sécurité manquants, un en-tête X-Powered-By qui révèle votre stack, des fichiers exposés et des erreurs verbeuses, et vous propose des corrections en langage clair. Une fois le correctif appliqué, lancez un scan gratuit sur chacun de vos domaines pour régler au passage les autres points faciles.