Une faille critique dans PHP, une technologie présente dans la plupart des organisations, permet de prendre le contrôle d’un serveur à distance. Cette page explique simplement sa gravité et les points à contrôler avec vos équipes techniques et votre infogérant, puis décrit la méthode et les outils qu’un infogérant devrait avoir en place, avec un exemple appliqué.

En bref

• Quoi : deux failles critiques dans PHP, surnommées « PHP2Shell », révélées le 21 octobre 2026 par une alerte du NCSC, l’agence britannique de cybersécurité.
• Le risque : un attaquant peut prendre la main sur un serveur sans mot de passe. Des attaques sont déjà en cours.
• Qui doit agir : l’équipe technique ou l’infogérant, responsables du maintien en condition opérationnelle (MCO) et de sécurité (MCS). Pour un site en hébergement mutualisé, l’hébergeur.

Pourquoi c’est grave

Un serveur compromis peut mener au vol de données clients, à un rançongiciel ou à l’arrêt de l’activité. Une fuite de données personnelles doit être notifiée à la CNIL. Pour les organisations soumises à la directive NIS2, la direction doit approuver et superviser les mesures de sécurité : s’assurer que cette faille est traitée en fait partie.

Qui est concerné ? Quelques exemples

PHP ne se limite pas aux sites web. Il fait souvent tourner, sans qu’on le sache :

• le site internet ou la boutique en ligne (WordPress, Prestashop) ;
• l’outil de gestion du parc informatique ou de tickets (GLPI) ;
• le partage de fichiers ou la messagerie web (Nextcloud, Roundcube) ;
• le logiciel de gestion (Dolibarr) ou une application métier développée sur mesure ;
• l’interface d’administration de certains pare-feu (pfSense, OPNsense).

Ce qu’une petite entreprise doit demander à son infogérant : 7 points à contrôler

1. Inventaire : avons-nous la liste de tous nos systèmes qui utilisent PHP, y compris les logiciels et les équipements qui l’embarquent ?
2. Exposition : lesquels sont accessibles depuis Internet ? Ce sont eux qu’il faut traiter en premier.
3. Correction : sont-ils tous passés à une version corrigée, et sinon, à quelle date le seront-ils ?
4. Mesures provisoires : pour ce qui ne peut pas être corrigé tout de suite, qu’a-t-on fait pour réduire le risque (accès restreint, service coupé temporairement) ?
5. Traces d’intrusion : a-t-on vérifié qu’aucun système n’a été compromis depuis le 21 octobre ?
6. Contrat : le contrat d’infogérance fixe-t-il un délai pour corriger les failles critiques ? A-t-il été respecté ?
7. Compte rendu : qui informe la direction de l’avancement, et quand aura-t-elle la confirmation que tout est traité ?

Si les réponses tardent ou restent floues, c’est un signal en soi : l’organisation n’est pas encore prête pour ce type d’alerte.

Côté infogérant : la méthode et les outils à avoir en place

Un infogérant responsable du MCS ne découvre pas la faille dans la presse. Il la traite avec un processus établi et des outils déjà en place, qui lui permettent de répondre aux 7 questions en quelques heures.

Le processus

1. Veille : suivre les avis du CERT-FR, des éditeurs et des sources reconnues (NCSC, CISA), et être alerté le jour même.
2. Qualification : interroger l’inventaire pour savoir en quelques minutes quels clients et quels systèmes utilisent le composant touché, et en quelle version.
3. Priorisation : croiser la gravité de la faille, l’exposition sur Internet et la criticité métier du système. Une faille critique sur un système exposé se traite dans la journée.
4. Mesures provisoires : restreindre l’accès, activer une règle de pare-feu applicatif ou couper un service quand le correctif n’est pas encore applicable.
5. Correction : appliquer les correctifs selon une procédure testée, après sauvegarde, en commençant par les systèmes exposés.
6. Vérification : contrôler la version obtenue et relancer un scan de vulnérabilités.
7. Recherche de compromission : examiner les journaux et les alertes de détection sur la période d’exposition.
8. Compte rendu : informer chaque client de ce qui était concerné, de ce qui a été fait et de ce qui reste à faire, puis tirer les leçons pour la fois suivante.

Les outils à avoir en place

Besoin	Outil attendu	Exemples
Savoir ce qui existe	Inventaire automatique des serveurs, logiciels et versions (CMDB)	GLPI avec agent d’inventaire, OCS Inventory
Savoir ce qui est vulnérable	Scanner de vulnérabilités, interne et externe	Greenbone/OpenVAS, Nessus, module de vulnérabilités de Wazuh
Savoir ce qui est exposé	Surveillance de la surface d’attaque sur Internet	scan externe régulier des adresses et domaines publics
Être alerté	Veille sur les vulnérabilités, filtrée sur l’inventaire	abonnement CERT-FR, flux des éditeurs
Corriger vite et partout	Gestion centralisée des mises à jour	Ansible, mises à jour de sécurité automatiques, reconstruction régulière des images Docker
Détecter une intrusion	Supervision de sécurité et centralisation des journaux	Wazuh, SIEM, EDR
Revenir en arrière	Sauvegardes régulières, isolées et testées	sauvegarde externalisée avec test de restauration
S’engager	Délais de correction écrits dans le contrat	ex. : faille critique exposée corrigée sous 48 h

Un infogérant qui ne peut pas montrer ces outils, ou qui met plusieurs jours à répondre aux 7 questions, n’est pas organisé pour le MCS.

Exemple appliqué à PHP2Shell

1. Cartographier

Recenser tout ce qui utilise PHP, avec sa version, son hébergement et son responsable. Pour lire la version :

• site WordPress : Outils > Santé du site > Informations > Serveur > Version de PHP ;
• serveur : php -v ;
• conteneur Docker : docker exec <conteneur> php -v, pour chaque conteneur ;
• équipement (pare-feu, NAS) : page de mise à jour ou notes de version du fabricant.

Exemple d’inventaire :

Élément	Hébergement	Version PHP	Exposition	Statut
Site vitrine WordPress	Mutualisé	8.4.27	Public	Corrigé
Boutique en ligne	VPS	8.3.35	Public	À corriger en urgence
Pare-feu	Équipement	intégré	Admin filtrée par IP	Mise à jour éditeur à planifier
Outil de tickets GLPI	Conteneur Docker	8.2.30	Interne	À corriger cette semaine

2. Identifier ce qui est exposé

Exposition	Exemples	Priorité
Public sur Internet	site vitrine, boutique, extranet	Immédiate
Accessible depuis Internet, mais filtré	administration limitée à quelques IP, accès par VPN	Dans la semaine
Interne uniquement	outil métier sur le réseau local	Planifiée

L’exposition se vérifie, elle ne se suppose pas : un outil « interne » publié sur un nom de domaine ou derrière un reverse proxy est en fait public.

3. Mettre à jour

Versions corrigées minimum :

Branche PHP	Version corrigée minimum
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35 (fin du support de sécurité le 31/12/2026)
8.1 et plus ancien	Plus supporté : migrer vers 8.4 ou 8.5

Exemples selon l’hébergement :

• Hébergement mutualisé : l’hébergeur installe le correctif. Vérifier la version et ouvrir un ticket si rien ne bouge. Garder la même branche (8.4 reste 8.4) : changer de branche n’accélère pas la correction.
• Serveur dédié ou VPS (Debian, Ubuntu) : apt update && apt upgrade, puis redémarrer PHP-FPM ou Apache.
• Conteneur Docker : docker compose build --pull si l’image est construite localement, docker compose pull si elle est téléchargée, puis docker compose up -d.
• Logiciel ou équipement avec PHP intégré (pare-feu, NAS) : appliquer la mise à jour de l’éditeur dès sa sortie, après une sauvegarde de la configuration, en limitant l’accès à l’administration en attendant.

Seule la mise à jour protège. Le réglage session.upload_progress.enabled = 0, parfois cité, ne suffit pas.

4. Vérifier et rechercher des traces d’intrusion

Après la mise à jour, relire la version pour confirmer le correctif. Puis rechercher :

• des erreurs « Allowed memory size exhausted » en rafale dans les journaux PHP ;
• des fichiers .php créés ou modifiés depuis le 20 octobre, notamment dans les dossiers d’envoi de fichiers ;
• des processus shell (sh, bash) lancés par l’utilisateur du serveur web (www-data) ;
• des comptes administrateurs ajoutés ou des tâches planifiées inconnues.

En cas de doute : isoler le système, restaurer une sauvegarde saine, appliquer les correctifs et changer tous les mots de passe et jetons d’accès.

Pour la prochaine faille

Il y en aura d’autres. Les organisations qui les traversent sereinement ont préparé à l’avance ce que décrit la méthode ci-dessus : une cartographie à jour, une vision vérifiée de ce qui est exposé et un processus de mise à jour défini avec l’infogérant (veille, délais selon la gravité, vérification, compte rendu). C’est aussi ce que demandent le guide d’hygiène informatique de l’ANSSI, la norme ISO/IEC 27001 (gestion des vulnérabilités techniques) et la directive NIS2.

Les failles en détail

• CVE-2026-109618 : un manque de mémoire peut interrompre PHP alors que les données internes d’une requête ne sont que partiellement initialisées. Le nettoyage de la requête traite ensuite ces données invalides comme valides.
• CVE-2026-109619 : un état interne lié à une requête peut survivre après la libération de sa mémoire. La requête suivante traitée par le même processus peut réutiliser cet état périmé.

Combinées, ces corruptions mémoire permettent une exécution de code à distance sans authentification. Tout script PHP accessible suffit.

Les failles ont été découvertes par Ryan Austin et l’équipe de Calif, avec OpenAI et Wiz, dans le cadre du programme « Patch the Planet » d’OpenAI, avec l’aide d’un assistant d’intelligence artificielle. Calif les a signalées à l’équipe PHP les 11 et 21 août 2026. Les correctifs sont sortis le 21 octobre, au lendemain d’une fuite sur les réseaux sociaux (récit de la découverte).

Comment je peux vous aider

Je ne remplace pas votre infogérant : je vous aide à être prêts. Fort de 25 ans d’expérience, j’accompagne la mise en place de la cartographie, de l’analyse de l’exposition et du processus de mise à jour, avec des outils et des pratiques adaptés à votre organisation et conformes aux référentiels de sécurité. Je peux aussi vous aider à poser ces 7 questions et à interpréter les réponses. Contactez-moi

Sources : NCSC, Calif, Datadog Security Labs, watchTowr. Article mis à jour le 22 octobre 2026.