Le 21 octobre 2026, l’équipe PHP a publié en urgence PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux failles critiques baptisées « PHP2Shell » : CVE-2026-109618 et CVE-2026-109619. Une simple requête HTTP, sans authentification, peut suffire à exécuter du code sur le serveur avec les droits du worker web. Mettre à jour WordPress n’y change rien : c’est PHP lui-même qui est touché.

Voici comment faire le tri entre ce qui dépend de vous et ce qui dépend de votre hébergeur.

Transparence : vu l’urgence, cet article compile les annonces officielles (php.net, CERT-FR, distributions, hébergeurs) publiées les 21 et 22 octobre 2026, revérifiées le 22 octobre au soir. Les commandes viennent de ces sources ; je ne les ai pas encore toutes rejouées dans mon lab. Les passages concernés sont signalés, et l’article sera mis à jour au fil de mes tests.

1. PHP2Shell, kézaco ?

Deux bugs distincts, notés 9.2/10 en CVSS v4 par l’équipe PHP (l’avis du CERT-FR les classe aussi en exécution de code à distance) :

• CVE-2026-109618 (OOM corruption) : quand une requête dépasse le memory_limit au mauvais moment, PHP laisse des données à moitié initialisées que le nettoyage de fin de requête traite comme valides. Sur mod_php, ça se déclenche avant même que votre code s’exécute.
• CVE-2026-109619 (stale global state) : après une erreur fatale, un état interne survit alors que sa mémoire est libérée. La requête suivante du même worker peut la réutiliser (use-after-free), notamment via session.upload_progress, activé par défaut.

D’après php.net, tout PHP qui sert du web est concerné : PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. Les branches 8.1, 8.0 et 7.4 ont reçu des rétroportages au format source (pour un paquet, voyez votre distribution ou votre hébergeur). Rien pour 7.3 et plus ancien, que le CERT-FR liste aussi comme affectés.

Côté exploitation, les sources divergent :

• Amazon a relevé une tentative dès le 17 octobre et parle d’exploitation « large », sans savoir si ces tentatives ont réussi.
• Datadog a reproduit l’exécution de code sur PHP 8.5.11 avec une seule requête POST.
• La PHP Foundation n’avait identifié aucun exploit fonctionnel au moment de la publication, et Red Hat juge l’exécution de code difficile sur un PHP-FPM par défaut.
• Le CERT-FR connaît des PoC « pour des déploiements spécifiques ». La CISA n’avait observé aucune exploitation le 21 octobre, et aucune des deux CVE n’était dans son catalogue KEV le 22.

Attention aux faux PoC, dont certains embarquent du malware d’après Tanium. Bref, on patche aujourd’hui, pas la semaine prochaine.

2. Vérifier la version réellement servie

Le PHP en ligne de commande n’est pas forcément celui du site. Le plus fiable : un phpinfo à la racine.

<?php phpinfo();

Notez « PHP Version » et « Build Date », puis supprimez-le.

Autre piège : un vieux numéro ne veut pas forcément dire vulnérable. Beaucoup d’éditeurs rétroportent le correctif sans changer le numéro : Ubuntu 24.04 corrige dans 8.3.6-0ubuntu0.24.04.13 (tracker Ubuntu), CloudLinux dans alt-php83 8.3.35-6 (note CloudLinux). Comparez donc la version du paquet au tracker de votre distribution.

3. Sur un hébergement mutualisé

L’hébergeur patche ; à vous de vérifier qu’il l’a fait et que vous n’êtes pas sur une vieille branche.

o2switch

D’après Clubic, o2switch a désactivé session.upload_progress le 21 octobre dès 8 h 07, mais à 16 h 40 les binaires étaient encore en 8.3.35 et 8.4.26, en attente des paquets CloudLinux. Ils sont sortis dans la nuit du 21 au 22, entre 2 h et 3 h, heure de Paris (php2shellcheck), sans changer les numéros.

• Version affichée : elle peut rester en 8.3.35 ou 8.4.26 même une fois patchée. Fiez-vous à la date de build du phpinfo (je n’ai pas pu le vérifier sur un compte o2switch).
• Changer de branche : cPanel, Logiciels, « Sélectionner une version de PHP ». Les extensions ne suivent pas : réactivez mbstring, gd, intl, etc.
• Statut : au 22 octobre au soir, toujours pas d’annonce officielle. Une réponse du support relayée sur le forum SPIP indique que les paquets CloudLinux seront déployés automatiquement. Déploiement non confirmé : dans le doute, demandez au support.

OVHcloud

D’après sa page de statut, OVHcloud a posé un contournement le 21 octobre à 10 h, puis des règles WAF, et toutes les versions de 7.4 à 8.5 étaient patchées à 19 h 53. La maintenance est prolongée jusqu’au 26 octobre à 20 h (heure de Paris) pour traiter les versions plus anciennes. Pour changer de version, éditez le .ovhconfig à la racine FTP (documentation OVHcloud) :

app.engine=php
app.engine.version=8.4
container.image=stable64

php -v en SSH n’est pas fiable à 100 %, rappelle la communauté OVHcloud.

Hostinger

D’après son billet, Hostinger a fini de déployer le correctif (5.2 à 8.5) le 22 octobre à 8 h 44, heure de Paris, sur toutes ses offres sauf les VPS. Dans hPanel, PHP Info doit afficher une « Build Date » du 21 octobre 2026 ou plus récente.

Infomaniak, IONOS, PlanetHoster

Ces trois-là ont communiqué officiellement depuis :

• Infomaniak : correctifs déployés le 22 octobre au matin sur le mutualisé et les Serveurs Cloud, de 7.4 à 8.5 (statut Infomaniak). Les numéros restent en 8.4.26, 8.3.35, etc., mais les builds sont recompilés. En dessous de 7.4, changez de version.
• IONOS : plateformes gérées par IONOS mises à jour, incident clos le 22 octobre à 12 h 10, heure de Paris (communiqué IONOS). Sur un VPS ou un dédié, c’est à vous de patcher.
• PlanetHoster : déploiement encore en cours le 22 octobre à 19 h (avis PlanetHoster). D’ici là, les requêtes multipart/form-data sont bloquées, donc les uploads peuvent renvoyer une erreur 403. Côté cPanel, les comptes en dessous de 7.4 passent en 7.4.

Ailleurs, même méthode : phpinfo, page de statut, et ticket au support si la date de build précède le 21 octobre. Et si vous êtes encore en 8.1 ou plus ancien, migrez : la 8.2 elle-même sera en fin de vie le 31 décembre 2026, d’après l’annonce de la 8.2.35.

4. Sur un VPS, un dédié ou un homelab

Debian et Ubuntu

Le tracker Debian donne php8.4 8.4.27-1~deb13u1 pour Trixie (DSA-6574-1) et php8.2 8.2.35-1~deb12u1 pour Bookworm (DLA-4848-1). Bullseye n’est corrigé que par l’ELTS payant de Freexian (ELA-1853-1). Sur Ubuntu (USN-8948-1), 20.04 et plus anciennes demandent Ubuntu Pro.

sudo apt update

sudo apt upgrade

Vérifiez la version du paquet (ici PHP-FPM 8.4) :

apt policy php8.4-fpm

Puis redémarrez, sinon les workers gardent l’ancien binaire :

sudo systemctl restart php8.4-fpm

sudo systemctl restart apache2

Dépôt d’Ondřej Surý

Si vous avez suivi mon tuto pour changer de version de PHP sur Debian, votre PHP vient du dépôt Sury, et ce sont ses numéros qui comptent. Sur le PPA d’Ondřej, 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont en ligne depuis le 21 octobre, avec des rebuilds de 7.0 à 8.1, puis de 5.6 le 22. Mêmes commandes apt, en redémarrant chaque phpX.Y-fpm. Mon tuto de 2023 utilise apt-key, désormais déprécié : suivez plutôt la méthode actuelle.

RHEL, Rocky (et Remi)

Red Hat et Rocky ont publié leurs errata les 21 et 22 octobre (RHSA/RLSA-2026:87070 et suivants). D’après php2shellcheck, le 22 au soir, le flux php:8.4 de RHEL 9 restait sans correctif et RHEL 7 était « en cours d’analyse ». Côté Remi, les index du dépôt montrent des paquets 8.4.27 et 8.3.36 datés du 21 octobre.

sudo dnf upgrade 'php*'

Vérifiez le changelog plutôt que le numéro :

rpm -q --changelog php-cli | grep CVE-2026-109618

Panneaux cPanel, CloudLinux, Plesk, aaPanel

• cPanel / EasyApache 4 : d’après le support cPanel, lancez yum clean all && yum makecache, puis /scripts/update-packages, et vérifiez avec rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618. cPanel lui-même a aussi des builds corrigés (11.110.0.153, 11.134.0.66, 11.136.0.50, 11.138.0.18).
• CloudLinux (alt-php) : yum clean all && yum update 'alt-php*' 'ea-php*' -y, puis redémarrage d’Apache et de PHP-FPM, plus pkill lsphp sous LiteSpeed (note CloudLinux). Pas de correctif pour alt-php44 et alt-php51.
• Plesk : mettez à jour Plesk lui-même (18.0.80 Update 11 ou 18.0.81 Update 4, d’après php2shellcheck) en plus des paquets PHP.
• aaPanel : si vous l’avez installé après mon test d’aaPanel, les correctifs 7.4 à 8.5 sont dans l’App Store (non vérifié sur mon instance).

Docker

Les images officielles php ont été reconstruites le 21 octobre (PR docker-library). Épinglez la version corrigée :

FROM php:8.4.27-fpm

Puis reconstruisez en forçant le téléchargement de l’image de base :

docker build --pull --no-cache -t monapp:patched .

docker compose up -d

Windows (XAMPP, WampServer, Laragon)

Si ce PHP de dev est exposé, remplacez le dossier PHP de la pile par les binaires corrigés, en gardant votre php.ini. Manip non testée.

5. Si vous ne pouvez pas patcher tout de suite

L’équipe PHP insiste : aucune de ces mesures ne rend l’installation sûre. Elles se mettent dans le php.ini ou le pool FPM, jamais via ini_set() ni .user.ini, puis on redémarre tous les workers.

Pour CVE-2026-109619 :

session.upload_progress.enabled = Off

En pool PHP-FPM, d’après le CERT-FR :

php_admin_flag[session.upload_progress.enabled] = off

Sur PHP 8.5 uniquement :

fatal_error_backtraces = 0

Pour CVE-2026-109618, php.net recommande de lever la limite mémoire de façon non modifiable par l’application, avec un post_max_size bas (8M, ou 32M avec upload) :

php_admin_value[memory_limit] = -1

post_max_size = 8M

Revers : un script gourmand peut saturer la machine. Gardez un plafond au niveau du conteneur ou du cgroup, mais pas RLIMIT_AS ni RLIMIT_DATA, qui déclenchent le chemin vulnérable. L’avis GitHub cite aussi pm.max_requests = 1 si les performances importent peu. Je n’ai pas mesuré l’effet de ces réglages : testez sur une préprod.

Côté frontal, limitez la taille des requêtes, par exemple avec client_max_body_size sous Nginx :

client_max_body_size 8m;

Sans formulaires multipart, le CERT-FR suggère de les bloquer ou surveiller au WAF. Il précise que ces contournements ne sont pas qualifiés et recommande d’isoler ce qui ne peut pas être corrigé. Derrière Cloudflare, des règles managées sont actives même en offre gratuite, si le trafic passe par le proxy (nuage orange). En offre payante, vérifiez que le Managed Ruleset est en mode blocage.

6. Après le patch : vérifier et chercher des traces

Refaites le phpinfo pour chaque version et chaque pool. Sans besoin de progression d’upload, l’avis GitHub conseille de la laisser désactivée après le patch.

Petit bémol : 8.4.27 et 8.5.12 contiennent une régression SimpleXML qui peut faire planter un worker avec zend_mm_heap corrupted. Le correctif est dans le code source, mais aucune nouvelle version n’était sortie au 22 octobre. Ce n’est pas une raison pour revenir à une version vulnérable.

Autre bruit : un chercheur affirme avoir contourné le correctif sur 8.5.12, dans des conditions précises. Selon Cyber Kendra, ce n’était ni reproduit ni confirmé par l’équipe PHP au 22 octobre. Je le signale sans pouvoir le confirmer.

Pour les traces, remontez au moins au 17 octobre, comme le conseille Amazon. D’après Datadog, trois signaux méritent d’être corrélés :

• Logs PHP : des « Allowed memory size … exhausted » localisés « in Unknown on line 0 », signe d’un échec avant tout script.
• Logs Apache : des workers tués par une Segmentation fault, typique d’un exploit qui tâtonne.
• Processus : un sh ou un bash lancé par www-data, l’indice le plus direct d’une exécution réussie.

Premier signal (chemin selon votre config) :

grep "in Unknown on line 0" /var/log/php8.4-fpm.log

Shells lancés par le serveur web :

ps -ef --forest

Un exploit réussi peut renvoyer un simple HTTP 200. En cas de doute, cherchez les fichiers déposés (voir Web Shell et sécurité) et ressortez mon recueil d’outils pour traquer les processus douteux sous Debian. Changez aussi les secrets accessibles à PHP.

Côté IOC, Tanium n’en voyait pas d’officiels, mais Amazon a publié six adresses IP, dont 103.216.220.92, en précisant qu’il s’agit d’infrastructures d’anonymisation partagées : à investiguer plutôt qu’à bloquer. Il suggère aussi de chercher dans les logs WAF les POST contenant PHP_SESSION_UPLOAD_PROGRESS.

7. Et voilà

Sur un mutualisé, vérifiez la date de build et relancez le support si besoin. Sur votre serveur, mettez à jour, redémarrez tous les workers et fouillez les logs depuis le 17 octobre. Et si un vieux site traîne en PHP 7 ou 8.1, vous avez la meilleure excuse pour le migrer, avec mon petit tuto de changement de version sur Debian comme point de départ.