Le 21 octobre, le projet PHP a publié un avis de sécurité intitulé « Critical remote code execution vulnerabilities, update now » : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux failles critiques, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) et CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp). Toutes deux sont classées Critical, avec un score CVSS v4 de 9,2 dans leurs avis GitHub, et toutes deux peuvent permettre une exécution de code à distance sans authentification. Le projet invite fortement tous les utilisateurs de PHP à mettre à jour immédiatement. Le duo est aussi surnommé php2shell.

Qui est concerné

  • L'avis vise toutes les installations PHP qui traitent des requêtes web, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP estime que le risque est le plus élevé avec mod_php, pour lequel il existe un exploit démontré : une requête non authentifiée déclenche l'attaque avant même l'exécution du moindre code de l'application.
  • CVE-2026-109618 : la gestion d'un manque de mémoire (OOM) peut interrompre PHP alors que des données internes de la requête ne sont que partiellement initialisées, et le nettoyage de la requête peut ensuite traiter ces données invalides comme valides.
  • CVE-2026-109619 : un état interne propre à une requête peut subsister après la libération de la mémoire qui le porte, et une requête ultérieure traitée par le même worker peut utiliser cet état périmé avant que l'initialisation normale ne le réinitialise.
  • Le problème se situe dans le moteur d'exécution de PHP lui-même, pas dans WordPress ni dans une extension. WordPress a indiqué le même jour qu'aucune mise à jour de WordPress n'est nécessaire ni prévue pour ces failles : c'est PHP qu'il faut mettre à jour. Dans WordPress, la version de PHP s'affiche sous Outils → Santé du site → Informations → Serveur.

Comment mettre à jour

  • Vérifiez la version avec php -v. Si vous compilez depuis les sources officielles, passez à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
  • Si vous utilisez les paquets de votre distribution : Ubuntu a publié USN-8948-1 le 21 octobre, avec php8.1 8.1.2-1ubuntu2.28 pour 22.04 et php8.3 8.3.6-0ubuntu0.24.04.13 pour 24.04 ; Debian 13 propose php8.4 8.4.27-1~deb13u1 (DSA-6574-1) et Debian 12 php8.2 8.2.35-1~deb12u1 (DLA-4848-1). Après sudo apt update && sudo apt upgrade, redémarrez PHP-FPM ou Apache (par exemple sudo systemctl restart php8.3-fpm) : les workers déjà lancés ne chargent pas le nouveau code d'eux-mêmes.
  • PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP ; si votre distribution rétroporte les correctifs (comme le 8.1 d'Ubuntu 22.04 ci-dessus), il suffit de mettre à jour les paquets du système. Vu la gravité, l'équipe de sécurité de PHP a aussi fourni des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1, destinés à ceux qui compilent eux-mêmes.
  • Un PHP installé par un panneau comme aaPanel, ou un PHP dans une image Docker, ne provient pas de l'apt du système : vérifiez dans le panneau si une nouvelle version est disponible, ou récupérez l'image mise à jour et recréez le conteneur. Voir gérer un VPS avec aaPanel et Docker sur un VPS.

Impossible de mettre à jour tout de suite : les mesures provisoires officielles

L'équipe PHP insiste : seule une mise à jour constitue une solution complète ; les mesures ci-dessous réduisent l'exposition à certains vecteurs d'attaque, mais ne rendent pas une installation sûre :

  • Pour CVE-2026-109618 : définissez memory_limit=-1, de préférence d'une manière que les applications ne peuvent pas modifier (par exemple php_admin_value dans le pool FPM ou la configuration d'Apache), et fixez un post_max_size bas — 8M pour les applications qui n'ont pas besoin d'envoi de fichiers, 32M sinon — en gardant upload_max_filesize en dessous.
  • Pour CVE-2026-109619 : définissez session.upload_progress.enabled=0 et redémarrez tous les workers, dans php.ini, un pool FPM ou la configuration du serveur — pas via ini_set() ni les fichiers .user.ini de FPM. Sous PHP 8.5, définissez aussi fatal_error_backtraces=0.
  • Le 23 octobre, l'équipe PHP a ajouté un avis d'information : même en 8.5.12, gardez session.upload_progress.enabled=0 jusqu'à la prochaine version régulière, car un problème apparenté au déclenchement inhabituel, CVE-2026-115560, ne sera corrigé qu'à ce moment-là.

Un CDN en amont ne dispense pas de corriger

Cloudflare a indiqué le 21 octobre que les failles avaient fuité avant la publication officielle et qu'il avait observé du trafic d'attaque visant ses clients ; depuis le 21 octobre à 03:02 UTC, les sites qui utilisent son WAF gratuit ou payant sont protégés par défaut. Cloudflare précise lui-même qu'il faut tout de même corriger PHP. Et un WAF ne filtre que le trafic qui passe par lui : si l'adresse IP de votre serveur d'origine est joignable directement, un attaquant peut contourner le CDN. Une fois la mise à jour faite, si le site était exposé à Internet auparavant, suivez enquêter sur un VPS compromis pour repérer des processus inattendus et des fichiers inconnus. Les propriétaires de sites WordPress doivent aussi vérifier que la faille du cœur de WordPress de septembre est corrigée, et les utilisateurs de nginx consulter les cinq correctifs de nginx publiés le 14 octobre.