PHP2Shell : la faille critique de PHP, et pourquoi un site statique y échappe
Deux failles critiques du moteur PHP, surnommées PHP2Shell, permettent une exécution de code à distance sans authentification. Les correctifs sont sortis le 21 octobre, mais des tentatives d'exploitation ont été observées avant la divulgation. Voici ce qu'il faut faire tout de suite, puis la question de fond : pourquoi exposer un interpréteur PHP pour servir des pages qui ne changent presque jamais ?
PHP2Shell : ce que l'on sait
Le 21 octobre 2026, le projet PHP a publié des versions correctives pour deux vulnérabilités critiques du moteur lui-même : CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell ». Chacune est notée 9,2 sur l'échelle CVSS v4. Elles permettent, selon les analyses publiées par les éditeurs de sécurité, une exécution de code à distance sans authentification, par l'envoi de requêtes web multipart forgées.
Le point qui change la donne : la faille se trouve dans le moteur, pas dans votre application. Un code applicatif irréprochable n'y change rien. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les branches 8.1 et antérieures ne sont plus supportées : si vous les faites tourner, vous ne pouvez pas compter sur un correctif officiel.
Autre élément préoccupant : Amazon Threat Intelligence a rapporté des tentatives d'exploitation dès le 17 octobre, soit quatre jours avant la publication des correctifs, et un code de démonstration public circule. Les sources divergent encore sur certains détails techniques (nature exacte de chaque défaut, bornes des versions touchées) : c'est une raison de plus pour se fier aux avis officiels plutôt qu'aux résumés.
Une application PHP utilisée uniquement en ligne de commande n'expose pas le même vecteur qu'un site servi par un serveur web. Mais dès qu'un PHP répond à des requêtes HTTP venues d'Internet, considérez-le comme exposé tant qu'il n'est pas corrigé.
Que faire cette semaine
- Inventorier : sur quels serveurs, conteneurs et hébergements mutualisés tourne PHP, et dans quelle version ? C'est souvent l'étape la plus longue, parce que personne ne tient le registre à jour.
- Corriger en priorité ce qui est exposé à Internet : montée vers l'une des quatre versions corrigées, puis redémarrage des processus.
- Isoler ce qui ne peut pas être corrigé : version hors support, application qu'on n'ose pas migrer. Mettez-la hors ligne ou derrière une restriction d'accès.
- Mesures provisoires : un pare-feu applicatif (WAF), la limitation des requêtes multipart au niveau du proxy et la désactivation du suivi de progression d'envoi de session (
session.upload_progress.enabled=0) réduisent la surface, sans remplacer le correctif. Des spécialistes précisent d'ailleurs que cette dernière mesure ne suffit pas seule. - Chercher des traces : une exploitation antérieure au correctif est possible. Examinez les journaux et les fichiers récemment modifiés.
Le précédent : toujours le même scénario
Ce n'est pas la première alerte de ce type sur le parc web PHP. La mécanique se répète d'une faille à l'autre : une vulnérabilité critique, une course entre attaquants et équipes techniques, et des organisations qui découvrent qu'elles ne savent pas exactement ce qu'elles exploitent.
Corriger vite est indispensable. Mais ce n'est pas une stratégie : c'est une réaction. La vraie question est de savoir combien de vos pages ont réellement besoin de PHP à chaque visite.
La question de fond : calculer à chaque requête, vraiment ?
Prenez un site d'entreprise typique : pages vitrine, offre, blog, fiches produits, actualités. Ce contenu change quelques fois par semaine, parfois par mois. Pourtant, avec une architecture classique, chaque visite déclenche l'exécution de PHP, des requêtes en base de données et l'assemblage d'une page identique à celle de la veille.
Ce calcul répété a un coût : de la performance, de l'hébergement, et surtout une surface d'attaque. Tant qu'un interpréteur répond au public, toute faille de cet interpréteur devient votre problème.
L'export statique : générer à la publication, pas à la visite
Le principe est simple. Au lieu de calculer la page à chaque requête, on la génère une fois, au moment de la publication, sous forme de fichier HTML. Le serveur ne fait plus que distribuer des fichiers. Deux approches courantes :
- un générateur de site statique, qui transforme des sources (Markdown, modèles) en HTML lors d'un build ;
- un CMS headless avec export, où l'équipe éditoriale garde une interface de saisie confortable, mais où le site public est produit en HTML.
Pour la partie éditoriale, l'interpréteur PHP sort du chemin d'attaque public. Une faille comme PHP2Shell ne peut pas être déclenchée sur un serveur qui ne sert que des fichiers. Ce n'est pas une protection contre une faille précise : c'est la disparition d'une classe entière de risques sur ce périmètre.
Les gains annexes
- Performance : un fichier servi par un CDN est plus rapide qu'une page calculée.
- Coût : l'hébergement de fichiers coûte une fraction d'un serveur applicatif.
- Résilience : un pic de trafic ou une attaque par saturation se dilue dans le CDN.
Les limites à regarder en face
L'export statique n'est pas une solution universelle, et il serait malhonnête de le présenter ainsi.
- Les parties dynamiques restent dynamiques : formulaire de contact, recherche, espace client, panier. Elles restent côté serveur, mais on peut les isoler et les réduire : fonction serverless dédiée, API derrière authentification, back-office sur un réseau restreint plutôt qu'ouvert à tous.
- La prévisualisation éditoriale demande un environnement de test ou un aperçu : il faut l'organiser.
- Les contenus très personnalisés (tarifs par client, contenu selon le profil) se prêtent mal au statique.
- Le pipeline de build devient un composant critique : il faut le sécuriser, comme n'importe quel maillon de la chaîne de livraison.
Notre propre site telemach-learning.fr est généré en statique (modèles Jinja2, build par GitHub Actions), avec les formulaires traités par des fonctions serverless. Ce n'est pas une démonstration de force, juste un retour d'expérience : sur ce périmètre, aucune alerte PHP ne nous demande de réagir dans la nuit.
Par où commencer
Une démarche réaliste, sans refonte totale :
- Classez vos pages en deux familles : éditoriales (rarement modifiées) et applicatives (calcul, données personnelles, authentification).
- Sortez d'abord la famille éditoriale, la plus simple et la plus exposée au public.
- Gardez le dynamique, mais isolé, minimal, à jour et surveillé.
- Intégrez le build et le déploiement à un pipeline automatisé et contrôlé : c'est exactement le terrain de la démarche décrite dans notre article sur l'intégration de la sécurité dans le pipeline CI/CD.
Ces sujets (conteneurs, déploiement, exploitation) sont au cœur de notre formation DEVOPS-012 sur Kubernetes, et la réduction de la surface d'attaque fait partie des réflexes de la formation CYBE-001 Hygiène numérique.
À retenir
- PHP2Shell (CVE-2026-109618 et CVE-2026-109619) touche le moteur PHP : corrigez vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, en commençant par ce qui est exposé à Internet.
- Les versions hors support imposent une migration ou une mise hors ligne.
- Les mesures provisoires réduisent le risque sans remplacer le correctif.
- À moyen terme, ne faites plus exécuter PHP pour des pages qui ne changent pas : l'export statique de la partie éditoriale supprime cette classe de faille de votre exposition publique.
Sources : publications d'Amazon Threat Intelligence, Tenable, Sansec, Upwind, JFrog et Check Point sur PHP2Shell, consultées le 22 octobre 2026. Vérifiez toujours l'avis officiel du projet PHP pour votre version.