Suivi en direct : cet article est mis à jour au fil des publications. Dernière mise à jour le 21 octobre 2026 à 18h25.
Le 21 octobre 2026, PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent PHP2Shell, deux vulnérabilités d’exécution de code à distance sans authentification notées 9.2 en CVSS v4.0, exploitables sous Apache mod_php avant même l’exécution du code applicatif et déjà exploitées. Les correctifs atteignent chaque canal de distribution à son propre rythme. Découvrez comment évaluer votre exposition, corriger et suivre leur disponibilité.
Le 20 octobre au soir, l’équipe sécurité de PHP annonçait une release de sécurité à date fixe sans en dévoiler le contenu, le jour même où l’éditeur de sécurité offensive watchTowr confirmait publiquement l’existence de deux failles sous embargo dont des informations avaient fuité. Le 21 octobre à 16h00 (heure de Paris), PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ont été publiées avec leurs avis de sécurité : les deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, permettent une exécution de code à distance sans authentification. Baptisées « PHP2Shell » en référence à Log4Shell, elles font l’objet d’exploitations observées dès le 21 octobre par watchTowr sur son réseau de honeypots, et Cloudflare signale lui aussi les premières attaques. Le CERT-FR a émis l’alerte CERTFR-2026-ALE-014, le CERT-EU l’avis de sécurité 2026-018, et le BSI allemand un avertissement de niveau orange, le troisième sur une échelle de quatre.
Mettez à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Les premières exploitations sont observées depuis le 21 octobre. Toutes les installations PHP qui servent des requêtes web sont concernées : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est maximal avec mod_php, pour lequel un exploit fonctionne avant même l’exécution du code applicatif, et selon l’équipe sécurité de PHP, aucune configuration ne remplace la mise à jour.
Ce type d’avis déclenche chez nous une procédure standard sur les environnements que nous maintenons en condition opérationnelle : nous en partageons ici le déroulé, et nous suivons dans cet insight la disponibilité du correctif sur chaque canal de distribution.
Suivi des correctifs
Le correctif n’arrive pas partout au même moment : php.net publie les sources, puis chaque canal reconstruit et diffuse ses binaires selon son propre calendrier. Ce tableau est mis à jour à chaque nouvelle publication.
| Canal | Statut | Versions corrigées |
|---|---|---|
| php.net (sources) | Disponible | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Ubuntu | Disponible (USN-8948-1 et USN-8948-2) | 22.04 LTS : php8.1 8.1.2-1ubuntu2.28 ; 24.04 LTS : php8.3 8.3.6-0ubuntu0.24.04.13 ; versions plus récentes : php8.5 ; versions plus anciennes : USN-8948-2 |
| Dépôt Sury pour Debian | Disponible (Debian 12 et 13) | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Bref (Lambda) | Disponible | bref/bref 3.0.14 (layers 3.0.10) et 2.4.22 (layers 2.3.45) |
| PPA Sury pour Ubuntu | Disponible (Ubuntu 22.04 et 24.04) | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Debian | Disponible (DSA-6574-1 et DLA-4848-1) | Debian 13 : php8.4 8.4.27-1 |
| Images Docker officielles | Disponible | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Amazon Linux 2023 | En attente | – |
| Dépôt Remi (RHEL, AlmaLinux, Rocky) | Pas de mise à jour le 21 octobre | – |
L’équipe PHP recommande aux utilisateurs du dépôt Remi, maintenu par un bénévole, de basculer vers les paquets de leur distribution ou de compiler depuis les sources pour pouvoir corriger immédiatement.
Journal des mises à jour
- 20 octobre, 22h32 : annonce d’une release de sécurité critique par l’équipe sécurité de PHP ; watchTowr confirme le même jour l’existence de deux RCE sous embargo, et le CERT-EU publie son avis 2026-018.
- 21 octobre : le CERT-FR émet l’alerte CERTFR-2026-ALE-014, avec des contournements provisoires, et le BSI allemand un avertissement de niveau orange qui envisage une déconnexion temporaire des serveurs web ne pouvant être corrigés rapidement.
- 21 octobre, entre 15h30 et 16h10 : publication des avis de sécurité, des identifiants CVE et de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, puis de l’USN-8948-1 d’Ubuntu et de Bref 3.0.14.
- 21 octobre : le dépôt Sury publie les paquets corrigés pour Debian 12 et 13, puis pour Ubuntu 22.04 et 24.04.
- 21 octobre : watchTowr observe les premières exploitations sur son réseau de honeypots et Cloudflare signale des attaques émergentes ; selon l’agence dpa, la ville de Mayence a mis son portail hors ligne par précaution.
- 21 octobre : Debian publie la DSA-6574-1, qui corrige php8.4 dans Debian 13.
- 21 octobre, 17h40 : les images Docker officielles 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont publiées ; Debian corrige php8.2 dans Debian 12 (DLA-4848-1), Ubuntu étend le correctif à ses anciennes versions (USN-8948-2) et Bref publie la version 2.4.22.
Comprendre les deux failles
Les deux vulnérabilités sont notées 9.2 en CVSS v4.0 (AV:N/AC:H/AT:P/PR:N/UI:N) : exploitables à distance, sans authentification et avec un impact maximal, mais sous des conditions d’attaque qui expliquent que le score n’atteigne pas 10. Des codes d’exploitation présentés comme fonctionnels circulent déjà publiquement : Tenable rappelle que ce type de code non vérifié embarque parfois un malware, et il ne doit jamais être exécuté hors d’un environnement isolé.
CVE-2026-109618 : corruption sur dépassement mémoire
PHP interrompt une requête qui dépasse sa limite mémoire par un saut direct (longjmp()) hors du contexte en cours. Si ce dépassement survient alors que des données internes de la requête ne sont que partiellement initialisées, la procédure de fin de requête les traite comme valides, ce qui ouvre la voie à une exécution de code. L’attaquant n’a pas besoin d’un bug applicatif pour provoquer ce dépassement : plusieurs faiblesses du parsing multipart suffisent, notamment une requête sans Content-Length exploitable qui échappe au contrôle de post_max_size, un nombre illimité d’en-têtes par partie, ou des champs de fichier vides que max_file_uploads ne comptabilise pas.
Avec Apache mod_php, la fin de requête s’exécute même lorsque son démarrage a échoué : l’exploit complet a été validé en HTTP avec les limites par défaut, avant toute exécution du code applicatif. PHP-FPM termine le processus enfant dans ce cas, mais reste vulnérable selon l’analyse du code lorsque le dépassement survient après le démarrage de la requête.
CVE-2026-109619 : état global résiduel entre deux requêtes
Un worker PHP conserve des états globaux (erreurs, session, extensions) qui pointent vers la mémoire d’une requête. Si une erreur fatale, un dépassement mémoire ou un timeout empêche leur réinitialisation, la requête suivante traitée par le même worker peut les réutiliser avant son initialisation normale : c’est un use-after-free, qu’un agencement maîtrisé du tas transforme en exécution de code. Deux chemins sont confirmés : la progression d’upload de session (session.upload_progress, activée par défaut et sans appel nécessaire à session_start()), validée contre mod_php et PHP-FPM, et les traces d’erreurs fatales de PHP 8.5 (fatal_error_backtraces), validées contre mod_php. Les avertissements émis par une configuration INI appliquée à chaque requête (php_value dans un .htaccess, paramètre PHP_VALUE transmis par nginx) constituent un autre point d’entrée.
Exposition par environnement
| Environnement | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Apache mod_php | Exploit complet démontré | Exploit complet démontré |
| PHP-FPM | Vulnérable selon l’analyse du code, sans exploit complet démontré | Exploit démontré via la progression d’upload, selon l’application |
| FrankenPHP | Probablement vulnérable, comme mod_php | Pas de vecteur établi en configuration par défaut |
| LiteSpeed (LSAPI) | Exploit applicatif probable, non validé | Candidat sous conditions |
Détecter les versions vulnérables
| Branche | Version corrigée | Support sécurité jusqu’au |
|---|---|---|
| 8.5 | 8.5.12 | 31 décembre 2029 |
| 8.4 | 8.4.27 | 31 décembre 2028 |
| 8.3 | 8.3.36 | 31 décembre 2027 |
| 8.2 | 8.2.35 | 31 décembre 2026 |
| 8.1, 8.0, 7.4 | Rétroportage source uniquement | Fin de support |
La version renvoyée par php -v n’est pas toujours celle qui sert vos pages, et les paquets de distribution conservent souvent le numéro de version amont : pour eux, c’est la présence des CVE dans le changelog du paquet installé qui fait foi.
# Version du CLI et pools PHP-FPM actifs
php -v
systemctl list-units 'php*-fpm*' --no-legend
# Apache charge-t-il mod_php ?
apachectl -M 2>/dev/null | grep -i php
# Paquet de distribution : le correctif est-il installé ?
zgrep -m1 CVE-2026-109618 /usr/share/doc/php8.3-fpm/changelog.Debian.gz # Debian, Ubuntu
rpm -qa 'php*-fpm*' | xargs -r rpm -q --changelog | grep -m1 CVE-2026-109618 # Amazon Linux, RHELPour les conteneurs, la version se lit directement dans chaque conteneur en cours d’exécution :
for c in $(docker ps -q); do
echo "$(docker inspect -f '{{.Name}} {{.Config.Image}}' "$c") $(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null)"
doneSur un parc EC2 géré par AWS Systems Manager, une seule commande interroge toutes les instances, sans connexion SSH :
CMD_ID=$(aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=tag:Environment,Values=production" \
--parameters 'commands=["php -r \"echo PHP_VERSION;\""]' \
--query "Command.CommandId" --output text)
aws ssm list-command-invocations --command-id "$CMD_ID" --details \
--query "CommandInvocations[].[InstanceId,CommandPlugins[0].Output]" --output textCorriger
Paquets Debian et Ubuntu
Les paquets corrigés sont disponibles pour Ubuntu (USN-8948-1 et USN-8948-2), Debian 13 (DSA-6574-1) et Debian 12 (DLA-4848-1), ainsi que dans le dépôt Sury pour Debian comme pour Ubuntu.
sudo apt update
sudo apt install --only-upgrade $(dpkg -l 'php8.3*' | awk '/^ii/ {print $2}')Amazon Linux 2023
Amazon Linux 2023 verrouille ses dépôts sur une version de release : un simple dnf upgrade n’installe pas les paquets publiés dans une release ultérieure. Dès la publication de l’avis ALAS correspondant :
sudo dnf check-release-update
sudo dnf upgrade --releasever=latest 'php*'Images Docker officielles
Les tags corrigés (8.5.12, 8.4.27, 8.3.36 et 8.2.35) sont publiés : le paramètre --pull force la récupération de la nouvelle image de base au lieu de celle présente en cache :
docker build --pull --no-cache -t mon-app:php-patch .Un tag de branche (php:8.4-fpm) suit automatiquement les correctifs, alors qu’un tag de version complète ou un digest @sha256: doit être incrémenté dans une branche prête à passer dans votre pipeline d’intégration continue.
Lambda avec Bref
Bref 3.0.14 embarque les layers corrigés : un composer require bref/bref:^3.0.14 suivi d’un redéploiement suffit. Pour un déploiement Terraform ou SAM, ou pour Bref 2, les ARN des nouveaux layers sont publiés sur runtimes.bref.sh.
Redémarrer et vérifier
Le piège classique est un paquet mis à jour sur le disque tandis que PHP-FPM ou Apache continue de servir l’ancien binaire chargé en mémoire.
# PHP-FPM (adapter la version), ou Apache avec mod_php
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # httpd sur RHEL et Amazon Linux
# "(deleted)" signale un processus maître encore sur l'ancien binaire
sudo ls -l /proc/$(pgrep -o php-fpm)/exe
# Services à relancer après une mise à jour
sudo needrestart -r l # Debian, Ubuntu
sudo dnf needs-restarting -s # Amazon Linux, RHELCe que ça fait :
restartrecharge le binaire corrigé et vide l’OPcache/proc/<pid>/exepointe vers un fichier marqué(deleted)si le processus a démarré avant la mise à journeedrestartetneeds-restartinglistent tous les services qui utilisent encore des fichiers remplacés
Si la mise à jour ne peut pas être immédiate
Pour une application exposée sur Internet, le CERT-EU recommande de l’isoler des réseaux publics jusqu’à l’application du correctif, et le BSI envisage de même une déconnexion temporaire du serveur web. À défaut, l’équipe sécurité de PHP et le CERT-FR détaillent des mesures qui réduisent l’exposition aux chemins d’attaque connus, sans rendre une installation sûre. Elles s’appliquent dans la configuration chargée au démarrage (php.ini, pool FPM, configuration Apache), jamais via ini_set() ou un .user.ini, et exigent un redémarrage de tous les workers.
; Pool PHP-FPM (ex. /etc/php/8.3/fpm/pool.d/www.conf)
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
; PHP 8.5 uniquement
php_admin_flag[fatal_error_backtraces] = offCe que ça fait :
session.upload_progress.enabled = offbloque les chemins de session confirmés pour CVE-2026-109619 ; l’avis recommande de le laisser désactivé après la mise à jour si la fonctionnalité n’est pas utiliséememory_limit = -1supprime le dépassement mémoire contrôlable exploité par CVE-2026-109618 : la mémoire se borne alors par une limite cgroup par worker (memory.max), jamais parRLIMIT_ASouRLIMIT_DATA, qui déclenchent précisément le chemin vulnérablepost_max_size = 8M(32M si l’application accepte des uploads) réduit la surface du parsing multipart, à compléter par des limites de taille, d’en-têtes et de parties au niveau du reverse proxyfatal_error_backtraces = offneutralise le chemin confirmé sur PHP 8.5
Si l’application n’accepte aucun envoi de formulaire multipart, le CERT-FR recommande de bloquer ces requêtes au niveau du pare-feu applicatif, ou à défaut de les superviser. Sans WAF, nginx peut les rejeter directement :
# Dans le bloc server : rejet des requêtes multipart sur un site sans upload
if ($content_type ~* "^multipart/") {
return 403;
}Il convient enfin de supprimer les surcharges INI appliquées à chaque requête qui émettent des avertissements (php_value dans un .htaccess, PHP_VALUE transmis par le frontal), et, si les performances le permettent, de limiter chaque worker à une seule requête avec pm.max_requests = 1. Masquer les erreurs avec error_reporting, display_errors ou @ ne protège en rien.
PHP 8.1 et versions antérieures
PHP 8.1 et les branches plus anciennes ne reçoivent plus de mises à jour du projet, mais compte tenu de la gravité des failles, l’équipe sécurité a publié des rétroportages minimaux du correctif pour PHP 7.4, 8.0 et 8.1, sous forme de branches du dépôt php-src destinées à ceux qui compilent depuis les sources. Les distributions LTS corrigent également les versions qu’elles embarquent : Ubuntu 22.04 dispose déjà d’un paquet php8.1 corrigé. Le CERT-FR, qui considère toutes les versions depuis PHP 5 comme affectées, recommande pour les versions non maintenues d’isoler les équipements concernés, puis de migrer vers une version maintenue. Ces solutions restent des sursis, d’autant que PHP 8.2 sort lui-même du support sécurité le 31 décembre 2026 : la migration vers 8.4 ou 8.5, dont les nouveautés la rendent par ailleurs intéressante, mérite d’être planifiée dès maintenant, comme pour la fin de vie de MySQL 8.0.
Avant : deux RCE sans authentification exploitables avant le code applicatif, sur un parc dont les versions de PHP ne sont connues qu’approximativement
Après : un inventaire à jour, des versions corrigées déployées dès leur disponibilité sur chaque canal et des workers redémarrés sur le bon binaire
Les deux chemins d’exploitation sont désormais documentés publiquement, pour les équipes qui défendent comme pour celles qui attaquent : le délai de mise à jour se mesure maintenant en heures, et non en cycles de maintenance.