Introduction
La semaine du 21 octobre 2026 restera marquée. En l’espace de quelques heures, trois des socles de l’infrastructure web mondiale — PHP, Node.js et GitLab — ont publié des correctifs pour des vulnérabilités permettant une exécution de code à distance sans authentification.
Aux dernières nouvelles, plusieurs sites gouvernementaux et universitaires européens ont dû fermer préventivement le temps de patcher.
PHP2Shell : deux failles 9,2 dans le moteur lui-même
Le 21 octobre, l’équipe PHP a publié en urgence quatre versions corrigeant CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2/10 en CVSS v4.0 et permettant une exécution de code arbitraire à distance, sans compte ni mot de passe.
Contrairement aux failles applicatives habituelles, elles se situent dans le moteur PHP lui-même : tout site tournant sur une version vulnérable est exposé, quel que soit son code.
CVE-2026-109618 — corruption mémoire sur épuisement OOM. Lorsqu’une erreur d’allocation mémoire interrompt PHP, des structures internes peu rester partiellement initialisées ; le nettoyage de requête traite alors des données invalides. Les requêtes multipare sont un vecteur identifié, mais pas le seul.
CVE-2026-109619 — Use-After-Free inter-requêtes. Des références vers des données d’une requête peuvent survivre à la libération de leur mémoire et être réutilisées par la requête suivante du même processus. Le mécanisme session.upload_progress est un chemin d’exploitation connu, parmi d’autres
Versions corrigées : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 : La seule correction complète, aucun contournement ne garantit la protection.
Point notable : PHP 8.1 et les branches antérieures ne sont plus maintenues, mais l’équipe a exceptionnellement publié des correctifs source minimaux pour les branches 7.4, 8.0 et 8.1.
Ce qu’il faut retenir côté risque : le risque est maximal sous Apache mod_php, où une seule requête suffit à déclencher l’attaque avant même l’exécution du code applicatif. PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont également concernés
Et ce n’est pas anodin : PHP fait tourner environ 69 % des sites dont le langage serveur est identifié
Mesures temporaires si le patch est impossible immédiatement (rappel : aucune ne suffit) :
session.upload_progress.enabled = Off(dans php.ini ou le pool FPM, jamais viaini_set()ou.user.ini)- Blocage des requêtes multipare en amont (nginx/Apache, sur tous les verbs HTTP)
memory_limit = -1imposé côté serveur (php_admin_valueFPM / config Apache), en acceptant la perte de cette protectionpost_max_sizelimité à 8M (32M si uploads nécessaires)- Redémarrage de tous les processus PHP après chaque modification
Lien vers le site de l’éditeur
GitLab : CVE-2026-110264, le 10/10 dans le compilateur de regex
Le même jour, GitLab a publié un avis corrigant plusieurs vulnérabilités dont CVE-2026-110264 — un dépassement d’entier dans le compilateur d’expressions régulières, scoré 10/10 CVSS, permettant à un utilisateur non authentifié d’exécuter du code arbitraire sur le serveur
Périmètre : toutes les versions de GitLab CE/EE de la 7.0 à la 19.5 — soit plus de dix ans de versions, toutes vulnérables. Correctifs : 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 et 19.5.1
Le contexte rend l’affaire plus sensible : le 12 octobre, GitLab avait déjà corrigé CVE-2026-97229, un dépassement d’entier quasi identique dans le même composant (compilateur de regex CI/CD), lui aussi en RCE non authentifié, lui aussi à 10/10
Deux 10/10 dans le même sous-système en dix jours — les instances self-managed exposées sur Internet sont clairement dans la ligne de mire.
Pourquoi c’est critique : un serveur GitLab centralise le code source, les secrets CI/CD, les clés de déploiement. Sa compromission expose toute la chaîne de supply chain de l’organisation
Action immédiate : GitLab a publié deux règles de détection pour identifier les tentatives d’exploitation — à intégrer dès maintenant dans votre SIEM, et à exécuter avant de considérer quoi que ce soit comme propre : patcher ne remédie pas à une compromission antérieure.
Lien vers le site de l’éditeur
Node2Shell : le décodeur Brotli, bombe à fragmentation
Node.js a publié le 21 octobre les versions 22.23.4, 24.22.1 et 26.12.1, corrigeant 10 vulnérabilités
La tête d’affiche : CVE-2026-111497, surnommée Node2Shell (puis HTTP2Shell) — une écriture hors limites dans le décodeur Brotli intégré, scorée 9,2 CVSS 4.0 par Google, et menant à de la RCE
Le mécanisme est vicieux : un bloc invalide est signalé comme « besoin temporaire de plus d’entrée » au lieu d’une erreur définitive ; le décodeur en streaming continue d’empiler des octets dans un buffer interne de huit octets. Toute application qui décompresse des données Brotli via node:zlib — y compris implicitement — est à risque
Le chercheur Ron Masas affirme avoir reproduit une RCE pré-authentification : sur un runtime vulnérable, app.use(express.json()) suffirait, une simple requête avec Content-Encoding: br passant par le décodeur avant même l’exécution de vos routes
La faille déborde de Node.js : le bug est dans la bibliothèque Brotli de Google (versions 1.0.3 à 1.2.0), corrigée en 1.0.10, 1.1.1 et 1.2.1. Bun (< 1.4.4), le paquet PyPI Brotli et les distributions Linux embarquant Brotli sont concernés
Le reste du lot n’est pas négligeable, surtout les contournements de validation de certificats TLS :
- CVE-2026-105482 (haute) :
dns.resolve*()tronque les noms contenant un octet NUL —attacker.example\0.trusted.examplerésoutattacker.example, contournant vos allowlists de domaines - CVE-2026-105483 / CVE-2026-106069 (hautes) :
tls.checkServerIdentity()accepte des certificats pour des IP écrites en chiffres fullwidth (１２７.0.0.1) ou en notation non canonique (0127.0.0.1, lue en octal par WHATWG mais en décimal par le résolveur) — la certificatisation IP redevient un sujet
La release met aussi à jour le magasin de certificats racines suite au compromis eMudhra (clés intermédiaires compromises, bloquées par Mozilla/Google/Apple du 17 au 19 octobre)
Tableau récapitulatif
| Produit | CVE | Type | CVSS | Versions corrigées |
|---|
| PHP | CVE-2026-109618 / 109619 | RCE non auth (OOM + UAF) | 9,2 | 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 |
| GitLab CE/EE | CVE-2026-110264 | RCE non auth (integer overflow regex) | 10 | 18.11.13 → 19.5.1 selon branche |
| Node.js | CVE-2026-111497 | RCE (OOB write Brotli) | 9,2 | 22.23.4 / 24.22.1 / 26.12.1 |
| Node.js | CVE-2026-105482 | Contournement DNS (NUL byte) | Haute | idem |
| Node.js | CVE-2026-105483 / 106069 | Contournement validation TLS IP | Haute | idem |
Plan d’action pour le sysadmin pressé
- PHP : mettre à jour en priorité tout hébergement mutualisé/mod_php. Vérifier auprès de l’hébergeur que le correctif est bien déployé — afficher
phpinfo()ne suffit pas si le fournisseur rétroporte. - GitLab : patcher les instances self-managed exposées sur Internet avant toute autre chose, puis jouer les règles de détection GitLab sur les logs des 30 derniers jours.
- Node.js : identifier les services décompressant du Brotli (express, proxies, workers de fetching). Puis auditer les sorties TLS vers des ressources configurées en IP — vulnérabilité combinée 106069/106072 — et préférer les noms DNS en attendant le patch.
- Brotli hors Node : scanner le parc pour les binaires/libs Brotli 1.0.3–1.2.0 (Bun, Python, paquets système).
- Hunting : ces trois failles ont fait l’objet de fuites/divulgations anticipées (PHP2Shell a fuité sur Hacker News la veille du patch ). Ne pars pas du principe que tu es arrivée avant l’attaquant : cherche les processus enfants anormaux de php-fpm/apache/node et les connexions sortantes inédites.
Conclusion
Trois écosystèmes, trois RCE non authentifiées, une seule leçon : la surface d’attaque ne se résume pas au code applicatif. Moteurs de langage, décodeurs de compression, compilateurs de regex — les couches basses sont devenues la cible privilégiée, et cette semaine le montre de façon spectaculaire. Si ton parc n’est pas patché au moment où tu lis ces lignes, tu sais quoi faire ce soir.