Le mercredi 21 octobre 2026 restera dans les annales de la cybersécurité. Deux failles critiques dans PHP, baptisées collectivement PHP2Shell, ont été publiées avec leurs correctifs en fin d’après-midi. Avant même leur publication officielle, des prototypes d’exploitation circulaient sur les réseaux sociaux. Des sites gouvernementaux se sont mis hors ligne par précaution. Des médias aussi. L’ANSSI a émis une alerte d’urgence. La CISA, la NSA et le CERT-EU également.
Ce n’était pas une alerte de routine.
Nous gérons plusieurs dizaines de plateformes Moodle et de serveurs pour nos clients. Voici ce qui s’est passé, ce que nous avons fait, et ce que ça change pour la suite.
PHP2Shell : une faille dans le moteur, pas dans Moodle
Pour comprendre pourquoi cette faille était aussi sérieuse, il faut saisir une distinction importante : Moodle n’est pas une application autonome. C’est une application web qui tourne sur PHP, un langage de programmation qui fait office de moteur côté serveur. PHP est présent sur environ 70 % des sites web dans le monde, soit plus de 600 000 serveurs en France selon l’ANSSI.
Mettre à jour Moodle ne suffisait pas. C’est PHP lui-même, installé sur le serveur qui fait tourner Moodle, qui devait être mis à jour. Une nuance qui change tout dans la façon de réagir.
PHP2Shell regroupe deux vulnérabilités distinctes (CVE-2026-109618 et CVE-2026-109619) permettant toutes les deux d’exécuter du code à distance sur un serveur, sans aucune authentification préalable. Concrètement : lire l’intégralité des données, accéder aux bases de données, récupérer des clés API, prendre le contrôle de la machine. Moodle, WordPress, Drupal, Nextcloud, phpMyAdmin… toute application tournant sur PHP était concernée.
La seule protection réelle : mettre à jour PHP sur le serveur. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Tout serveur antérieur restait exposé, peu importe la qualité du code de l’application qui tourne dessus.
Pourquoi toutes les plateformes Moodle étaient concernées
Moodle HQ l’a dit explicitement dans sa communication officielle à l’ensemble de la communauté mondiale : PHP2Shell n’est pas une faille dans Moodle, mais dans PHP sur lequel il tourne. Aucune version de Moodle n’était immunisée. La variable décisive n’était pas la version de Moodle installée. C’était la réactivité de l’équipe qui gère le serveur.
Moodle HQ a mis à jour ses propres infrastructures dès la publication du patch. Pour tous les autres, la responsabilité revenait à ceux qui opèrent les serveurs : hébergeur spécialisé, DSI interne ou prestataire externe.
Ce que nous avons fait à Pimenko
Nous avons suivi l’affaire de près dès le mercredi matin. L’annonce d’une publication en fin d’après-midi, combinée aux exploits qui circulaient avant l’heure officielle, nous a conduits à passer en mode intervention dès que les correctifs sont devenus disponibles.
Pour les plateformes hébergées directement chez Pimenko, sur notre infrastructure Scaleway en France ou en Europe, nous avons déployé les mises à jour PHP sur l’ensemble de notre parc dès le mercredi soir. Nos clients n’ont eu aucune action à effectuer. Certains nous avaient contactés dans la journée pour demander une mise hors ligne préventive de leur site : nous l’avons fait immédiatement.
Pour les plateformes hébergées chez nos clients, le travail a demandé plus de coordination. Chaque infrastructure a ses propres contraintes : versions d’OS différentes, distributions différentes (Ubuntu, Debian, RedHat), et selon les environnements, les modalités d’application du correctif PHP varient. Pas de recette universelle. Nous avons travaillé au cas par cas, en lien direct avec les équipes techniques de chaque organisation.
L’ensemble de nos interventions était finalisé dès le jeudi. Moins de 24 heures après la publication des correctifs, notre parc entier était sécurisé.
Patch the Planet, l’IA et la découverte des failles : ce qui s’est vraiment passé
PHP2Shell n’a pas été découverte de façon ordinaire. C’est dans le cadre du programme Patch the Planet d’OpenAI, lancé en juin 2026, que Calif, une entreprise de cybersécurité partenaire du programme, a identifié la première faille. Ses chercheurs ont utilisé GPT-5.6 Sol pour auditer le code source de PHP. Indépendamment, l’équipe de Wiz (rachetée par Google) est arrivée aux mêmes conclusions avec Gemini 4 Argon quelques semaines plus tard. Les deux équipes ont rapporté leurs découvertes à l’équipe PHP en août, permettant une coordination de deux mois avant la divulgation publique, avec la PHP Foundation, Cloudflare, AWS, et plusieurs agences gouvernementales dont l’ANSSI, la CISA et la NSA.
Là où les versions divergent, c’est sur le rôle exact de l’IA. OpenAI et Wiz mettent en avant la contribution des modèles. Mais Calif, pourtant à l’origine de la découverte, nuance fortement : « Aucun outil spécial ni modèle inaccessible à tous n’a été utilisé lors de la découverte initiale. Je me suis concentré sur quelque chose où j’avais de l’expérience, je connaissais bien l’histoire de ces vulnérabilités. Connaître sa cible reste aussi pertinent que jamais. »
La vérité est probablement entre les deux : l’IA a été un outil utile, disponible à tous, mais c’est l’expertise humaine et la connaissance fine de l’historique des failles PHP depuis 2004 qui ont rendu la découverte possible.
Ce que cette histoire dit de manière plus large est en revanche clair. Heartbleed en 2014, Log4Shell en 2021, PHP2Shell en 2026 : les crises de cette ampleur se répètent et s’accélèrent. OpenAI le dit sans détour : « nous prévoyons une forte hausse de découvertes similaires dans les mois à venir. » Les mêmes outils qui permettent de trouver les failles permettent aussi de les exploiter plus vite. La fenêtre entre la découverte d’une vulnérabilité et son exploitation active se réduit.
Ce que ça dit de notre approche de la maintenance
PHP2Shell n’a pas été résolu sur les instances gérés par Pimenko rapidement par hasard. C’est le résultat d’une culture de maintenance appliquée bien avant les crises : des cycles réguliers de mises à jour côté serveur et côté Moodle, des procédures connues, des accès en place. Quand une faille critique est publiée, nous ne partons pas de zéro. La question n’est pas « comment faire ? », mais « dans quel ordre ? ». C’est cette culture de l’anticipation et de la rigueur technique qui a contribué a être reconnus Newcomer of the Year aux Moodle Partner Awards 2026.
Si cette semaine a confirmé quelque chose, c’est que la maintenance d’une plateforme Moodle ne se joue pas uniquement au niveau du code Moodle. Elle se joue au niveau de l’infrastructure complète : OS, PHP, serveur web, configuration réseau. Une mise à jour Moodle sans mise à jour serveur laisse des portes ouvertes. Et avec des attaquants de plus en plus outillés, la réactivité devient un avantage décisif.
Nous avons déjà engagé des travaux pour aller encore plus vite sur ce type d’interventions, notamment sur l’automatisation du déploiement des correctifs urgents. PHP2Shell a confirmé que c’est la bonne direction.
Votre plateforme Moodle est-elle à jour ?
La faille est corrigée, mais les serveurs non mis à jour restent exposés. Les plateformes Moodle des organismes de formation, des établissements publics et des universités ne sont pas des cibles anodines : elles hébergent des données personnelles d’apprenants, des parcours de formation, parfois des informations sensibles. Beaucoup de ces structures gèrent leur Moodle sans ressource technique dédiée. Ce sont celles qui ont le plus de mal à réagir vite et qui restent le plus longtemps vulnérables.
Si vous gérez votre plateforme en autonomie ou avec un hébergeur qui n’a pas encore communiqué sur PHP2Shell, la première question à poser est simple : quelle version de PHP tourne sur votre serveur ?
En tant que partenaire certifié Moodle en France, nous pouvons auditer votre infrastructure et vous accompagner pour sécuriser la situation.
Questions fréquentes sur PHP2Shell et Moodle
Ma version de Moodle est-elle touchée par PHP2Shell ?
Toutes les versions de Moodle sont concernées si PHP n’a pas été mis à jour sur le serveur. La faille n’est pas dans Moodle lui-même mais dans PHP, qui fait tourner Moodle.
Comment savoir si mon serveur PHP est à jour ?
Vérifiez que votre serveur tourne sur PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 minimum. Toute version antérieure reste exposée.
Mon hébergeur a-t-il appliqué le correctif ?
C’est la bonne question à lui poser directement. Si vous n’avez pas reçu de communication de sa part sur PHP2Shell, il peut être prudent de vérifier.
