Incidents de sécurité d'octobre 2026 : PHP2Shell, eMudhra et LiteLLM

Entre le 17 et le 21 octobre 2026, quatre incidents de sécurité ont touché des logiciels sur lesquels repose une grande partie d’internet :

deux failles critiques d’exécution de code à distance dans PHP (« PHP2Shell »)
des clés compromises chez l’autorité de certification eMudhra
une série de correctifs de sécurité pour Node.js
une version piégée de la bibliothèque d’IA Python LiteLLM

En bref pour les clients de Safina : Safina n’utilise ni PHP ni LiteLLM. Nous avons vérifié chaque alerte dès sa publication et mis à jour les dépendances concernées. Vous n’avez rien à faire dans votre compte Safina. Comment nous avons réagi · Ce que vous devriez vérifier vous-même

Dernière mise à jour : 22 octobre 2026. Nous compléterons cet article dès que de nouvelles informations seront disponibles.

Les incidents d’octobre 2026 en un coup d’œil

Incident	Ce qui est concerné	Correctif
PHP2Shell 21 octobre · critique	Toute installation PHP qui répond à des requêtes web	PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35
Certificats intermédiaires d’eMudhra 17 octobre · faux certificats possibles	Les logiciels qui font confiance à la racine « emSign ECC Root CA - G3 »	Navigateurs et listes de certificats à jour, nouveaux certificats pour les sites concernés
Correctifs de sécurité Node.js 21 octobre · 4 failles de gravité élevée	Node.js 22.x, 24.x et 26.x	Node.js 22.23.4, 24.22.1 ou 26.12.1
LiteLLM 1.107.0 21 octobre · vol d’identifiants et porte dérobée	Les systèmes qui ont installé LiteLLM 1.107.0 depuis PyPI ou récupéré ses images Docker	LiteLLM 1.106.2, renouvellement de tous les identifiants

PHP2Shell : une faille critique d’exécution de code dans PHP

PHP2Shell désigne deux vulnérabilités critiques de l’interpréteur PHP, CVE-2026-109618 et CVE-2026-109619. Toutes deux permettent à un attaquant d’exécuter du code sur un serveur avec une seule requête web non authentifiée, avant même que le code de l’application ne démarre. L’équipe PHP les note 9,2 sur l’échelle CVSS 4.0 et a publié les correctifs le 21 octobre 2026.

PHP fait tourner WordPress, de nombreuses boutiques en ligne, des plugins de réservation et les interfaces d’administration des hébergeurs. PHP2Shell fait donc partie des failles les plus étendues depuis des années. Le chercheur en sécurité Kevin Beaumont a déclaré à Help Net Security : « La situation de PHP va provoquer une masse d’incidents. C’est l’une des plus grosses vulnérabilités depuis des années. »

Ce qui est concerné : selon Help Net Security, toute configuration PHP qui répond à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Selon Tenable, le code vulnérable remonte à PHP 5.4.

Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 7.4 à 8.1 ne reçoivent pas de version officielle, seulement des correctifs minimaux du code source.

Chronologie : les identifiants CVE ont fuité le 20 octobre. La PHP Foundation a alors avancé la publication d’un jour, du 22 au 21 octobre, rapporte Tenable. Amazon Threat Intelligence a observé une première tentative d’attaque dès le 17 octobre, quatre jours avant le correctif, et signale depuis des attaques à grande échelle. L’agence américaine CISA n’avait pas encore observé d’attaque au moment de son alerte, mais recommande de déconnecter les systèmes PHP non corrigés, ainsi que tous ceux qui tournent sous PHP 8.1 ou plus ancien.

Cloudflare a ajouté des règles de pare-feu contre les schémas d’attaque connus, y compris pour les offres gratuites. Cloudflare parle elle-même d’une solution provisoire : seule la mise à jour corrige la faille.

Situation au 22 octobre : après la publication, des entreprises de sécurité comme watchTowr et Patchstack ont signalé des tentatives d’attaque actives. Selon CyberScoop, Huntress n’avait confirmé aucune attaque réussie sur des systèmes clients. CyberScoop estime que plus de 1,3 million de serveurs accessibles depuis Internet pourraient être vulnérables. La CISA n’a pas encore ajouté les deux failles à son catalogue des vulnérabilités exploitées.

eMudhra : les clés d’une autorité de certification compromises

Les autorités de certification (CA) émettent les certificats qui donnent son sens au cadenas du navigateur. Le 17 octobre 2026, un chercheur a signalé que les clés privées de huit certificats intermédiaires de l’autorité indienne eMudhra avaient été générées avec un aléa trop faible. N’importe qui aurait pu calculer ces clés et émettre, pour n’importe quel site, des certificats auxquels navigateurs et applications feraient confiance.

La réaction a été rapide. Selon Google, Chrome a bloqué les certificats intermédiaires concernés moins de deux heures après le signalement, sans mise à jour du navigateur. Les appareils Android ont reçu le blocage le 19 octobre via les services Google Play. Google n’a trouvé aucun certificat de ces CA dans les journaux publics Certificate Transparency avant le blocage. Mozilla a retiré la racine « emSign ECC Root CA - G3 » de la liste de confiance de Firefox (bug Mozilla 2083449), et Chrome la retire le 27 octobre 2026. Firefox a aussi bloqué les certificats intermédiaires le 17 octobre, Apple a suivi le 19 et Microsoft le 20 octobre (CyberInsider). eMudhra attribue les clés faibles à un script défectueux lors de la génération des clés et n’émet plus de certificats sous la racine G3.

Le plus difficile concerne les logiciels hors navigateur. Serveurs, conteneurs et langages de programmation embarquent souvent leur propre liste de CA de confiance, et la plupart ne savent pas bloquer un certificat intermédiaire précis. Il leur faut une mise à jour qui retire toute la racine. Le paquet Python certifi, par exemple, ne la contient plus depuis la version 2026.10.18, et l’avis indique la 2026.10.19 comme version corrigée (avis GitHub). Deux des huit certificats intermédiaires servaient à signer des logiciels : le risque ne se limite donc pas aux sites web.

Correctifs de sécurité Node.js d’octobre 2026

Le 21 octobre 2026, le projet Node.js a publié des correctifs de sécurité pour toutes les versions maintenues : 22.23.4, 24.22.1 et 26.12.1. Ils corrigent 10 vulnérabilités, dont 4 de gravité élevée :

deux façons de contourner la vérification TLS du nom d’hôte avec des notations inhabituelles d’adresses IP
une écriture hors limites dans le décodeur Brotli, qui peut permettre une exécution de code à distance
une faille de dns.resolve qui tronque les noms d’hôte à un caractère NUL

Ces mêmes versions retirent aussi la racine compromise d’eMudhra de la liste de certificats fournie avec Node.js. Les versions en fin de vie, comme Node.js 20, sont également touchées et ne reçoivent pas de correctif.

LiteLLM 1.107.0 : une attaque sur la chaîne d’approvisionnement d’une bibliothèque d’IA

LiteLLM est une bibliothèque Python très répandue qui relie des applications à de nombreux fournisseurs de modèles d’IA. Le 21 octobre 2026, des attaquants ont publié la version 1.107.0 sur PyPI et dans les images Docker du projet (tags v1.107.0, latest, main-latest et main-stable). Cette version contenait un voleur d’identifiants et une porte dérobée.

D’après Datadog Security Labs, la version malveillante est restée disponible environ deux heures. Ses fichiers s’exécutent à chaque démarrage de Python, même si LiteLLM n’est jamais importé, et restent sur le système après une désinstallation. Le code malveillant récupérait des clés cloud, des clés d’API de fournisseurs d’IA, des clés SSH et les mots de passe enregistrés dans le navigateur. Chainguard y voit la deuxième compromission de LiteLLM en sept mois.

D’après le rapport d’incident de LiteLLM, les attaquants ont utilisé des identifiants GitHub volés à des comptes de développeurs et ont redirigé le processus de publication vers un dépôt au nom presque identique. Le code source du dépôt officiel ne contenait pas les fichiers malveillants. Le paquet est resté sur PyPI de 11 h 39 à environ 13 h 23 UTC, et les tags Docker ont pointé vers l’image malveillante jusqu’à 14 h 20 UTC. Les clients de la version privée Enterprise n’ont pas été touchés.

La dernière version sûre est la 1.106.2. Toute personne ayant installé la 1.107.0 doit considérer le système comme compromis, supprimer les fichiers injectés et renouveler, depuis une machine saine, tous les identifiants auxquels le système avait accès.

Comment Safina a réagi

Safina répond aux appels de votre entreprise : les systèmes qui la font fonctionner doivent donc être à la fois disponibles et sûrs. La sécurité est une priorité pour nous, et la surveillance automatique de la sécurité fait depuis toujours partie du fonctionnement de Safina. Voici comment elle a joué lors de ces incidents :

Surveillance automatique. Notre code, nos dépendances et nos images de conteneurs sont analysés automatiquement. Lorsqu’un avis de sécurité concerne un composant que nous utilisons, nous recevons une alerte et une proposition de mise à jour, sans attendre que quelqu’un lise l’actualité.
Vérification dès la publication. Pour chacun des quatre incidents, nous avons vérifié dès sa publication si et où Safina utilise le logiciel concerné.
Mises à jour. Nous avons passé nos services sur les versions corrigées de Node.js et mis à jour les listes de certificats de confiance de nos services.
Pas utilisé chez nous. Safina n’exécute pas PHP et n’utilise pas LiteLLM. Notre vérification de l’ensemble du code et des dépendances l’a confirmé.

Vous n’avez rien à faire dans votre compte Safina. Les mises à jour se font de notre côté. Pour en savoir plus sur la façon dont nous traitons vos données, consultez notre présentation de la confidentialité et de la conformité et notre article sur le RGPD et les assistants téléphoniques IA.

Ce que les petites entreprises doivent vérifier maintenant

Vous n’administrez sans doute pas vos propres serveurs. Mais votre site, votre boutique en ligne ou votre outil de réservation tournent peut-être sous PHP. Ces cinq vérifications couvrent les cas les plus courants :

Demandez à votre hébergeur ou à votre agence si votre site utilise une version de PHP corrigée (8.5.12, 8.4.27, 8.3.36 ou 8.2.35). Cela concerne la plupart des sites WordPress.
Prévoyez de quitter PHP 8.1 ou plus ancien. Ces versions ne reçoivent pas de correctif officiel. La CISA recommande de déconnecter ces systèmes.
Mettez à jour navigateurs, smartphones et ordinateurs. Chrome, Firefox, Android et les appareils Apple et Microsoft bloquent les certificats d’eMudhra via leurs mises à jour habituelles.
Vérifiez l’émetteur de votre certificat si votre propre site utilise un certificat d’eMudhra (emSign). Chrome cesse de faire confiance à la racine « emSign ECC Root CA - G3 » le 27 octobre 2026. Obtenez avant cette date un nouveau certificat auprès d’une autre CA.
Interrogez votre prestataire informatique sur LiteLLM si vous utilisez vos propres outils d’IA. Si la version 1.107.0 a été installée, il faut nettoyer le système et remplacer toutes les clés qu’il contenait.

Pourquoi l’IA rend les mises à jour rapides encore plus importantes

Les chercheurs de Wiz ont expliqué à propos de PHP2Shell que les modèles d’IA de pointe avaient nettement abaissé la barrière et transformé une faille ancienne en attaque fonctionnelle (Help Net Security). Les modèles d’IA aident désormais les défenseurs à trouver de vieux bugs, comme Anthropic l’a montré avec Claude Mythos et Project Glasswing. Les mêmes outils aident les attaquants à transformer plus vite un correctif publié en attaque.

Le délai entre la publication et les premières attaques ne cesse de raccourcir. Avec PHP2Shell, les premières tentatives sont arrivées avant même le correctif. Pour un éditeur de logiciels, la surveillance automatique et les mises à jour rapides ne sont plus un bonus. Elles sont le minimum.

Questions fréquentes

Safina est-elle concernée par PHP2Shell ?

Non. Safina n’exécute pas PHP. Notre site, nos applications et nos services backend reposent sur d’autres technologies. Nous l’avons vérifié dès la publication des vulnérabilités.

Dois-je modifier quelque chose dans Safina ?

Non. Toutes les mises à jour se font de notre côté. Votre assistant, votre numéro de téléphone et vos réglages restent inchangés.

Quelles versions de PHP corrigent PHP2Shell ?

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. PHP 8.1 et les versions plus anciennes ne reçoivent pas de version officielle. Demandez à votre hébergeur quelle version utilise votre site.

Que s’est-il passé chez eMudhra ?

Les clés privées de huit certificats intermédiaires de l’autorité de certification eMudhra ont été générées avec un aléa trop faible. N’importe qui aurait pu s’en servir pour créer des certificats reconnus pour n’importe quel site. Chrome et Firefox les ont bloqués quelques heures après le signalement, Apple et Android deux jours plus tard et Microsoft trois jours plus tard, et la racine « emSign ECC Root CA - G3 » est en cours de retrait des listes de confiance.

Quelle version de LiteLLM est sûre ?

LiteLLM 1.106.2 est la dernière version sûre. La version 1.107.0 du 21 octobre 2026 contenait un voleur d’identifiants. Les systèmes où elle a été installée doivent être nettoyés et recevoir de nouveaux identifiants.

Chronologie

Date (2026)	Événement
17 octobre	Signalement des clés faibles d’eMudhra. Chrome et Firefox bloquent les certificats intermédiaires concernés le soir même. Amazon observe une première tentative d’attaque PHP2Shell.
19 octobre	Apple bloque les certificats intermédiaires d’eMudhra. Android reçoit le blocage via les services Google Play.
20 octobre	Les identifiants CVE de PHP2Shell fuitent. PHP annonce la mise à jour de sécurité pour le lendemain. Microsoft bloque les certificats intermédiaires d’eMudhra.
21 octobre	PHP et Node.js publient leurs correctifs. La version malveillante LiteLLM 1.107.0 est publiée, puis retirée après environ deux heures. La CISA publie son alerte sur PHP. Des entreprises de sécurité signalent les premières tentatives d’attaque après la mise à jour de PHP.
27 octobre	Chrome retire la racine « emSign ECC Root CA - G3 » de sa liste de confiance.