Failles PHP de la semaine : bilan sécurité au 26 octobre 2026

Entre le 19 et le 26 octobre 2026, PHP2Shell (CVE-2026-109618 et CVE-2026-109619, CVSS v4 9.2) est passé de tentatives massives à une exécution de commandes démontrée, sur des honeypots. Le 24/10, le chercheur Adel Karimi a publié 35 shells obtenus sur trois honeypots Apache mod_php en PHP 8.4.26, via CVE-2026-109618. Aucune compromission de victime réelle n’est confirmée par une source primaire au 26/10. Le correctif date du 21/10 (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35). Selon votre chaîne de build, il a pu n’arriver dans vos images que quatre jours plus tard. La décision à prendre ce lundi ne change pas : patcher PHP, reconstruire les images, redémarrer tous les workers.

Cet article ne refait pas le tour des deux CVE : le mécanisme, les versions et les commandes de mise à jour sont dans notre guide de patch PHP2Shell pour Symfony sous Docker. Il fait le point sur ce qui a bougé depuis le 22/10 : des correctifs de distributions arrivés en cascade, des mitigations qui ne ferment pas tout, un troisième avis (CVE-2026-115560) sans correctif publié, et un contournement d’authentification critique dans Laravel. Symfony, lui, n’a publié aucun advisory sur la période.

Publié le 26/10/2026, sources vérifiées le 26/10 : catalogue CISA KEV (flux du 23/10), php-src, API Red Hat, rapport de Karimi. La situation évolue : revérifiez les sources primaires avant d’agir sur un point daté.

Quelles failles PHP traiter cette semaine (19 → 26 octobre 2026) ?

• PHP2Shell (CVE-2026-109618 et CVE-2026-109619, CVSS v4 9.2) : corrigé le 21/10 en 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Exécution de commandes démontrée sur honeypots le 24/10, pas au catalogue CISA KEV. Action : patch du runtime, rebuild, redémarrage des workers.
• CVE-2026-115560 (avis php.net du 23/10) : aucun correctif publié, aucun CVSS, aucune fiche CVE publique. Mitigation : session.upload_progress.enabled=0, à garder jusqu’à la prochaine release de bugfix, non datée.
• Laravel CVE-2026-114509 (CVSS v4 9.2) : contournement d’authentification du guard token, corrigé en 12.68.0 et 13.29.0.
• Livewire 4 (de 4.3.0 à 4.4.7) : contournement de #[Authorize], corrigé en 4.4.8, sans CVE.
• Drupal contrib (21/10) : trois modules critiques, dont deux RCE.
• Symfony : aucun advisory ni release de patch du 19 au 26/10. Dernier lot le 14-15/10, trois dénis de service.
• Composer et Packagist : rien de notable sur la période.

PHP2Shell est-il vraiment exploité ?

Oui, l’exécution de commandes est démontrée, mais sur des honeypots, pas sur des victimes. La chronologie tient en trois dates. Le 17/10, Amazon voit une première tentative sur ses honeypots MadPot, quatre jours avant la divulgation. Le 21/10, Amazon observe plusieurs PoC dès 02:00 UTC environ, avant la levée de l’embargo, et watchTowr voit l’exploitation des deux CVE sur son réseau de capteurs. Le 24/10, Adel Karimi publie un rapport détaillé, avec captures réseau mises en ligne le 26/10. Marcus Hutchins y voit « by far the highest quality confirmation » d’exploitation in-the-wild vue jusque-là.

Le rapport mérite d’être lu pour ce qu’il dit, pas pour le titre de BleepingComputer (« now successfully exploited in the wild »), qui laisse entendre des compromissions réelles. Ce qu’il établit :

• Cibles : trois honeypots jetables, PHP 8.4.26 sous Apache mod_php avec un seul worker et memory_limit à 128 MiB. Karimi parle lui-même d’une configuration « favorable » : un seul worker, c’est le même processus à chaque étape. Le rapport ne mesure aucune fiabilité sur d’autres configurations.
• Faille : la chaîne est « consistent with CVE-2026-109618 ». Aucun chemin distinct via CVE-2026-109619 n’est établi.
• Technique : quatre POST multipart par tentative (pression mémoire, divulgation, pression mémoire, exécution), avec un PHPSESSID surdimensionné qui fait fuiter 800 KiB de mémoire pour contourner l’ASLR. C’est la technique du PoC public, pas une primitive nouvelle.
• Résultat : 35 shells lancés par les workers Apache, depuis deux grappes d’IP (15.204.59.70, 162.35.99.94). Les commandes sont des preuves et des callbacks (id, curl, wget), et aucun fichier de seconde étape n’a été observé.

Côté victimes réelles, aucune compromission n’est confirmée par une source primaire au 26/10. Unit 42 a même retiré le 25/10 sa mise à jour du 23, qui reliait l’intrusion d’une agence gouvernementale européenne à PHP2Shell : ce lien ne tient plus. CrowdStrike ne voyait aucune exploitation réussie le 23/10. L’attribution reste mince : Sophos a bloqué une tentative d’installer « Potassium », une variante probable de Mirai, et VulnCheck affirme détenir son propre exploit de CVE-2026-109618, réservé à ses clients et non vérifié indépendamment.

CISA KEV : aucune entrée. Le flux du catalogue (version 2026.10.23, publiée le 23/10 à 19:30 UTC, toujours servi le 26/10) ne contient ni CVE-2026-109618, ni CVE-2026-109619, ni CVE-2026-115560. L’alerte CISA du 21/10, révisée le 23, indiquait n’avoir observé aucune exploitation réussie. Le rapport de Karimi est postérieur à ce flux : un ajout cette semaine reste possible. Avant de l’affirmer en comité, consultez le catalogue KEV.

Sur l’exposition, ne retenez pas un chiffre unique. Les estimations vont de 1,9 million d’hôtes (Tenable) à 22,6 millions d’instances (Unit 42, sans méthodologie publiée), parce qu’elles ne comptent pas la même chose. Le seul ordre de grandeur utile vient de Qualys, via SecurityWeek : environ 199 000 instances corrigées douze heures après la divulgation, contre près de 110 millions sur PHP 5.4 à 8.1, des branches sans release officielle. La moitié ou plus du parc PHP tourne hors support sécurité.

Les mitigations suffisent-elles ? Non, et une troisième faille est apparue

La position de php.net n’a pas bougé : les réglages de configuration réduisent l’exposition sans rendre une installation sûre. Datadog Security Labs détaille pourquoi, et c’est le point à retenir si vous avez posé des mitigations en attendant votre canal de patch.

• session.upload_progress.enabled=0 ne couvre que le chemin d’upload de CVE-2026-109619.
• Le chemin des backtraces d’erreur fatale (PHP 8.5 uniquement) demande en plus fatal_error_backtraces=0.
• CVE-2026-109618 est un défaut distinct : un échec d’allocation laisse un bucket de hash à moitié initialisé. Aucun réglage d’upload ne l’adresse, et memory_limit=-1 ne bloque que le chemin connu.
• Masquer les erreurs n’empêche pas l’accès à l’état périmé.
• Le WAF reste un palliatif : Cloudflare qualifie ses règles de « stopgap only », et des payloads modifiés pour les contourner ont été observés. Aucun test indépendant de leur efficacité n’a été publié.

Or les exploits avancés connus, ceux de VulnCheck et de Karimi, visent justement CVE-2026-109618. Une équipe qui s’est arrêtée à l’upload progress reste exposée au chemin le plus travaillé par les attaquants.

CVE-2026-115560 est un avis informatif publié par php.net le 23/10, intitulé « Session upload progress ». Il décrit un vecteur RCE jugé « improbable », sur une configuration inhabituelle : l’application fixe session.serialize_handler à php_binary ou php_serialize, puis le repasse à php par ini_set() avant session_start(), avec l’upload progress actif. La mitigation est la même que pour CVE-2026-109619 : si vous l’aviez déjà appliquée, aucune autre action n’est nécessaire selon l’avis. Red Hat, seul éditeur à la mentionner (bulletin RHSB-2026-013), en est encore à évaluer l’impact sur ses produits.

Au 26/10, rien d’autre n’est public. Pas de GHSA dans les avis de php-src, pas d’enregistrement chez CVE.org, pas de fiche NVD, pas de page chez Debian, Ubuntu, SUSE ou Red Hat, et aucun commit de correctif visible sur les branches 8.2 à 8.5. Donc ni CVSS, ni versions affectées, ni crédit. Les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ne corrigent pas ce défaut : php.net publiera l’avis complet « with the next release ». Cette release n’a pas de date. Les branches sont passées en 8.5.13-dev, 8.4.28-dev, 8.3.37-dev et 8.2.36-dev le 21/10, mais aucun tag ni RC n’existe. La cadence récente (8.5.11 le 24/09, 8.5.12 le 21/10) laisse attendre la mi-novembre, sans annonce officielle. Rien ne garantit non plus qu’une 8.2.36 sortira : la branche 8.2 ne reçoit plus que des correctifs de sécurité, publiés au besoin. Seul PHP 8.6 a un calendrier : RC5 le 5/11, version finale le 19/11. Aucune exploitation de CVE-2026-115560 n’a été relevée. La conséquence pratique est simple : le réglage que beaucoup ont posé « par prudence » devient le seul rempart contre ce vecteur. Il doit être chargé avant le parsing de la requête, donc dans php.ini ou le pool FPM, jamais par ini_set() ni .user.ini.

; conf.d/zz-hardening.ini (pas ini_set(), pas .user.ini)
; À garder jusqu’à la prochaine release de bugfix : couvre CVE-2026-115560
; et le chemin d’upload de CVE-2026-109619. Ne remplace PAS le patch.
session.upload_progress.enabled = 0

; PHP 8.5 uniquement : chemin des backtraces d’erreur fatale (CVE-2026-109619)
fatal_error_backtraces = 0

; Variante pool PHP-FPM, non surchargeable par l’application :
; php_admin_value[session.upload_progress.enabled] = 0

Les images Docker et les distributions sont-elles corrigées ?

Au 26/10, oui pour la plupart des canaux, mais pas au même rythme. Entre le 21 et le 25/10, votre exposition dépendait du canal choisi plus que de votre réactivité. Pour les images officielles php, les dates ci-dessous viennent de l’API Docker Hub (champ last_updated, qui peut refléter un rebuild plutôt qu’une première publication) : lisez-les comme « disponible au plus tard ».

• Images Debian : 8.4.27-bookworm dès le 21/10 au soir, variantes 8.5.12 trixie et 8.4.27-apache le 23/10, 8.2.35-apache le 24/10.
• Images Alpine : 8.5.12-alpine et 8.4.27 Alpine le 25/10 seulement, soit quatre jours après le correctif amont.
• FrankenPHP 1.13.2 (21/10) : release de sécurité qui embarque PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
• Debian : trixie corrigé en php8.4 8.4.27-1~deb13u1 (DSA-6574-1), bookworm en php8.2 8.2.35-1~deb12u1 (DLA-4848-1).
• Ubuntu : USN-8948-1 et -2 le 21/10, avec des backports qui ne changent pas le numéro amont (24.04 reste en 8.3.6).
• Remi : paquets publiés le 22/10 pour Fedora 43 et plus, EL 8 et plus.
• Alpine secdb v3.23 : php83 8.3.36-r0, php84 8.4.27-r0, php85 8.5.12-r0. Aucune entrée php82 trouvée.
• Red Hat : RHSA publiés le 21/10 pour RHEL 10.2 (RHSA-2026:87070 en php 8.3.36, RHSA-2026:87071 en php8.4 8.4.27), RHEL 9 (modules php:8.2 et php:8.3, php 8.0) et RHEL 8 (modules php:8.2 et php:7.4), puis le 23/10 pour les versions EUS, E4S, AUS et TUS. Trou restant : le module php:8.4 de RHEL 9 est toujours « Affected », sans RHSA ni date.
• Rocky Linux : sept RLSA le 22/10, mêmes numéros que les RHSA. Amazon Linux : AL2023 corrigé pour php8.2 à php8.5, mais AL2 (php du dépôt principal) et AL2023 php8.1 en « No Fix Planned ». AlmaLinux : non vérifié.

Le piège concret de ce lundi est le cache d’images. Sur une machine de test, un php:8.4-fpm-alpine déjà présent localement tournait encore en PHP 8.4.22, construit le 16 juin : un docker run ne retélécharge pas un tag déjà en cache. Un FROM php:8.4-fpm-alpine reconstruit avec cache sur un runner CI persistant a exactement le même défaut. Forcez le pull, reconstruisez sans cache, et vérifiez la version du SAPI web : php -v décrit le CLI, pas le PHP qui sert le trafic. C’est le principe d’une image PHP multi-stage scannée par Trivy en CI : la version réelle se vérifie au build.

# 1) Image de base : forcer le pull, puis lire la version du SAPI FPM
docker pull php:8.4-fpm-alpine
docker run --rm php:8.4-fpm-alpine php-fpm -v | head -1
# attendu : PHP 8.4.27 ou plus (8.4.22 = image en cache non corrigée)

# 2) Image applicative : reconstruire sans cache, en retirant les bases
docker build --pull --no-cache -t monapp/php:patched .

# 3) Conteneur qui sert le trafic : version et réglage vus par le SAPI FPM
docker compose exec php php-fpm -v | head -1
docker compose exec php sh -c 'php-fpm -i | grep session.upload_progress.enabled'
# attendu : Off (php-fpm -i lit l’ini du SAPI FPM, pas les php_admin_value du pool)

Les branches anciennes restent l’angle mort : pour PHP 7.4, 8.0 et 8.1, php.net n’a publié que des backports sources, sans release officielle. Et PHP 8.2, corrigé en 8.2.35, sort du support sécurité le 31/12/2026. Si vous y êtes encore, la vraie correction consiste à migrer avant la fin de support de PHP 8.2.

Symfony est-il concerné cette semaine ?

Non, côté framework. Symfony n’a publié aucun advisory ni release de patch du 19 au 26/10. Le dernier lot date du 14-15/10 : CVE-2026-108082 (ReDoS dans HeaderUtils::split() via un en-tête Cache-Control), CVE-2026-109413 (récursion non bornée du lexer YAML inline) et CVE-2026-109449 (imbrication non bornée du parseur ExpressionLanguage), trois dénis de service corrigés en 6.4.48, 7.4.21 et 8.1.9 (14/10) puis 5.4.54 (15/10). Si vous n’avez pas encore pris ces versions, faites-le dans la même fenêtre de maintenance que le patch PHP.

Pour PHP2Shell, il n’y a rien à monter dans composer.json : la faille est dans le runtime. Une application Symfony n’envoie normalement jamais de champ PHP_SESSION_UPLOAD_PROGRESS, ce qui permet de couper l’upload progress durablement sans régression. La priorité reste la version de PHP, l’image et la base de distribution. Une fois le runtime à jour, la semaine est un bon prétexte pour repasser la checklist OWASP Symfony en 30 minutes.

Laravel, Livewire, Drupal : que faut-il patcher ?

Laravel. CVE-2026-114509 (GHSA-f9x3-7vq9-cph6, CVSS v4 9.2) permet de contourner l’authentification du TokenGuard en envoyant des identifiants API non-string, sur une base MySQL ou MariaDB : l’attaquant s’authentifie comme un utilisateur existant. Versions affectées : avant 12.68.0 et de 13.0.0 à 13.28.x. Corrigé en 12.68.0 et 13.29.0 (avis GitHub du 19/10). Dans la même série, CVE-2026-114508 (CVSS 6,5) permet, via l’inclusion de relations sur des endpoints en lecture, de déclencher une opération destructive sans droit d’écriture ; elle est corrigée en 12.68.0 et 13.27.0.

Livewire 4, de 4.3.0 à 4.4.7, laisse contourner l’attribut #[Authorize] en réordonnant les clés de paramètres. Correctif en 4.4.8, sans CVE attribuée ; Livewire 3 n’est pas affecté. Drupal a publié le 21/10 un lot de modules contrib : Ffmpeg Image Toolkit (SA-CONTRIB-2026-220, très critique, RCE), Custom Formatters (SA-CONTRIB-2026-225, critique, RCE) et Monster Menus (SA-CONTRIB-2026-253, critique, injection d’objet PHP). Ne confondez pas PHP2Shell avec « wp2shell », une chaîne d’exploitation du cœur de WordPress publiée mi-juillet.

Le contrôle se fait sur le composer.lock, sans installer le projet. composer audit s’appuie sur la base d’advisories de Packagist, qui peut avoir un léger décalage avec l’index GitHub : complétez par une lecture directe des versions verrouillées.

# Audit basé sur le lock, sans vendor/ ni PHP local
docker run --rm -v "$PWD":/app -w /app composer:2 \
  composer audit --locked --no-dev --format=plain

# Versions verrouillées des paquets concernés
docker run --rm -v "$PWD":/app -w /app composer:2 \
  composer show --locked | grep -E '^(laravel/framework|livewire/livewire) '
# Seuils : laravel/framework >= 12.68.0 (12.x) ou >= 13.29.0 (13.x)
#         livewire/livewire >= 4.4.8 en 4.x

Composer et Packagist n’ont rien publié de notable sur la période : le dernier billet Packagist date du 29/09, et les derniers incidents de paquets malveillants recensés remontent au printemps. Cette absence n’est pas une preuve, seulement l’état des sources publiques consultées.

Comment chercher une compromission depuis le 17 octobre ?

La première tentative documentée date du 17/10 : la rétro-chasse doit commencer avant la divulgation, pas le 21. La signature publiée par Amazon Threat Intelligence est un POST multipart contenant le champ PHP_SESSION_UPLOAD_PROGRESS. Limite essentielle : ce champ est dans le corps de la requête, donc invisible dans un access log nginx ou Apache standard. Il faut des logs de corps (audit ModSecurity, WAF, Cloudflare) ou, à défaut, une heuristique sur les POST multipart envoyés vers des routes qui n’attendent aucun upload. Priorité aux machines en mod_php, où le RCE complet est validé.

# 1) Logs de corps (audit ModSecurity, WAF) : signature publiée par Amazon
zgrep -l 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/modsec_audit/*/* /var/log/waf/*.log* 2>/dev/null

# 2) Heuristique nginx : journaliser le Content-Type, puis compter les POST multipart
#    log_format mp '$remote_addr [$time_local] "$request" $status $content_type';
zgrep -hE '"POST [^ ]+ HTTP/[0-9.]+" [0-9]+ multipart/form-data' /var/log/nginx/access.log* \
  | awk '{print $5}' | sort | uniq -c | sort -rn | head -20
# Comparez avec vos routes d’upload légitimes : tout le reste est à examiner.

Les adresses IP publiées par Amazon relèvent d’infrastructures partagées : Amazon recommande de les investiguer, pas de les bloquer. Les indicateurs de compromission liés à Potassium qui circulent ne sont recoupés par aucune seconde source : traitez-les comme des pistes.

Où en êtes-vous ce lundi ? La checklist

• Version du SAPI web en production : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 minimum, ou paquet de distribution corrigé. Vérifiez avec php-fpm -v dans le conteneur qui sert le trafic.
• Images reconstruites avec --pull --no-cache, redéployées, tous les workers redémarrés. Un conteneur en cours d’exécution ne se met jamais à jour.
• Base Alpine : si votre build a tourné entre le 21 et le 25/10, vérifiez qu’il n’a pas réutilisé un tag ou un cache antérieur.
• RHEL et Amazon Linux : sur RHEL 9 avec le module php:8.4, aucun correctif n’existe encore ; même chose sur AL2 et AL2023 php8.1, où aucun n’est prévu. Changez de flux de module ou de paquet, ou isolez l’application.
• Mitigation : session.upload_progress.enabled=0 dans php.ini ou le pool FPM, maintenu jusqu’à la release qui corrigera CVE-2026-115560.
• Symfony : 6.4.48, 7.4.21, 8.1.9 ou 5.4.54 si ce n’est pas déjà fait, en suivant la checklist de patch de sécurité PHP pour Symfony en production.
• Laravel : 12.68.0 ou 13.29.0 ; Livewire 4 : 4.4.8.
• Rétro-chasse depuis le 17/10 sur les logs de corps et les POST multipart.
• À surveiller : entrée au catalogue CISA KEV, tags php-8.5.13 et suivants dans php-src, avis complet de CVE-2026-115560, RHSA du module php:8.4 de RHEL 9.

Le changement de la semaine est moins technique que temporel. La question « exploitable ou pas » est tranchée : l’exécution de commandes est reproduite, même si aucune victime réelle n’est encore documentée. La fenêtre qui compte est celle de votre déploiement, pas celle de la release amont. Un pipeline bâti sur php:8.x-fpm-alpine a pu rester exposé jusqu’au 25/10, et RHEL 9 avec le module php:8.4 l’est encore, alors même que les premières tentatives datent du 17. Si vous êtes encore en PHP 8.2, la bonne question n’est plus « patcher ou pas », mais « migrer avant le 31/12 ».

Les chiffres de Qualys disent la même chose à l’échelle du parc : sur une branche supportée, ce correctif se pose en une heure ; sur une version abandonnée, il devient un chantier de migration à mener sous la pression d’un exploit public. Si votre équipe n’a pas le temps de suivre les versions de PHP, du framework et des dépendances, la maintenance des versions de Bear Upgrade s’en charge, avec des correctifs livrés en Merge Requests testées.

Écrit par

Flavien Métivier

Expert PHP/Symfony indépendant depuis 2014, ancien CTO de Kartable et d'Extrabat. Plus de 80 projets menés, de l'audit à la migration.

Mon parcours