Alerte de sécurité : failles PHP critiques CVE-2026-109618 et CVE-2026-109619

Le 21 octobre 2026, le projet PHP a publié une version d'urgence pour deux vulnérabilités critiques du cœur de PHP : CVE-2026-109618 et CVE-2026-109619 (CVSS v4.0 de 9,2 chacune). Les deux permettent une exécution de code à distance sans authentification : un attaquant qui peut envoyer une requête HTTP à n'importe quel script PHP peut exécuter du code avec les droits du processus PHP. L'avis officiel de PHP s'intitule « update now » (mettez à jour maintenant). Les détails ont fuité avant la publication coordonnée, et les premières attaques sont déjà signalées. Les hébergeurs déploient en ce moment le correctif sur leurs plateformes gérées. Hetzner, par exemple, met à jour ses offres d'hébergement géré. Sur votre propre VPS, la mise à jour vous revient.

Qui est concerné

Toute installation PHP qui répond à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP considère mod_php comme le plus exposé. Les failles se trouvent dans l'analyse de la requête, avant l'exécution de votre application : écrans de connexion, extensions de sécurité et middlewares ne vous protègent pas.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) : la gestion d'un manque de mémoire peut interrompre PHP alors que les données de la requête ne sont qu'en partie initialisées, et le nettoyage traite ensuite des données invalides comme valides.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) : un état de requête peut survivre après la libération de sa mémoire, et une requête suivante sur le même worker peut l'utiliser. Le suivi de progression des envois et les backtraces d'erreurs fatales y donnent accès.

Les serveurs ShadowPanel sont concernés via PHP, pas via ShadowPanel lui-même. L'API et le daemon du panneau sont écrits en Node.js. Mais chaque site PHP hébergé tourne sur le PHP-FPM du serveur, tout comme phpMyAdmin et le webmail sur le port d'administration. Le correctif arrive par les paquets PHP de votre distribution. Aucune mise à jour de ShadowPanel n'est nécessaire pour le recevoir.

Les versions corrigées

Notez que PHP 8.2 arrive lui-même en fin de vie le 31 décembre 2026.

Étape 1 : vérifier ce que tourne votre serveur

ShadowPanel installe PHP depuis le dépôt ondrej/php et peut faire tourner plusieurs versions côte à côte. Vérifiez chacune :

for v in /etc/php/*/; do v=$(basename "$v"); echo "$v: $(php$v -v 2>/dev/null | head -1)"; done

Toute version inférieure à celles du tableau est vulnérable.

Étape 2 : installer les paquets corrigés

apt update
apt list --upgradable 2>/dev/null | grep '^php'
apt upgrade
systemctl restart 'php*-fpm'

Utilisez restart et non reload, pour qu'aucun worker ne garde l'ancien binaire en mémoire. Relancez ensuite la vérification de l'étape 1 et confirmez les nouveaux numéros de version.

Les paquets des distributions peuvent arriver quelques heures après la publication officielle. Si apt list --upgradable n'affiche pas encore la version corrigée, appliquez l'étape 3 maintenant et refaites l'étape 2 plus tard dans la journée.

Étape 3 : réduire le risque en attendant les paquets

Les développeurs de PHP sont clairs : seule la mise à jour corrige ces failles. Les mesures ci-dessous réduisent le risque. Elles ne le suppriment pas.

Désactivez la progression des envois de session. Cela ferme le chemin d'exploitation confirmé de CVE-2026-109619 et ne coûte rien sur la plupart des sites :

for d in /etc/php/*/fpm/conf.d; do
  echo 'session.upload_progress.enabled = 0' > "$d/99-upload-progress-off.ini"
done
systemctl restart 'php*-fpm'

Le fichier dans conf.d s'applique à tous les pools de cette version de PHP, y compris les pools par site créés par ShadowPanel. Vous pouvez le laisser en place après la mise à jour. En PHP 8.5, ajoutez aussi fatal_error_backtraces = 0 dans ce même fichier.

Limitez la taille des requêtes pour CVE-2026-109618. L'avis de PHP recommande memory_limit = -1 avec post_max_size = 8M et upload_max_filesize = 8M (32M si le site a besoin d'envois de fichiers). Supprimer la limite de mémoire n'est sûr que si autre chose arrête un worker incontrôlé, par exemple une limite MemoryMax= sur le service systemd de PHP-FPM. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA pour cela.

Faites taire votre configuration PHP. Les réglages obsolètes ou invalides qui affichent un avertissement à chaque requête, ainsi que les erreurs fatales ou délais dépassés qu'un attaquant peut provoquer, facilitent l'attaque. Les masquer avec error_reporting, display_errors ou @ ne sert à rien.

Bloquez les requêtes multipart sur les sites qui n'ont pas besoin d'envoi de fichiers. Un site vitrine ou un blog sans formulaire public peut refuser multipart/form-data dans nginx, avant que PHP ne voie la requête. Ne le faites pas sur une boutique, un forum ou une administration WordPress qui envoie des médias : cela bloque tous les envois de fichiers.

Une règle de pare-feu applicatif (CDN ou ModSecurity) peut arrêter les requêtes d'exploitation connues, mais de nouvelles variantes apparaissent vite. Considérez-la comme une solution provisoire. Les réglages modifiés via ini_set() ou .user.ini ne vous protègent pas : placez-les dans la configuration de PHP-FPM et redémarrez.

Étape 4 : sortir les sites des versions PHP en fin de vie

PHP 7.4, 8.0 et 8.1 ne recevront pas de nouvelle version. Le projet PHP a publié des rétroportages minimaux du code source, mais c'est au mainteneur de votre dépôt de paquets de décider s'il les compile. Si un site tourne encore sur l'une d'elles, c'est le moment de le migrer, de préférence vers PHP 8.3 ou plus récent, car le support de 8.2 s'arrête cette année. Dans ShadowPanel, la version de PHP se règle site par site : vous pouvez migrer un site à la fois sans toucher aux autres. Testez d'abord le site sur la nouvelle version, idéalement sur une copie de préproduction. Pour comprendre le fonctionnement des versions par site, lisez plusieurs versions de PHP par site.

Étape 5 : rechercher des signes de compromission

Les failles étaient publiques avant le correctif. Si vos sites étaient accessibles entre-temps, vérifiez :

• les fichiers PHP inconnus dans les dossiers d'envoi et de cache, et les fichiers récemment modifiés dans vos racines web ;
• les erreurs PHP-FPM dans /var/log/php/ et les requêtes POST inhabituelles dans les journaux d'accès nginx ;
• les nouveaux comptes administrateur, tâches cron ou clés SSH que vous n'avez pas créés.

Le scanner de malwares de ShadowPanel (offres Pro et Agency) analyse un site entier avec ClamAV.

En résumé

1. Vérifiez chaque version de PHP installée.
2. Installez les paquets corrigés et redémarrez PHP-FPM.
3. En attendant, désactivez session.upload_progress, limitez la taille des requêtes et restreignez les envois là où c'est possible.
4. Passez les sites encore en PHP 7.4, 8.0 ou 8.1 en 8.3 ou plus récent.
5. Cherchez des signes de compromission sur vos sites.

Pour les détails officiels, lisez l'avis de sécurité de PHP sur php.net. Si vous utilisez ShadowPanel et avez une question sur votre serveur, ouvrez un ticket de support depuis votre compte.