PHP2Shell, Node.js, GitLab, Railway : la semaine noire d'octobre 2026 et comment protéger votre site

PHP2Shell, Node.js, GitLab, Railway : la semaine noire d'octobre 2026

Entre le 17 et le 22 octobre 2026, l'écosystème du web a vécu l'une de ses pires semaines. PHP, Node.js, GitLab et Java ont publié des correctifs critiques. Huit certificats de l'autorité eMudhra ont été compromis. Et deux plateformes utilisées par des milliers de développeurs, Railway et OpenCode, se sont fait voler les clés API de leurs clients.

Ces événements ne sont pas liés entre eux, mais ils racontent la même histoire : les failles sont trouvées et exploitées plus vite que jamais. Ce dossier fait le tri : ce qui s'est passé, qui est concerné, et surtout quoi faire.

La réponse courte

Votre site tourne sur PHP (WordPress, WooCommerce, Laravel, Drupal…) : passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 aujourd'hui. C'est le plus urgent.
Vous avez une application Node.js : passez à 26.12.1, 24.22.1 ou 22.23.4.
Vous hébergez votre propre GitLab : mettez-le à jour, une faille notée 10/10 touche toutes les versions depuis 2014.
Tout le monde : mettez à jour navigateurs, systèmes et serveurs pour ne plus faire confiance aux certificats eMudhra compromis.
Vous utilisez Railway ou OpenCode : considérez vos clés API et mots de passe stockés là-bas comme volés, et remplacez-les.
Vous utilisez des clés OpenAI, Anthropic ou Google : fixez une limite de dépenses et des alertes dès maintenant.

Deux types de problèmes, à ne pas confondre

Comme le souligne le youtubeur Theo (t3.gg), cette semaine mélange deux choses très différentes :

Des failles (CVE) : des bugs découverts dans des logiciels que tout le monde utilise (PHP, Node.js, GitLab, Java). Personne ne vous attaque encore forcément, mais votre site est vulnérable tant que vous n'avez pas mis à jour.
Des attaques réelles : chez Railway et OpenCode, quelqu'un est entré et a volé des secrets. Là, le mal est fait : il faut limiter les dégâts.

1. PHP2Shell : la faille la plus grave de la semaine

Le 21 octobre, l'équipe PHP a publié un correctif d'urgence pour deux failles critiques (CVE-2026-109618 et CVE-2026-109619), surnommées PHP2Shell. Elles permettent à un attaquant d'exécuter du code sur votre serveur sans compte ni mot de passe. Le problème n'est pas dans un plugin : il est dans PHP lui-même, le moteur qui fait tourner WordPress, WooCommerce, Drupal, Joomla, Laravel, Magento et une grande partie des sites tunisiens.

Gravité : 9,2 sur 10 (CVSS v4) pour chacune des deux failles.
Qui est concerné : toute installation PHP qui sert des pages web (Apache avec mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP). Le risque est le plus élevé avec Apache et mod_php, où l'attaque fonctionne avant même que le code du site ne s'exécute.
Applications confirmées vulnérables : WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony et WHMCS.
PHP 8.1 et plus ancien : plus de correctif officiel. Il faut migrer, ou obtenir un correctif rétroporté de votre hébergeur ou distribution.

Le FBI a lui-même relayé l'alerte. Il demande de mettre à jour immédiatement et, si ce n'est pas possible, de mettre le système hors ligne jusqu'à ce qu'il soit protégé.

Comment fonctionne l'attaque (sans jargon)

Quand un visiteur envoie un formulaire ou un fichier, PHP lit la requête avant même que le code de votre site ne s'exécute. C'est là que se trouvent les failles.

L'attaquant pousse PHP à court de mémoire au milieu de la lecture d'une requête, avec un envoi de formulaire spécialement construit.
PHP s'arrête en plein travail et saute une partie de son nettoyage. Certaines données internes pointent encore vers de la mémoire déjà libérée.
Une deuxième requête réutilise cette mémoire (c'est ce qu'on appelle un use-after-free). Bien orchestrée, elle permet d'exécuter des commandes sur le serveur.

Schéma de l'attaque en deux requêtes : un formulaire piégé épuise la mémoire de PHP, le nettoyage est sauté, puis une deuxième requête lit la mémoire libérée et exécute du code sur le serveur. — L'attaque en deux requêtes, avant que WordPress ne s'exécute.

Comme tout se passe avant votre code, aucun plugin de sécurité WordPress ne peut bloquer cette attaque. Seule la mise à jour de PHP corrige le problème.

Une découverte faite avec l'IA, et une divulgation qui a dérapé

Les failles ont été trouvées par le chercheur Ryan Austin (@lcfr_hax) de Calif, avec OpenAI, dans le cadre d'un audit de PHP. L'équipe a décrit le schéma du premier bug à un modèle d'IA, qui a trouvé le second ailleurs dans le code. La société Wiz a aussi signalé ces failles. Le chemin le plus ancien remonte à PHP 5.4.0 : le bug dormait depuis plus de dix ans, et un problème lié avait même été repéré lors d'un audit en 2024 sans que son exploitation soit prouvée.

La publication, elle, ne s'est pas passée comme prévu. Selon le compte rendu de la PHP Foundation :

Le 20 octobre, les numéros des failles ont fuité sur les réseaux sociaux, avec une fausse note de 10/10. PHP a avancé la sortie du correctif d'un jour.
Le même soir, Calif a publié par erreur une vidéo de démonstration, vite supprimée mais recopiée. Elle a accéléré l'écriture d'exploits.
Le 21 octobre à 7h41 UTC, plus de six heures avant l'heure convenue, Chainguard a publié des images contenant le correctif. La PHP Foundation l'accuse d'avoir rompu l'embargo. Le PDG de Chainguard répond qu'il a agi parce que des exploits circulaient déjà.

Le 23 octobre, PHP a publié un avis complémentaire sur un troisième scénario, beaucoup moins probable (CVE-2026-115560). Il se neutralise avec le réglage session.upload_progress.enabled=0, détaillé plus bas.

2. Les autres failles de la semaine

Node.js : 10 failles, dont une exécution de code à distance

Le 21 octobre, Node.js a corrigé 10 failles, dont une dans le décodeur Brotli (CVE-2026-111497) qui permet d'exécuter du code à distance. Versions corrigées : 26.12.1, 24.22.1 et 22.23.4. Il n'existe pas de contournement : seule la mise à jour protège. Les versions en fin de vie (Node 20 et plus ancien) restent vulnérables.

GitLab : une faille notée 10 sur 10

GitLab a publié en urgence un correctif pour CVE-2026-110264, une exécution de code sans authentification qui touche les versions depuis GitLab 7.0 (2014). GitLab.com est déjà corrigé, mais si vous hébergez votre propre GitLab, passez à l'une des versions corrigées (19.5.1, 19.4.3, 19.3.6, 19.2.9 et suivantes pour les autres branches).

eMudhra : des certificats dont la clé secrète valait « 4 »

Huit certificats intermédiaires de l'autorité de certification indienne eMudhra ont été compromis. Leurs clés privées étaient si faibles qu'on pouvait les retrouver en moins d'une seconde. L'une d'elles valait littéralement le nombre 4. Avec ces clés, un attaquant peut fabriquer un faux certificat HTTPS pour n'importe quel site et intercepter le trafic.

Mozilla, Google et Apple ont bloqué ces certificats dans leurs navigateurs, et Ubuntu et Debian les ont retirés le 20 octobre. Mais les logiciels qui ont leur propre liste de certificats (applications Java, conteneurs, vieux serveurs) peuvent encore leur faire confiance. C'est d'ailleurs la raison de l'alerte Java ci-dessous.

Oracle Java : une alerte d'urgence liée à eMudhra

Oracle a publié le 21 octobre une alerte hors calendrier pour Java SE et GraalVM (CVE-2026-91403, note 9,1). Java pouvait continuer à accepter les certificats eMudhra compromis. Si vous faites tourner des applications Java, appliquez cette alerte en plus du correctif trimestriel d'octobre.

3. Les attaques : vos clés API sont devenues une cible

OpenCode : des clés OpenAI, Anthropic et Google volées

Le 17 octobre, l'outil de développement assisté par IA OpenCode a annoncé qu'un attaquant avait accédé à un ancien système de sa console web, en cours de fermeture. Ce système contenait les clés API que certains utilisateurs y avaient enregistrées pour OpenAI, Anthropic ou Google. Environ 1,4 % des utilisateurs de la console sont touchés. Certains ont reçu des factures allant jusqu'à 1 700 dollars en quelques minutes. Les fournisseurs ont bloqué les clés exposées, et OpenAI rembourse les crédits consommés. L'outil open source lui-même n'est pas concerné.

Railway : les variables d'environnement des clients exposées

Le 21 octobre, l'hébergeur Railway a révélé qu'un tiers avait pu accéder aux systèmes qui stockent les variables d'environnement de ses clients : clés API, mots de passe de bases de données, identifiants divers. Pour une partie des clients, les valeurs déchiffrées ont pu être lues. Railway a suspendu les déploiements pendant l'enquête, ce qui a empêché de nombreux clients de remplacer leurs secrets rapidement.

Pourquoi voler des clés qui seront bloquées en quelques heures ?

Une clé API d'IA volée permet de consommer des milliers de dollars de calcul aux frais de quelqu'un d'autre avant d'être révoquée. OpenCode a lui-même lié l'incident à une « attaque de distillation à grande échelle » : des acteurs qui n'ont pas le droit d'acheter l'accès à ces modèles s'en servent pour générer en masse des réponses et entraîner leurs propres modèles. Cette explication reste discutée. Mais la conclusion pratique ne l'est pas : toute plateforme qui stocke des clés API est désormais une cible, et votre clé peut coûter cher même si vous n'êtes pas visé personnellement.

Pourquoi tout arrive en même temps

Ce n'est pas un hasard. Les modèles d'IA savent maintenant :

trouver des failles que les outils classiques ratent, comme PHP2Shell ;
lire un correctif publié et en déduire comment attaquer les versions non corrigées, en quelques heures au lieu de quelques semaines.

Autrement dit, le délai entre la publication d'un correctif et les premières attaques s'effondre. Pendant des années, mettre à jour « dans le mois » suffisait. Ce n'est plus le cas : la plupart des piratages visent des failles déjà corrigées, sur des sites qui n'ont pas été mis à jour.

Comment vous protéger : la checklist complète

1. Faites l'inventaire

Vous ne pouvez pas protéger ce que vous ne connaissez pas. Listez ce qui tourne où : site vitrine, boutique, outils internes, et les services qui font tourner PHP, Node.js ou Java à votre insu (plugins, logiciels de facturation, CRM auto-hébergés). Commencez par tout ce qui est accessible depuis Internet.

2. Mettez à jour PHP

Vérifiez votre version. Hébergement mutualisé (cPanel, Plesk) : cherchez « Sélecteur de version PHP » ou « MultiPHP Manager ». WordPress : Outils → Santé du site → Infos → Serveur. Serveur dédié ou VPS : lancez php -v, et vérifiez aussi la version utilisée par PHP-FPM ou Apache.
Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou plus récent). Les distributions Linux ont reçu les correctifs à l'avance : un apt upgrade ou dnf update suffit souvent, suivi d'un redémarrage de PHP-FPM ou d'Apache.
En mutualisé, écrivez à votre hébergeur et demandez une confirmation écrite que les correctifs sont appliqués.
En PHP 7.x, 8.0 ou 8.1, migrez vers PHP 8.3 ou 8.4. Testez d'abord sur une copie du site : les vieux thèmes et plugins cassent parfois.

3. Mettez à jour le reste

Node.js : 26.12.1, 24.22.1 ou 22.23.4, puis redéployez vos applications.
GitLab auto-hébergé : dernière version corrigée de votre branche.
Java : correctif d'octobre et alerte CVE-2026-91403.
eMudhra : mettez à jour navigateurs, systèmes d'exploitation et images de conteneurs, et vérifiez les applications qui embarquent leur propre liste de certificats.

4. Si vous ne pouvez pas mettre à jour PHP tout de suite

PHP et Calif recommandent ces mesures temporaires et partielles :

Désactivez le suivi d'envoi de fichiers : session.upload_progress.enabled=0. Cette mesure couvre aussi le scénario publié le 23 octobre.
Calif suggère aussi memory_limit=-1. Attention : cela supprime la limite de mémoire de PHP, et un script gourmand peut alors faire tomber votre serveur. À n'utiliser que le temps de patcher.
Si le site n'est pas essentiel, suivez le conseil du FBI : mettez-le hors ligne jusqu'à la mise à jour.

5. Protégez vos clés API et vos secrets

Si vous utilisez Railway ou OpenCode : remplacez toutes les clés et tous les mots de passe qui y étaient stockés, en commençant par ceux qui donnent accès à de l'argent (IA, paiement) ou à des données (bases de données).
Une clé par projet et par environnement. Si une clé fuit, vous la révoquez sans tout casser.
Fixez une limite de dépenses et des alertes de consommation chez OpenAI, Anthropic et Google. C'est ce qui sépare une fuite à 20 dollars d'une fuite à 2 000.
Donnez le minimum de droits à chaque clé (lecture seule quand c'est possible, accès limité à un seul projet).
Ne mettez jamais de clé secrète dans le code du navigateur, d'une application ou d'un dépôt Git. Gardez-les côté serveur, dans un gestionnaire de secrets.
Sachez révoquer en deux minutes. Notez où se trouve chaque clé et qui peut la changer.

6. Surveillez et sauvegardez

Vérifiez que vous avez une sauvegarde récente, stockée hors du serveur.
Surveillez les signes listés par le FBI : des processus PHP qui lancent des commandes système ou téléchargent des fichiers.
Cherchez dans les logs des pics de requêtes POST volumineuses ou des redémarrages inhabituels de processus PHP.
Repérez les fichiers PHP récemment modifiés que vous ne reconnaissez pas, et les nouveaux comptes administrateur.
Consultez régulièrement la consommation de vos comptes d'IA et de vos services payants.

Ce qu'il faut retenir

Un site web n'est jamais « fini ». Il repose sur des couches (serveur, langage, CMS, plugins, services tiers) qui ont toutes besoin d'être mises à jour, et sur des clés qu'il faut protéger. Cette semaine le montre : la faille la plus grave ne venait ni de WordPress ni d'un plugin, mais du langage lui-même, et les vols de clés venaient de plateformes de confiance.

Les failles vont continuer à sortir plus vite qu'avant. La meilleure défense reste simple : mettre à jour vite, limiter ce qu'une clé volée peut coûter, et savoir réagir. Si personne ne s'occupe de la maintenance de votre site, c'est le bon moment pour y remédier. Vous ne savez pas quelle version de PHP fait tourner votre site, ou vous voulez qu'on vérifie avec vous ? Décrivez-nous votre situation et nous vous répondons sous 24 heures.

PHP2Shell, Node.js, GitLab, Railway : la semaine noire d'octobre 2026 et comment protéger votre site