Faille PHP CVE-2026-109618 et 109619 : que faire en PME

Le 20 octobre 2026, l'équipe PHP a annoncé un correctif pour deux failles critiques, dont les détails ont fuité avant sa publication. Elles seraient suivies sous les identifiants CVE-2026-109618 et CVE-2026-109619, d'après watchTowr et SecurityWeek. Toute entreprise dont le site, le CMS (logiciel de gestion de site, comme WordPress) ou l'intranet tourne sous PHP est potentiellement concernée, la liste officielle des versions touchées n'étant pas encore confirmée. La marche à suivre : identifier vos serveurs PHP, installer la mise à jour dès sa disponibilité et, d'ici là, appliquer une mesure temporaire.

Faille PHP CVE-2026-109618 et CVE-2026-109619 : ce qui s'est passé

PHP est un langage de programmation utilisé pour construire des sites et des applications web, dont les CMS WordPress, Drupal ou PrestaShop (un CMS est un système de gestion de contenu). Le 20 octobre 2026, son équipe de sécurité a annoncé une mise à jour de sécurité pour le 21 octobre à 14 h 00 UTC, soit 16 h 00 à Paris. Les deux failles sont notées 9,2 sur 10 selon l'échelle CVSS v4.0, le barème standard de gravité.

D'après SecurityWeek, les détails ont fuité en ligne avant la divulgation coordonnée, sous le nom « PHP2Shell ». Ces failles pourraient permettre une exécution de code à distance, c'est-à-dire qu'un attaquant fasse exécuter ses propres commandes sur votre serveur. Le CERT-EU, l'équipe de réponse aux incidents des institutions européennes, estime d'après le score qu'une exploitation sans authentification est possible.

La société watchTowr a confirmé que les vulnérabilités sont réelles et dit avoir reproduit la première, sans publier de détails. L'équipe PHP s'est réservé le droit de publier plus tôt si des détails devenaient publics ou si une exploitation était observée.

Un site PHP accessible depuis internet peut être visé par n'importe qui, sans cible particulière : c'est ce qui rend une exploitation de masse possible.

Mon entreprise est-elle concernée ?

Au 21/10/2026, avant la publication prévue à 16 h 00 (heure de Paris), PHP n'avait pas publié la liste des versions touchées ni corrigées. Les versions à installer seront celles du bulletin de sécurité de php.net, pour les branches maintenues 8.2 à 8.5, ou celles des bulletins de votre distribution. Des rapports évoquent toutes les versions depuis PHP 5, mais watchTowr précise que ce périmètre n'est pas confirmé par l'éditeur. La prudence consiste donc à considérer tout serveur PHP en production comme à traiter.

Selon votre hébergement

• Hébergement mutualisé (vous louez un espace chez un hébergeur) : c'est l'hébergeur qui met PHP à jour. Votre rôle est de vérifier la version utilisée dans votre espace client et de lui demander son calendrier.
• Serveur dédié, VPS (serveur virtuel loué) ou serveur interne : la mise à jour vous revient, ou revient à votre prestataire.
• Site confié à une agence : demandez-lui par écrit qui applique le correctif et quand.

Les versions anciennes

Seules les branches PHP 8.2 à 8.5 sont encore maintenues par le projet ; un serveur en 8.1 ou plus ancien ne devrait pas recevoir de correctif officiel, sauf exception. Si votre site tourne sur une version ancienne, la mesure temporaire décrite plus bas et une migration deviennent prioritaires.

N'oubliez pas les outils internes : intranet, extranet client, outil de facturation développé en PHP. Un inventaire de votre surface d'attaque externe aide à retrouver les sites oubliés.

Que faire maintenant, dans l'ordre

1. Faire l'inventaire. Listez tous les serveurs et conteneurs (environnements logiciels isolés) qui exécutent PHP, y compris les instances oubliées (ancien site, préproduction, c'est-à-dire une copie du site servant aux tests).
2. Appliquer la mesure temporaire si la mise à jour n'est pas encore installée : désactiver une fonction de PHP appelée « Session Upload Progress », qui sert à afficher la progression d'un envoi de fichier. Conséquence visible : les barres de progression d'envoi de fichier qui en dépendent ne fonctionneront plus.
3. Installer le correctif dès sa publication. Si PHP provient des paquets de votre distribution Linux, suivez aussi les bulletins de sécurité de celle-ci.
4. Planifier la migration des serveurs en PHP 8.1 ou antérieur vers une branche maintenue.
5. Vérifier l'absence de signes de compromission (section suivante).

La mesure temporaire a ses limites. L'entreprise GMO Flatt Security, qui relie la faille à cette fonction, reconnaît ne pas pouvoir garantir son efficacité à 100 %, et l'équipe PHP n'a ni confirmé ni infirmé cette piste. Elle ne remplace pas le correctif.

Le délai compte : selon Sansec, cité par SecurityWeek, l'exploitation de masse commencera probablement dans les 15 minutes suivant la publication du correctif. Pour inscrire ce type d'urgence dans une routine, voir le guide du patch management, c'est-à-dire la gestion des mises à jour.

Comment savoir si votre site a déjà été compromis

Au moment de l'article de SecurityWeek, watchTowr et Huntress n'avaient observé aucune exploitation de ces failles. La situation après la publication du correctif n'est pas connue. Les sources consultées au 21/10/2026 ne donnent pas d'indicateur de compromission ; surveillez le bulletin de php.net et les alertes du CERT-FR.

Les vérifications de bon sens restent utiles, à confier à votre prestataire :

• des fichiers PHP récents et inconnus dans les dossiers du site ;
• des comptes administrateurs du CMS que personne n'a créés ;
• des processus ou connexions sortantes inhabituels lancés par le compte du serveur web ;
• des pages modifiées, des redirections vers d'autres sites.

Si un doute sérieux apparaît, l'objectif est de déterminer ce qui s'est passé avant d'effacer quoi que ce soit : faites appel à un prestataire en réponse à incident plutôt que de reconstruire le serveur dans l'urgence. Des sauvegardes saines et hors ligne permettront ensuite de repartir d'un état fiable.

Fausse alerte Freebox : ce que les chiffres d'exposition ne disent pas

Un recensement d'Infrawatch a d'abord compté les Freebox parmi les serveurs PHP exposés. Numerama a rectifié, d'après Frandroid : les pages de Freebox OS portent l'extension .php, mais aucun serveur PHP ne tournerait dans la box. Le scanner, qui devine les technologies à partir d'indices visibles de l'extérieur, aurait été trompé.

Hors réseau Free, la France compterait environ 250 000 services PHP, loin derrière les États-Unis. Le chiffre reste élevé, mais ce n'est pas le nombre de systèmes réellement vulnérables.

La leçon vaut pour vos propres outils. Un scan externe peut se tromper dans les deux sens : signaler une box qui n'est pas concernée, ou ignorer un PHP caché derrière un proxy. Le chercheur 0x4148 recommande d'identifier la version de PHP qui sert réellement le trafic web. Il indique aussi n'avoir pas réussi à reproduire l'attaque avec la méthode publiée, tout en recommandant d'installer le correctif. Un échec de reproduction ne prouve pas l'absence de risque.

Pour votre équipe technique

Références : CVE-2026-109618, CVE-2026-109619, CVSS v4.0 9,2 annoncé. Versions corrigées : à lire dans le bulletin officiel de php.net et de votre distribution. Le chercheur 0x4148 n'a pas reproduit l'attaque sur PHP 8.4.4-FPM et lsphp 8.2.27.

Identifier le PHP qui sert le web (pas celui de la ligne de commande) : méthode principale, une page phpinfo temporaire, supprimée aussitôt après. Pour PHP-FPM, adaptez le numéro de version :

php-fpm8.4 -v
php-fpm8.4 -i | grep -i upload_progress

Mesure temporaire, d'après IT-Connect : passer la directive à Off dans le php.ini du serveur web (sous Debian et Ubuntu, celui de PHP-FPM ou d'Apache, pas celui de la CLI), puis recharger le service. Avec PHP-FPM, un fichier dédié dans conf.d, par exemple 99-php2shell.ini :

; /etc/php/8.4/fpm/conf.d/99-php2shell.ini
session.upload_progress.enabled = Off

sudo systemctl reload php8.4-fpm

Adaptez le numéro de version et le nom du service. Vérifiez ensuite la valeur effective sur la page servie par le web.

Le chercheur 0x4148 conseille aussi de restreindre les requêtes multipart/form-data inattendues quand c'est possible. Journaux à surveiller : pics de requêtes POST multipart, redémarrages ou plantages de workers PHP-FPM, activité sous l'utilisateur www-data.

Questions fréquentes

Mon site WordPress se met à jour tout seul, suis-je protégé ?

Non, pas forcément. Les mises à jour automatiques de WordPress concernent le CMS et ses extensions, pas le langage PHP du serveur. C'est l'hébergeur ou l'administrateur du serveur qui met PHP à jour.

Ma Freebox doit-elle être mise à jour ?

Non : selon Numerama, qui s'appuie sur Frandroid, aucun serveur PHP ne tourne dans la Freebox et les abonnés n'ont rien à faire. Ce qui est à traiter, ce sont vos sites et applications web en PHP.

Sources

• PHP : un correctif pour 2 failles critiques arrive aujourd'hui à 16h00 — IT-Connect, 21/10/2026
• PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws — SecurityWeek, 21/10/2026
• PHP Remote Code Execution FAQ: CVE-2026-109618 | watchTowr — watchTowr, 21/10/2026
• PHP2Shell: Inside PHP Upload Progress and the RCE I Couldn't Reproduce — 0x4148 (blog personnel)
• Faille PHP : fausse alerte pour les abonnés Freebox, une extension a trompé les détecteurs — Numerama, 21/10/2026

Comment Sedona peut aider

Ce que décrit cet article se voit depuis Internet, comme un attaquant le voit. Sedona Radar fait cet audit de sécurité externe automatisé sur votre domaine, sans rien installer, et classe ce qu'il trouve par gravité, avec un plan d'action.

Parmi ce qu'il examine :

• Vos portes ouvertes : les services qui répondent depuis Internet, les logiciels qui les font tourner et leurs failles connues.
• Les attaques web connues : des tests de failles répertoriées, joués sur vos pages, sans exploitation aboutie.

Le plan Discovery, gratuit, donne un premier Scan de Contrôle : score de risque, vos 3 vulnérabilités les plus graves, le décompte par sévérité et vos scores sur les 6 référentiels. Radar ne voit que ce qui est exposé sur Internet, pas l'intérieur de votre réseau ; il évalue votre exposition, il ne certifie rien. Pour en parler, nous contacter.

Article publié le 21/10/2026. Une erreur, une source à mettre à jour ? Nous contacter : nous corrigeons et datons la correction.