Corrigez votre PHP avant le petit-déj' : deux RCE critiques sont déjà exploitées

Mardi 21 octobre 2026, le projet PHP a fait quelque chose qu'il ne réserve qu'aux vraies urgences : la veille, il a pré-annoncé une publication de sécurité à date et heure fixes — le 21 octobre à 14h00 UTC — et l'a livrée à l'heure, pour toutes les branches supportées à la fois. Le projet ne fait pas ça pour des bugs ordinaires. Deux vulnérabilités — CVE-2026-109618 et CVE-2026-109619 — permettent une exécution de code distante non authentifiée. Toutes deux sont notées 9,2 sur 10 (critique) sur l'échelle CVSS v4.0. Et toutes deux sont, selon les termes mêmes de l'avis, activement exploitées en conditions réelles.

Si cette phrase ne gâche pas votre café, relisez-la lentement : n'importe qui sur internet peut exécuter du code arbitraire sur votre serveur en lui envoyant une simple requête HTTP. Sans compte. Sans mot de passe. Sans clic.

Cet article est la version longue de l'avis envoyé à nos clients — ce qui a réellement cassé, pourquoi c'est pire qu'un CVE moyen, et la séquence exacte de commandes qui vous fait passer de vulnérable à corrigé-et-vérifié en une vingtaine de minutes.

Ce que signifie concrètement « RCE non authentifiée »

Les bulletins de sécurité rabâchent l'expression ; soyons concrets sur ce qui se passe quand l'un de ces bugs se déclenche :

1. Un attaquant envoie une requête HTTP à priori anodine à n'importe quel point d'entrée PHP de votre serveur — une page de login WordPress, une route d'API, même une URL « statique » qui finit par atteindre index.php.
2. La requête emprunte le chemin de code vulnérable et l'état interne de l'interpréteur se corrompt d'une manière que l'attaquant contrôle.
3. L'attaquant exécute du code avec l'identité du processus PHP — typiquement www-data, apache ou l'utilisateur du pool FPM.

Et là, c'est fini, vite. Cet utilisateur peut lire les identifiants de base de données dans le fichier de configuration, vider la base, installer une web shell, ajouter une tâche cron persistante, et utiliser la machine comme tremplin vers le reste de votre réseau. Les attaquants automatisent tout le cycle : exploitation, dépôt de l'implant, passage à la cible suivante. L'ensemble prend quelques secondes et se mesure en milliers de scans par heure.

Les deux bugs

L'avis du projet détient le détail technique faisant foi ; voici ce qui compte pour les opérateurs.

CVE-2026-109618 — RCE via corruption liée à la mémoire (out-of-memory) (GHSA-w8hw-w9fx-j79w). La gestion d'un dépassement de mémoire peut interrompre PHP alors que les données internes de la requête ne sont que partiellement initialisées — et le chemin de nettoyage de la requête peut alors traiter ces données invalides comme valides. La leçon se généralise et vaut d'être retenue : les chemins de gestion d'erreur sont du code, et ils s'exécutent précisément quand le système est le moins en mesure de se défendre.

CVE-2026-109619 — RCE via un état global résiduel (stale global state) (GHSA-6wmf-4rv5-p3rp). Un état interne détenu par la requête peut survivre après la libération de la mémoire qui le portait. Une requête ultérieure traitée par le même worker peut alors utiliser cet état résiduel avant que l'initialisation normale ne le réinitialise. Le modèle de requête de PHP repose sur le « shared nothing » — chaque requête démarre avec un état d'interpréteur propre — et ce bug brise exactement cette isolation, la fonction de conception qui a épargné à PHP des catégories entières de bugs pendant des décennies.

Les deux bugs sont joignables par le réseau, sans authentification ni interaction de l'utilisateur — exactement la combinaison qui produit un 9,2.

Pourquoi les serveurs en mod_php sont les plus exposés

Tout déploiement de PHP qui répond à des requêtes web est concerné, dans toutes ses formes modernes :

• PHP-FPM — le standard derrière nginx, Apache et Caddy
• Apache avec mod_php — la configuration la plus risquée
• php-cgi — toujours présent sur les vieilles piles
• FrankenPHP — le nouvel app-server à la mode
• LiteSpeed / OpenLiteSpeed

Le cas mod_php mérite qu'on s'y arrête. Avec FPM, PHP tourne dans des processus workers séparés : la corruption de mémoire est au moins contenue dans le pool. Avec mod_php, l'interpréteur est compilé dans le processus Apache lui-même — et l'avis confirme un exploit démontré où une requête non authentifiée peut déclencher l'attaque avant même que le moindre code application ne s'exécute. Un bug de corruption frappe alors le serveur web directement, en mémoire partagée, souvent avec des droits filesystem plus larges qu'un pool isolé. Si vous tournez encore en mod_php en 2026, considérez ce CVE comme votre budget de migration.

Et une subtilité qui piège les mutualisés et les panneaux (cPanel, Plesk, CyberPanel) : un serveur fait tourner plusieurs versions de PHP côte à côte. Mettre à jour le 8.3 ne change rien pour le pool 8.1 qui sert encore trois vieux sites. Il faut traquer chaque version présente sur la machine — on y revient plus bas.

Le correctif : vingt minutes chrono

1. Snapshot d'abord. Snapshot VM, ou au minimum sauvegarde des racines web et des bases. Un correctif de sécurité reste un changement, et tout changement mérite un chemin de retour. Deux minutes maintenant épargnent le jeu des reproches plus tard.

2. Mettez à jour les paquets.

# Debian / Ubuntu
apt update && apt upgrade php-*

# AlmaLinux / Rocky / RHEL
dnf update php-*

Sur panneaux : cPanel/WHM se met à jour via /scripts/upcp (les builds EasyApache 4 sont déjà disponibles), Plesk Obsidian depuis le panneau, et les utilisateurs CloudLinux doivent surveiller la page de statut CloudLinux pour les builds Alt-PHP. Les paquets des distributions priment sur les dépôts tiers ici — le remirepo maintenu par des bénévoles ne publie pas de correctifs le jour J, et le projet PHP lui-même recommande les paquets de distribution ou une compilation depuis les sources.

3. Redémarrez la pile web. L'étape que tout le monde saute :

systemctl restart php-fpm
systemctl restart apache2   # et/ou nginx

4. Vérifiez ce qui tourne réellement — la CLI et le SAPI web, et chaque version installée :

php -v

Puis déposez une sonde de deux lignes derrière votre vhost et chargez-la en HTTP :

<?php phpinfo();

Si la version affichée par phpinfo() ne correspond pas à celle du CLI, vous avez trouvé un pool qui n'a jamais été redémarré — retour à l'étape 3. Sous cPanel, vérifiez chaque version ea-php dans le MultiPHP Manager de WHM ; sous Plesk, la page des versions PHP du panneau. À faire par version, pas par serveur.

Deux publics souvent oubliés : quiconque fait tourner des candidatures au lancement (RC) de PHP 8.6.0 doit passer au RC4 — publié le jour même avec ces correctifs ; les builds RC antérieurs sont vulnérables. Et sur les PHP 8.1 et plus anciens, il n'y a tout simplement rien à mettre à jour au-delà de rétroportages minimaux en source pour 7.4 à 8.1 — votre issue de secours est une branche supportée ou un fournisseur qui rétroporte pour vous.

Impossible de corriger tout de suite ? Mesures d'attente honnêtes

Il arrive que la fenêtre de changement soit mardi et que le correctif tombe vendredi. L'avis est inhabituellement concret sur ce qui réduit l'exposition — et inhabituellement net : seule une mise à jour est une solution complète.

Contre CVE-2026-109618 (corruption OOM) :

• Fixez memory_limit = -1, de préférence là où les applications ne peuvent pas le redéfinir (php_admin_value dans le pool FPM ou la config Apache) — et auditez chaque pool, répertoire et application pour qu'aucune limite finie ne revienne en douce.
• Abaissez post_max_size : 8M pour les applications sans envoi de fichiers, 32M si les uploads sont nécessaires, avec upload_max_filesize en dessous. Appliquez aussi des limites côté serveur web ou proxy : taille décodée de la requête, nombre de champs, de parties multipart, d'en-têtes, profondeur d'imbrication — y compris pour les requêtes sans Content-Length utilisable.
• Utilisez une limite de conteneur ou de cgroup comme frontière de disponibilité qui ne tue que le worker affecté. Ne substituez pas RLIMIT_AS ou RLIMIT_DATA — ils peuvent eux-mêmes déclencher l'échec d'allocation vulnérable.

Contre CVE-2026-109619 (état global résiduel) :

• Fixez session.upload_progress.enabled = 0 et redémarrez chaque worker — via php.ini ou la configuration du pool/du serveur, appliquée avant l'analyse de la requête, pas via ini_set() ou le .user.ini du FPM. Cela bloque les chemins de session confirmés, pas toutes les variantes.
• Sous PHP 8.5, fixez fatal_error_backtraces = 0 et redémarrez chaque worker (bloque le chemin confirmé via les backtraces d'erreur fatale).
• Supprimez les réglages par requête qui émettent des diagnostics avant l'initialisation — masquer les diagnostics avec error_reporting, display_errors ou @ n'aide pas.
• Corrigez les erreurs fatales et les timeouts joignables par l'attaquant, y compris les échecs dans les callbacks et le traitement des uploads.

Voyez tout cela comme un garrot : cela réduit l'accessibilité du bug, sans le supprimer. Chaque heure de mitigation doit être une heure passée à tester la vraie mise à jour.

Comment savoir si quelqu'un est passé avant vous

L'exploitation étant déjà active, corriger n'est que la moitié du travail — l'autre moitié consiste à se demander « est-ce qu'on a été touchés ? ». À faire même sur les serveurs que vous croyez avoir corrigé vite :

• Journaux du serveur web : POST inhabituels vers des endpoints bizarres, rafales de 500 depuis une même IP ou un même ASN, requêtes au corps mal formé ou tronqué.
• Système de fichiers : des fichiers dans les racines web que vous n'avez jamais déployés — surtout de petits fichiers PHP à charge utile encodée (cherchez eval, assert, gzinflate, de longues chaînes base64), et des .htaccess ou fichiers de config modifiés récemment.
• Persistance : nouvelles tâches cron (crontab -l pour chaque utilisateur, plus /etc/cron*), unités systemd inconnues, clés SSH inattendues dans les authorized_keys.
• Comportement : processus méconnus, trafic sortant soutenu qui n'est pas le vôtre, pics de CPU sans trafic correspondant.
• Comparer avec la sauvegarde : un diff de la racine web contre la sauvegarde de la semaine dernière trouve les implants plus vite que n'importe quel scanner.

Si vous trouvez quelque chose : isolez la machine du réseau avant de nettoyer. Un serveur compromis est une pièce à conviction, pas juste une panne.

La partie ennuyeuse qui prévient la prochaine urgence

Une fois l'adrénaline retombée, faites le travail sans éclat qui rendra le prochain avis anodin :

• Mises à jour de sécurité automatiques. unattended-upgrades, dnf-automatic, ou l'interrupteur de votre panneau — choisissez, activez, et laissez les correctifs de sécurité arriver sans humain dans la boucle.
• Un PHP supporté. PHP 8.2 s'arrête le 31 décembre 2026. Tout ce qui est plus vieux que 8.2 n'est déjà plus supporté et ne survit que sur des rétroportages de fournisseurs. Les CVE qui tombent sur des branches mortes n'ont pas de correctifs — elles ont des nécrologies.
• Moins de surface. Supprimez les versions de PHP et les applications dont vous ne vous servez plus. Chaque interpréteur présent sur le disque est une porte à surveiller.
• Défense en profondeur. Un WAF, une liste blanche d'IP sur les interfaces d'administration, de la MFA partout où elle rentre. Aucune mesure ne doit être porteuse à elle seule.

En résumé

Deux bugs notés 9,2, des exploits déjà dans la nature, des correctifs déjà empaquetés. Cette fois, la distance entre « vulnérable » et « corrigé et vérifié » tient en une mise à jour, un redémarrage et un phpinfo() honnête par version installée — une vingtaine de minutes de travail pour dormir tranquille. Faites-le maintenant. Puis automatisez, pour que la prochaine fois que PHP publiera un correctif d'urgence, la seule chose à écrire soit l'invitation calendaire de la montée de version que vous aviez déjà planifiée.

Sources : PHP.net — avis de sécurité du 21 octobre 2026, GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp. Versions corrigées : 8.5.12, 8.4.27, 8.3.36, 8.2.35 (dernière mouture du 8.2 avant sa fin de vie le 31 décembre 2026).