Failles critiques PHP : CVE-2026-109618 et 109619, mitigations et correctifs

Dernière mise à jour : 21 octobre 2026, 11 h 40 (heure de Paris). Alerte initiale. PHP confirme deux vulnérabilités critiques notées 9,2 (CVSS v4.0), mais n'a pas encore publié les versions corrigées ni le détail technique, annoncés pour le 21 octobre à 14:00 UTC sur la page des annonces de php.net. Les nouvelles informations seront ajoutées ici, datées, dès leur publication.

9,2 sur 10. C'est le score CVSS v4.0 annoncé pour chacune des deux vulnérabilités critiques qui touchent PHP. Le correctif est annoncé pour le 21 octobre 2026 à 14:00 UTC, et Sansec s'attend à des attaques massives dans les 15 minutes qui suivront sa publication. Les détails techniques et les versions concernées, eux, ne seront publiés qu'avec le correctif.

Si vous exploitez WordPress, Magento, Symfony, Laravel ou PrestaShop, votre urgence n'est pas de décortiquer l'exploit. Elle consiste à savoir où PHP tourne, quelles routes acceptent des fichiers et comment redémarrer proprement PHP-FPM, le gestionnaire qui maintient les processus PHP actifs. Le CERT-EU recommande déjà de recenser les applications concernées et de préparer la mise à jour.

Cet article distingue les faits confirmés par PHP et les autorités de cybersécurité des éléments rapportés par des analyses secondaires. Il propose deux mesures temporaires, réversibles et à tester. Aucune n'a été validée contre l'exploit réel. Cette page est datée du 21 octobre 2026 : revérifiez l'avis PHP final et les paquets disponibles avant toute décision.

Pourquoi cette alerte PHP mérite une réaction avant même le patch ?

Ce que PHP confirme, et ce que PHP ne dit pas encore

Dans son annonce officielle du 20 octobre 2026, PHP annonce deux vulnérabilités critiques notées CVSS v4.0 9,2, sans les nommer. Le CVSS est une échelle qui aide à estimer la gravité technique d'une faille. PHP annonce une publication de sécurité le lendemain à 14:00 UTC et précise que les versions touchées et corrigées seront publiées avec elle. Les identifiants CVE-2026-109618 et CVE-2026-109619 sont cités par le CERT-EU et la presse spécialisée.

Le CERT-EU précise dans son avis 2026-018 qu'aucun détail technique n'a encore été rendu public et ne donne aucune version corrigée. Il indique que toutes les versions depuis PHP 5 " pourraient " être touchées, en s'appuyant sur un message publié sur les réseaux sociaux. Le lien avec session.upload_progress et le use-after-free dans php_session_rfc1867_callback sont rapportés par des sources secondaires, dont un billet d'analyste qui souligne lui-même que PHP ne l'a pas confirmé. Quant à l'exécution de code à distance sans authentification, le CERT-EU la présente comme un potentiel déduit du score. Ces éléments ne doivent pas être présentés comme des faits établis par PHP tant que l'avis final n'est pas publié.

Même prudence sur les attaques actives. watchTowr écrit qu'au 21 octobre 2026, aucune exploitation dans la nature n'a été signalée, et Huntress dit n'en avoir observé aucune, selon SecurityWeek. Côté Cloudflare, les messages de son CTO sur X sont rapportés de façon contradictoire : premières attaques en cours selon un billet d'analyste, simples protections contre les charges d'exploit connues selon un message de remplacement relayé sur Hacker News, le message initial ayant été supprimé. L'urgence vient donc du score, du délai court et de l'incertitude, pas d'une campagne établie.

Le vrai risque opérationnel : le délai de réaction

Avant de toucher à la configuration, établissez la liste des serveurs qui exécutent PHP. Notez la version, le mode d'exécution, le pool FPM utilisé, l'application hébergée et l'exposition Internet. Un serveur oublié peut conserver une configuration différente du reste du parc.

Préparez aussi la fenêtre de redémarrage. PHP-FPM charge le code et ses extensions dans des processus longs. Installer un paquet corrigé sans redémarrer ces processus peut laisser l'ancien code en mémoire. Documentez le retour arrière, les contrôles fonctionnels et la personne qui valide la remise en service.

Cette préparation limite deux risques à la fois : laisser une application exposée et provoquer une indisponibilité en appliquant un changement trop large.

Le signal pointe vers session.upload_progress : faut-il couper la fonction ?

Une piste technique, pas encore une certitude

session.upload_progress est une fonction PHP qui permet de suivre l'avancement d'un téléversement. Elle s'appuie sur une requête multipart/form-data, le format utilisé par de nombreux formulaires qui envoient un fichier, et sur le champ PHP_SESSION_UPLOAD_PROGRESS. D'après le manuel PHP, l'option est active par défaut. Selon PentestIT, le traitement se déclenche sur tout point d'entrée PHP qui reçoit un téléversement multipart, même sans session_start(). Le lien avec les CVE, lui, reste à confirmer par PHP.

Des analyses secondaires relient les deux CVE à ce traitement. Elles évoquent un use-after-free, c'est-à-dire une zone mémoire réutilisée après sa libération, avec un risque d'exécution de code à distance. Cette description reste une attribution rapportée. PHP et le CERT-EU n'ont confirmé à ce stade ni le mécanisme précis ni le périmètre des versions.

La distinction compte. Désactiver la fonction peut réduire une surface d'exposition si cette piste est correcte, mais cela ne prouve pas que les deux vulnérabilités sont neutralisées. Des échanges publics entre développeurs évoquent même une seconde voie liée au traitement multipart lui-même, qu'aucun réglage du php.ini ne fermerait. Rien n'est confirmé, mais c'est la raison d'être de la mesure n°2. Les mesures ci-dessous sont des atténuations, pas un correctif et pas une validation contre l'exploit réel.

Le compromis fonctionnel à vérifier

La désactivation de la progression native peut supprimer l'affichage de l'avancement sans empêcher le téléversement lui-même. Le résultat dépend de l'application et de la manière dont elle suit ses imports. Sansec indique par exemple que Magento, Shopware et WooCommerce n'utilisent pas les barres de progression natives de PHP. Vérifiez les formulaires, les médias, les pièces jointes, les imports de données et les intégrations externes.

Faites ce contrôle sur un environnement représentatif, puis surveillez les erreurs après déploiement. Si une application dépend précisément de cette fonction, documentez l'impact avant de généraliser la mesure. La sécurité d'urgence ne doit pas se transformer en panne silencieuse.

Mesure n°1 : désactiver la progression d'upload, le réglage temporaire à vérifier

Où placer le réglage

La mesure rapportée consiste à désactiver l'option dans la configuration PHP globale ou dans le pool PHP-FPM concerné. Dans le fichier de configuration adapté à votre distribution, le réglage est :

session.upload_progress.enabled = 0

Selon l'environnement, vous pouvez le définir dans la configuration d'un pool FPM :

php_admin_flag[session.upload_progress.enabled] = off

Sur un hébergement mutualisé sans accès au php.ini, PentestIT rapporte que la même ligne session.upload_progress.enabled = Off fonctionne dans un fichier .user.ini.

N'essayez pas de régler ce paramètre depuis le code applicatif. Le manuel PHP le classe en INI_PERDIR : ini_set() ne peut pas le modifier, et le traitement multipart intervient de toute façon avant l'exécution de votre code. Vérifiez le périmètre exact du fichier chargé par FPM et du pool réellement utilisé par le site.

Redémarrer, puis vérifier

Après modification, redémarrez PHP-FPM avec le mécanisme prévu par votre distribution, puis rechargez le serveur web si votre architecture le demande. La commande exacte dépend de l'OS et du nom du service : utilisez votre procédure d'exploitation documentée.

Contrôlez ensuite la valeur effective dans le bon environnement. Si vous utilisez temporairement une page de diagnostic, supprimez-la immédiatement après vérification. Testez les téléversements autorisés, les imports et les pièces jointes. Surveillez les journaux PHP-FPM et du serveur web pendant la période qui suit.

Cette mesure peut réduire l'exposition rapportée autour de session.upload_progress. Elle n'a pas été validée contre l'exploit réel et ne couvre pas nécessairement une autre voie d'attaque. Gardez le plan de mise à jour actif.

Mesure n°2 : filtrer multipart, efficace en apparence et risqué si le périmètre dérape

Bloquer seulement là où aucun upload n'est attendu

Le principe est simple : refuser les requêtes dont le type de contenu commence par multipart/form-data sur les routes qui n'acceptent pas de fichier. Les routes d'upload indispensables doivent rester explicitement autorisées.

Voici des fragments à intégrer à votre configuration existante, pas des blocs autonomes : ils ne remplacent ni vos blocs location, ni vos règles de réécriture, ni le routage de Symfony ou Laravel. Ils ciblent /connexion et /panier. Ils renvoient 415, un code HTTP qui signifie que le format reçu n'est pas accepté. Remplacez les routes par celles de votre application, puis testez en préproduction.

Nginx, en deux fragments : les map vont dans le bloc http, le test dans le bloc server existant, sans toucher aux location :

# Bloc http {}
map $http_content_type $est_multipart {
    default                  0;
    "~*^multipart/form-data" 1;
}
map $uri $route_sans_upload {
    default                     0;
    "~^/(connexion|panier)(/|$)" 1;
}
map "$est_multipart$route_sans_upload" $bloquer_multipart {
    default 0;
    "11"    1;
}

# Bloc server {} existant, avant les location
if ($bloquer_multipart) {
    return 415;
}

Validez avec nginx -t avant de recharger.

Apache avec mod_rewrite, à placer avant les règles de réécriture existantes (celles du .htaccess de Symfony ou Laravel, par exemple) :

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/(connexion|panier)(/|$) [NC]
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteRule ^ - [R=415,L]

Caddy, à ajouter dans le bloc du site existant :

@multipartSansUpload {
    path /connexion /connexion/* /panier /panier/*
    header_regexp Content-Type (?i)^multipart/form-data
}

respond @multipartSansUpload 415

Ces blocs sont des exemples de filtrage, pas des garanties universelles. Les règles peuvent varier selon les préfixes, les réécritures, le proxy en amont et le serveur exposé. Repérez d'abord la couche qui reçoit réellement la requête : CDN, proxy, serveur web.

Le test qui évite la panne secondaire

Avant d'élargir le filtrage, testez la connexion, le panier, les formulaires, les imports, les médias et les API. Vérifiez aussi les appels externes qui utilisent un formulaire multipart sans que le nom de la route ne le laisse deviner.

Documentez les routes bloquées, les routes autorisées, la réponse attendue et le plan de retour arrière. Surveillez les faux positifs dans les journaux. La bonne règle est ciblée : bloquer ce qui n'a pas besoin de téléverser, préserver ce qui en dépend.

Deux fausses bonnes idées à écarter avant de redémarrer

Désactiver le handler PHP : le remède qui expose le code source

Retirer le handler PHP du serveur web ne constitue pas une atténuation propre. Selon la configuration, les fichiers PHP peuvent être servis comme du texte ou proposés au téléchargement : Apache sert alors les fichiers .php en clair, mots de passe compris. Le code source, les identifiants de connexion et la logique métier risquent d'être exposés. Pour couper un site, arrêtez plutôt le serveur web ou renvoyez une page 503.

Conservez un serveur correctement configuré. Réduisez la surface d'exposition avec les mesures ciblées, contrôlez les accès et préparez le correctif éditeur. Une décision d'urgence ne doit pas créer une fuite plus grave que la faille initiale.

Confondre l'atténuation et la correction

La remédiation de référence reste l'installation de la version PHP corrigée dès sa publication, puis le redémarrage de PHP-FPM. Vérifiez l'avis PHP final sur la page des annonces de php.net, les versions corrigées et les paquets proposés par votre distribution. PHP n'a pas encore publié les numéros de versions corrigées. Mais sa politique de support est claire : seules les branches 8.2, 8.3, 8.4 et 8.5 reçoivent encore des correctifs de sécurité. PHP 8.1 et les versions antérieures sont en fin de vie et ne devraient pas recevoir de correctif officiel.

Les branches hors support sont donc un problème distinct. Si votre application tourne sur l'une d'elles, gardez les mesures temporaires, préparez une migration et évaluez l'isolement. Le CERT-EU recommande d'isoler du réseau public les applications exposées sur Internet quand le correctif ne peut pas être appliqué. Si le risque ne peut pas être maîtrisé, la mise hors ligne peut devenir la seule option responsable.

La bonne décision aujourd'hui : réduire l'exposition, préparer le patch, vérifier deux fois

Recensez les applications PHP, leurs versions, leurs pools FPM et leurs routes multipart. Désactivez session.upload_progress si la mesure est compatible avec vos parcours. Ajoutez un filtrage ciblé sur les routes qui n'attendent aucun fichier. Testez, surveillez, documentez le retour arrière.

Puis revérifiez l'avis PHP final. Les versions corrigées, le périmètre des branches et le mécanisme technique doivent venir de la source éditeur dès qu'ils sont publiés. Une mesure temporaire achète du temps, elle ne remplace pas le correctif.

Pour préparer les évolutions de votre socle, consultez aussi notre article sur PHP 8.5, en gardant la vérification de l'avis de sécurité comme priorité.

La faille est peut-être dans le code. La première décision, elle, est dans votre inventaire.

Checklist express avant la publication du correctif

• Lister tous les serveurs, applications, versions PHP et pools FPM.
• Identifier les routes qui acceptent réellement multipart/form-data.
• Choisir une mesure temporaire documentée et noter son périmètre.
• Redémarrer PHP-FPM après modification.
• Tester les téléversements, imports, formulaires et API concernés.
• Surveiller les journaux et préparer le retour arrière.
• Vérifier l'avis PHP final, les paquets corrigés et les branches supportées.
• Garder les mesures temporaires jusqu'à l'installation du correctif : elles n'ont pas été validées contre l'exploit réel.