• Contact

Failles critiques PHP2Shell (CVE-2026-109618, CVE-2026-109619) : comprendre, corriger, suivre les correctifs

  • 21 octobre 2026
  • 9 min. à lire

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.

CanalStatutVersions corrigées
php.net (sources)Disponible8.5.12, 8.4.27, 8.3.36, 8.2.35
UbuntuDisponible (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 DebianDisponible (Debian 12 et 13)8.5.12, 8.4.27, 8.3.36, 8.2.35
Bref (Lambda)Disponiblebref/bref 3.0.14 (layers 3.0.10) et 2.4.22 (layers 2.3.45)
PPA Sury pour UbuntuDisponible (Ubuntu 22.04 et 24.04)8.5.12, 8.4.27, 8.3.36, 8.2.35
DebianDisponible (DSA-6574-1 et DLA-4848-1)Debian 13 : php8.4 8.4.27-1deb13u1 ; Debian 12 : php8.2 8.2.35-1deb12u1
Images Docker officiellesDisponible8.5.12, 8.4.27, 8.3.36, 8.2.35
Amazon Linux 2023En 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

EnvironnementCVE-2026-109618CVE-2026-109619
Apache mod_phpExploit complet démontréExploit complet démontré
PHP-FPMVulnérable selon l’analyse du code, sans exploit complet démontréExploit démontré via la progression d’upload, selon l’application
FrankenPHPProbablement vulnérable, comme mod_phpPas de vecteur établi en configuration par défaut
LiteSpeed (LSAPI)Exploit applicatif probable, non validéCandidat sous conditions

Détecter les versions vulnérables

BrancheVersion corrigéeSupport sécurité jusqu’au
8.58.5.1231 décembre 2029
8.48.4.2731 décembre 2028
8.38.3.3631 décembre 2027
8.28.2.3531 décembre 2026
8.1, 8.0, 7.4Rétroportage source uniquementFin 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, RHEL

Pour 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)"
done

Sur 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 text

Corriger

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, RHEL

Ce que ça fait :

  • restart recharge le binaire corrigé et vide l’OPcache
  • /proc/<pid>/exe pointe vers un fichier marqué (deleted) si le processus a démarré avant la mise à jour
  • needrestart et needs-restarting listent 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] = off

Ce que ça fait :

  • session.upload_progress.enabled = off bloque 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ée
  • memory_limit = -1 supprime 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 par RLIMIT_AS ou RLIMIT_DATA, qui déclenchent précisément le chemin vulnérable
  • post_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 proxy
  • fatal_error_backtraces = off neutralise 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.

Références

Nicolas Verlhiac

Nicolas Verlhiac

Full stack software expert | E-commerce & CRM

Nous sommes spécialisés dans la création de solutions technologiques innovantes qui aident les entreprises à rester compétitives et à prospérer.

Prendre rendez-vous avec Nicolas

tracking-thumb