Le 21 octobre 2026, PHP a publié quatre versions d'urgence ; : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ce n'était pas une mise à jour de routine. Elles corrigent deux vulnérabilités baptisées php2shell, identifiées comme CVE-2026-109618 et CVE-2026-109619, qui permettent l'exécution de code sur le serveur sans authentification préalable. L'agence fédérale américaine de cybersécurité a demandé ce même jour d'appliquer le correctif sans attendre (CISA, 2026).
L'exécution de code à distance sans authentification est, dans la liste des choses qui peuvent arriver à un site web, la combinaison que personne ne veut voir. Pas d'identifiants volés. Pas de session détournée. Pas de connaissance intime de l'application. Si le serveur expose une version concernée, l'attaquant envoie des instructions et le serveur les exécute. Rien à voler. Rien à casser.
Cet article ne répète pas les informations déjà partout. Il répond à ce que personne ne répond ; : comment savoir si vous êtes exposé, quoi faire cette semaine et qui occupe chaque partie du travail. Si vous dirigez une équipe technique avec des sites sous PHP, les vôtres, ceux de vos clients ou hérités, c'est ce qui se trouve devant vous, sauf que cette fois le calendrier ne l'a pas fixé votre plan trimestriel mais quelqu'un qui publiait deux CVE un mardi matin.
php2shell désigne deux vulnérabilités de PHP, CVE-2026-109618 et CVE-2026-109619, qui permettent l'exécution de code sur le serveur sans authentification. Elles ont été divulguées les 20 et 21 octobre 2026 et le correctif est sorti le 21 même ; : les versions sûres sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35 dans chaque branche (Huntress, 2026). La CISA a demandé de les appliquer immédiatement, car l'exploitation a commencé en heures, pas en semaines. Voici comment auditer quelles surfaces tournent sous PHP, dans quel ordre corriger, quoi vérifier ensuite (identifiants, journaux, webshells) et ce que la NIS2 vient faire là-dedans.
Ce qu'est php2shell et pourquoi le correctif est sorti en 24 heures
La séquence a été rapide, même au regard des standards de ce type de faille. Le 20 octobre, le projet PHP a annoncé une publication hors calendrier pour le lendemain ; ; le 21, à 14h00 UTC, les détails techniques et les versions corrigées sont sortis presque ensemble (Huntress, 2026). La marge pour inventorier ce qui était exposé avant l'existence d'un exploit public a été pratiquement nulle, et pas parce que le projet PHP a mal fait les choses, mais parce que l'inventaire des surfaces d'une organisation moyenne, réparti entre équipes plateforme, développement et un ou deux prestataires externes, ne se fait pas en un après-midi ni à coups de bonnes intentions.
Les branches concernées sont celles sous support actif ; : 8.2, 8.3, 8.4 et 8.5. Les versions qui corrigent les deux CVE sont les quatre du tableau. Si un environnement tourne sur une 8.2 à 8.5 antérieure à la sienne, il est en zone de risque, et il l'est même si personne ne l'a documenté, parce que la cartographie de ce qui tourne en production et celle que l'équipe croit voir tourner divergent depuis des années dans toute entreprise qui a hérité de systèmes, absorbé des projets ou intégré des équipes extérieures.
| Branche PHP | Version corrigée (21 octobre 2026) |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
La différence entre une exécution de code qui exige des identifiants et une qui ne les exige pas, c'est la différence entre un incident et une campagne. La première est exploitée par celui qui est déjà entré. La seconde par n'importe qui. Un script et une liste d'adresses suffisent. Le jour même, à grande échelle. Voilà pourquoi l'alerte de la CISA (2026) ne parle pas de risque potentiel, et pourquoi des tentatives d'exploitation massives contre des sites non corrigés étaient enregistrées dans les heures suivant la publication des détails (Help Net Security, 2026).
L'IA a trouvé la faille ; : ce que cela change pour votre calendrier
Les vulnérabilités ont été localisées en août 2026 avec l'aide d'outils d'analyse fondés sur l'IA, selon la chronique de l'incident (Wikipedia, 2026). Elles étaient là depuis des années. Une semaine avant le correctif, CNBC (2026) rapportait l'autre moitié du même schéma ; : Mythos, le modèle d'Anthropic dédié à localiser des failles logicielles, avait exposé chez Bank of America assez de défauts pour que la banque annonce le recrutement de 1 ;000 professionnels externes appuyant l'équipe interne de correction. Traduction pour votre calendrier ; : la découverte s'est industrialisée, la correction reste humaine, et un avis de vingt-quatre heures devient plusieurs semaines de travail dès que les fenêtres de maintenance ne dépendent pas de votre équipe.
Black Kite (2026) a compté 7 ;551 organisations publiées comme victimes de ransomware en 2026, soit 24,9 ;% de plus que l'année précédente. Chaque faille exposée alimente cette machine, et la machine ne distingue pas ceux qui ont corrigé à temps de ceux qui comptaient le faire à la fin du sprint.
Comment savoir si votre site est exposé
L'inventaire, c'est la moitié du travail. Cinq questions pour l'ordonner.
- Quelle version de PHP sert chaque environnement. Pas celle que documente la documentation ; : celle que répond le serveur. Environnements publics, préproduction oubliée, vieux conteneurs et ce CMS que personne ne touche depuis 2023.
- S'il y en a une entre 8.2 et 8.5 en dessous de la version corrigée de sa branche. 8.2.35, 8.3.36, 8.4.27 et 8.5.12 sont la limite (Huntress, 2026). En dessous, exposé.
- Ce que gère l'hébergeur et ce que vous gérez. En mutualisé ou en hébergement géré, le moteur PHP est mis à jour par le prestataire. La question n'est pas de savoir si le correctif existe, mais quand il l'applique et s'il prévient ses clients, parce que le calendrier du prestataire et sa politique d'avis décident ici plus que votre propre documentation d'infrastructure.
- Ce qui se passe avec WordPress et les autres CMS. La vulnérabilité est dans le moteur PHP, pas dans le CMS ni dans ses extensions ; : mettre à jour les extensions ne corrige pas php2shell. Le site est couvert quand le serveur sert une version corrigée, pas une minute avant, et il vaut la peine de demander par écrit à l'hébergeur la version servie aujourd'hui et la date d'engagement de mise à jour.
- Ce qui tourne sur des branches sans support, comme PHP 7. Ces versions ne recevront jamais ce correctif. Le risque accumulé n'a pas de date de péremption et la sortie raisonnable, c'est de planifier la migration.
Que faire cette semaine
- Mettre à jour vers les versions corrigées sur toutes les surfaces inventoriées, en commençant par celles exposées à internet. La CISA (2026) ne nuance pas l'ordre ; : elle demande l'immédiat. Sans fenêtre de grâce.
- Si une surface ne peut pas être touchée tout de suite, la réduire ou l'isoler en attendant le correctif, et surveiller ce qui lui arrive.
- Une fois corrigé, faire tourner identifiants, clés API et secrets qui vivaient sur le serveur, et relire les journaux d'accès et d'exécution à la recherche de webshells ; : quand l'exécution a été possible sans authentification, le correctif ferme la porte mais ne regarde pas qui était entré avant. C'est l'étape que la plupart des équipes sautent, et celle qui sépare une fermeture propre d'un incident latent qui ressurgit en janvier.
- Vérifier avec un test externe. Un correctif appliqué, c'est une affirmation ; ; un test qui tente d'exploiter la surface et échoue, c'est un fait, et il vaut mieux le confier à quelqu'un d'autre que celui qui a appliqué le correctif, parce qu'auditer son propre travail de ses propres mains reste la façon la plus confortable de ne rien trouver.
Et si votre organisation est soumise à la réglementation, la gestion de ces vulnérabilités n'est pas une bonne pratique volontaire mais une obligation qui a un nom, comme le détaille notre guide de ce qu'est la directive NIS2 pour les entreprises.
Le goulot d'étranglement n'est pas le correctif, c'est qui l'applique
Le correctif est gratuit. Le temps, non. Il est publié depuis plusieurs jours, et ce qui manque, c'est le temps des personnes capables d'inventorier les environnements, mettre à jour les moteurs, relire les journaux et signer que la surface est fermée. Quand ce travail s'accumule, apparaît la facture que personne n'avait budgétée ; : heures de plateforme, heures de développement et heures de relecture, toutes en concurrence avec la feuille de route déjà engagée avant mardi.
Le marché français était déjà sous tension avant l'événement. Selon l'analyse de marché de Shakers, 4 ;879 des 43 ;038 offres tech actives en France au 26 octobre 2026 mentionnent la cybersécurité, soit plus d'une offre sur dix, et pas comme une responsabilité annexe de profils voisins mais comme une exigence explicite de la description. Quand deux CVE avec correctif urgent tombent un mardi, cette demande n'attend pas le cycle annuel de recrutement ; : elle se couvre avec une capacité qui démarre cette semaine.
Pour l'inventaire et la correction, s'appuyer sur un développeur PHP senior qui a vécu des montées de version massives est la voie rapide. Pour la suite, travailler avec un expert en cybersécurité qui audite la surface et signe ce qui est resté fermé. Intégrer cette capacité via une véritable infrastructure de recrutement, avec des conditions validées et sans alourdir l'effectif permanent, c'est la différence entre couvrir une urgence de deux semaines et porter un coût fixe de janvier à décembre.
Questions fréquentes sur php2shell
- Quelles versions de PHP sont sûres après php2shell ; ?
Celles publiées le 21 octobre 2026 ; : 8.5.12, 8.4.27, 8.3.36 et 8.2.35, chacune dans sa branche. Tout environnement sous une version antérieure de PHP 8.2 à 8.5 reste exposé aux deux CVE, et les branches sans support, comme PHP 7, n'ont pas de correctif.
- WordPress est-il concerné par php2shell ; ?
La vulnérabilité est dans le moteur PHP, pas dans WordPress ni dans ses extensions. Un site sous WordPress est couvert quand l'hébergeur ou le serveur sert une version corrigée de PHP. Mettre à jour extensions et thème ne remplace pas ce correctif.
- Que signifie un RCE sans authentification ; ?
Qu'un attaquant peut faire exécuter son code par le serveur sans utilisateur, sans mot de passe et sans session préalable. Aucun identifiant volé ni accès initial requis ; : atteindre l'URL exposée suffit, et c'est pourquoi ce type de faille se prête aux campagnes automatisées et massives.
- Est-ce déjà exploité ; ?
Oui. La CISA a demandé d'appliquer le correctif immédiatement le 21 octobre 2026, et des tentatives d'exploitation massives contre des sites non corrigés étaient enregistrées dans les heures suivant la publication des détails (Help Net Security, 2026).
- Que faire si je ne peux pas mettre à jour cette semaine ; ?
Réduire la surface exposée en attendant ; : restreindre l'accès aux endpoints concernés, surveiller ce qui leur arrive et fixer une date ferme au correctif. Et si le système tourne sur une branche sans support, le correctif n'arrivera jamais ; : la sortie, c'est de planifier la migration de version.
. 