L'actu cyber du jour

vendredi 23 octobre 2026

10 actualités, 33 sources. Chaque information est attribuée à ses sources d'origine : suivez les liens pour en lire le détail.

L'essentiel

PHP2Shell domine la journée, mais pas comme prévu. Deux jours après les correctifs d'urgence, des millions de tentatives d'exploitation ont été enregistrées (Cloudflare), surtout du balayage. Aucune exécution de code réussie n'est confirmée en production au 23 octobre, et la CISA n'a pas classé les failles au catalogue KEV.
Le verrou technique reste l'ASLR. VulnCheck affirme avoir franchi cette protection sur des PHP de production configurés correctement, avec un exploit réservé à ses clients. C'est le signe que la fenêtre de sécurité se referme, même si les attaquants "grand public" échouent encore.
L'exploitation active se déplace vers des cibles plus faciles. Plex2Shell est entré au catalogue KEV avec une échéance fédérale américaine fixée à aujourd'hui, et une troisième zero-day de l'orchestrateur VeloCloud d'Arista est exploitée en quatre mois.
L'IA n'est plus seulement un sujet de défense. Un APT chinois utilise le framework de pentest automatisé Artex pour frapper plus de 2 250 tenants Microsoft 365 à la vitesse de 2 900 tentatives par minute, et une chaîne d'approvisionnement d'IA (LiteLLM) a servi de porte d'entrée vers du LLMjacking.
La dette technique industrielle tue. Une vague d'attaques sur des contrôleurs de réfrigération a touché plus de 700 magasins en Europe, dont environ 700 en France pour la seule nuit concernée, avec des pertes de plusieurs dizaines de millions d'euros chez Intermarché et des équipements en fin de vie depuis 2016 ou 2021.
Confiance cryptographique ébranlée. Huit clés privées d'autorités intermédiaires d'eMudhra étaient récupérables "instantanément" ; le navigateur Chrome cessera de faire confiance à la racine concernée le 27 octobre, et l'entreprise quitte le marché mondial du SSL/TLS.

01CritiqueVulnérabilité

PHP2Shell : des millions de tentatives, zéro compromission confirmée, et un exploit qui contourne l'ASLR

Ce qui s'est passé: Deux failles du moteur PHP permettent à un attaquant sans compte d'exécuter du code via de simples requêtes HTTP, en manipulant la gestion des sessions et la progression d'upload. Elles ont été corrigées en urgence le 21 octobre, un jour avant la date prévue, après la fuite des identifiants CVE. Depuis, les scanners du monde entier testent le web entier : de quelques dizaines de milliers de tentatives dans les 45 minutes suivant l'annonce à plusieurs millions le 22 octobre selon Cloudflare. Une variante de botnet Mirai nommée Potassium a été observée en train d'essayer de s'installer, sans succès.
Ce que ça change: en cas de succès, l'attaquant exécute du code avec les droits du processus web, donc accès aux clés d'API, aux identifiants de bases de données, aux variables d'environnement et aux services internes joignables depuis le serveur. Pas besoin d'être administrateur pour pivoter : un WordPress, un Drupal ou un Joomla avec du code applicatif propre reste exposé puisque le défaut est dans le moteur.
Ce qu'il faut faire: patcher en priorité et inventorier les PHP en fin de vie (7.4, 8.0, 8.1) pour migration ou backport distribution. Si le patch ne peut pas être appliqué immédiatement, désactiver session.upload_progress.enabled (valeur 0), mesure officiellement recommandée par PHP et qui couvre aussi le nouveau CVE-2026-115560. Activer les règles WAF (Cloudflare en a publié), restreindre l'exposition directe des interfaces d'administration, et rechercher des indicateurs d'exploitation dans les logs HTTP : paramètres de session anormaux, requêtes vers des chemins inexistants suivies d'un POST, écriture de fichiers dans les répertoires de session.
Ce qui reste incertain: l'exploit VulnCheck, présenté comme fonctionnel sur x86-64 avec ASLR actif et affichage d'erreurs désactivé, n'est pas public et n'a pas été vérifié indépendamment. Les volumes d'attaques proviennent de déclarations de Cloudflare et d'Amazon, non recoupées par un tiers neutre. Le décompte de 34,4 millions de services PHP encore vulnérables est une estimation Censys. Sophos a corrigé une première version de son analyse qui annonçait une exploitation réussie.

Sources :thehackernews.com securityweek.com krebsonsecurity.com theregister.com

02CritiqueVulnérabilité

Plex2Shell : la CISA ordonne de patcher aujourd'hui, l'exploitation est réelle

Ce qui s'est passé: Quatre défauts de gravité moyenne à élevée se combinent pour former une chaîne critique. Une SSRF non authentifiée dans /player/timeline permet de faire émettre des requêtes POST au serveur Plex vers ses propres API internes. Une injection d'URL dans searchOne permet d'appeler des fonctions d'autres plugins avec des paramètres contrôlés. Une seconde SSRF, authentifiée, existe sur le point d'entrée du transcodeur. Enfin, une écriture de fichier arbitraire dans les réglages du transcodeur permet de déposer une bibliothèque partagée malveillante que Plex charge ensuite. Le tout aboutit au vol du jeton administrateur et à une exécution de code privilégiée.
Ce que ça change: prise de contrôle du serveur Plex, accès à la bibliothèque multimédia, aux comptes liés et au système d'exploitation sous-jacent. Comme ces serveurs sont souvent installés sur des NAS ou des machines domestiques mal segmentées, le rebond vers le réseau local est direct.
Ce qu'il faut faire: mettre à jour vers 1.43.3.10861 ou plus récent sans attendre. Si Plex est exposé sur Internet sans nécessité, fermer le port, désactiver le transcodage distant non utilisé et surveiller les requêtes vers /player/timeline et les endpoints de transcodage. Vérifier la présence de bibliothèques .so ou .dll inattendues dans les répertoires du transcodeur.
Ce qui reste incertain: le nombre de serveurs Plex encore vulnérables (environ 36 000 exposés selon des articles liés) n'est pas daté avec précision dans la source consultée. L'identité des attaquants n'est pas établie.

Sources :bleepingcomputer.com

03CritiqueAttaque

Réfrigérateurs détournés en radiateurs : plus de 700 magasins européens touchés

Ce qui s'est passé: Dans la nuit, des attaquants ont pris le contrôle de contrôleurs de froid commercial et fait monter la température de réfrigérateurs, congélateurs et chambres froides jusqu'à 50 degrés Celsius, détruisant les denrées et provoquant quelques petits départs de feu. Pour retarder la détection, ils auraient allongé les cycles de dégivrage afin que la montée en température ressemble à une maintenance de routine. Plus de 700 magasins auraient été touchés la même nuit ; l'Espagne, le Portugal, la Pologne, l'Allemagne et la Belgique sont cités, et une enseigne néerlandaise a coupé ses systèmes par précaution. Intermarché évoque plusieurs dizaines de millions d'euros de pertes.
Ce que ça change: destruction physique de stocks alimentaires, pertes d'exploitation, risque incendie, et atteinte à la chaîne du froid donc à la sécurité sanitaire. C'est un exemple rare où une cyberattaque produit un dommage matériel mesurable sans passer par un rançongiciel.
Ce qu'il faut faire: sortir immédiatement les contrôleurs de réfrigération d'Internet, segmenter l'OT dans un VLAN dédié, n'autoriser l'accès distant que via une passerelle avec authentification forte et liste d'adresses, journaliser les changements de consigne et les cycles de dégivrage, et exiger des prestataires de maintenance la liste de leurs accès. Un scan Shodan cité dans l'article recensait environ 1 500 systèmes Danfoss exposés en France.
Ce qui reste incertain: le décompte exact de magasins, la date précise de la vague et le montant total des pertes ne sont pas consolidés. La responsabilité de Danfoss est contestée par l'entreprise, qui renvoie à l'obsolescence des firmware. Le lien avec des pannes survenues fin août dans des cantines militaires américaines n'est pas établi. L'article français de Dark Reading est une traduction automatique, ce qui peut décaler certaines formulations temporelles.

Sources :darkreading.com cnbc.com

04CritiqueIA & Sécurité

Un APT chinois industrialise ses attaques avec un outil de pentest IA

Ce qui s'est passé: Le groupe lié à la Chine, actif depuis 2021, a utilisé le framework open source de pentest automatisé Artex pour accélérer reconnaissance, pulvérisation de mots de passe et abus d'applications OAuth. Microsoft rapporte plus de 300 comptes visés dans huit organisations, 2 250 tentatives de connexion à des tenants, et plus de 151 000 échecs d'authentification, le tout à plus de 2 900 tentatives par minute. Dans certains environnements, l'agent IA a dépassé la simple authentification pour atteindre Microsoft Graph, faire de la reconnaissance, modifier des identifiants applicatifs pour se maintenir et toucher aux rôles privilégiés.
Ce que ça change: accès persistant à des tenants Microsoft 365 entiers, y compris après remédiation de l'application compromise, puisque l'attaquant modifie les identifiants de l'application pour se recréer un accès. Capacité de lecture de courriels, de données métier et de gestion d'identités.
Ce qu'il faut faire: auditer les connexions de principaux de service et l'activité Graph qui les suit, corréler avec les actions administratives légitimes, révoquer et faire tourner tous les secrets applicatifs liés à des fournisseurs tiers, appliquer le moindre privilège sur les consentements OAuth, et bloquer ou signaler les authentifications non interactives inhabituelles. La vitesse d'attaque rend la détection manuelle inopérante : il faut des règles automatisées sur les volumes et les changements de credentials d'application.
Ce qui reste incertain: Microsoft ne précise pas combien d'organisations ont été réellement compromises au-delà des tentatives. Le lien entre Artex et un gain opérationnel mesurable repose sur l'analyse de Microsoft et de Zscaler, pas sur une démonstration indépendante. Aucune attribution nominative officielle au-delà du cluster Storm-0940.

Sources :securityweek.com darkreading.com

05CritiqueVulnérabilité

Arista VeloCloud : troisième zero-day exploitée en quatre mois

Ce qui s'est passé: Une injection SQL critique dans l'orchestrateur SD-WAN permet à un utilisateur authentifié disposant du rôle le plus faible (Enterprise Read Only) d'obtenir les privilèges d'opérateur, soit le niveau de contrôle maximal. Contrairement aux deux zero-days précédentes de la même famille, celle-ci exige une connexion valide, ce qui suppose des identifiants obtenus en amont. L'interface web du VCO est exposée par défaut et aucun réglage ne permet de la masquer.
Ce que ça change: prise de contrôle de l'orchestrateur, donc des politiques réseau de l'ensemble du parc SD-WAN : redirection de trafic, modification de règles, perturbation des sites, et potentiellement atteinte à l'hôte lui-même. Un orchestrateur compromis peut servir de tremplin vers les équipements Edge.
Ce qu'il faut faire: mettre à jour vers les versions corrigées, restreindre l'accès à l'interface VCO à des réseaux d'administration de confiance, rechercher dans les logs web des composants de chemin d'URL anormaux, des caractères encodés et des requêtes vers des services internes, et vérifier les activités administratives récentes. En cas de suspicion, préserver les journaux avant toute remédiation.
Ce qui reste incertain: Arista ne précise ni la date de début des attaques, ni les orchestrateurs touchés, ni les actions menées après exploitation. On ignore si la mise à jour retire un accès déjà obtenu.

Sources :thehackernews.com bleepingcomputer.com

06CritiqueSupply Chain

LiteLLM : la chaîne de publication compromise, un voleur d'identifiants dans PyPI et Docker

Ce qui s'est passé: Des attaquants ont repris la publication du paquet en exploitant trois jeux d'identifiants GitHub CLI de développeurs, dont un capable de lancer des workflows. Avec un jeton de propriétaire d'organisation, ils ont désactivé les protections de branche, forcé un push, puis fait signer et publier des artefacts via un dépôt sosie (Berri-AI/litellm au lieu de BerriAI/litellm). Le code malveillant repose sur un fichier .pth et un sitecustomize.py, deux mécanismes que Python exécute à chaque démarrage : la charge se déclenche donc même si l'application n'utilise pas LiteLLM. Elle collecte secrets système, navigateur, développeur, cloud et outils d'IA, les envoie à litellm[.]dev/healthcheck, puis installe un démon qui récupère un domaine de commande et contrôle toutes les heures.
Ce que ça change: vol en masse de clés cloud et d'API, puis, selon Wiz, validation des identifiants de rôle d'instance AWS et appels bedrock:ListFoundationModels, signature classique de LLMjacking, c'est-à-dire d'un usage détourné de la facturation de modèles. Une seule installation compromise suffit à permettre la publication de code malveillant en aval.
Ce qu'il faut faire: retirer LiteLLM 1.107.0, isoler les hôtes concernés, chercher cook.pth, cook.py et sitecustomize.py dans les environnements Python, bloquer le domaine d'exfiltration, puis faire tourner tous les identifiants joignables depuis ces hôtes. Épingler les images et paquets par digest et non par tag, et vérifier les artefacts avant qu'ils n'atteignent la CI. Le point d'entrée initial serait un déploiement LiteLLM interne exposé sur Internet, dont les journaux contenaient des jetons OAuth GitHub injectés par Claude Code dans des corps de réponse.
Ce qui reste incertain: le mode exact d'accès au déploiement exposé n'est pas établi, LiteLLM évoque une vulnérabilité récemment corrigée sans la nommer. Le lien avec l'attaque de mars 2026 (TeamPCP) est explicitement non démontré selon Socket. L'ampleur réelle des vols de clés n'est pas quantifiée.

Sources :thehackernews.com securityweek.com helpnetsecurity.com

07CritiqueCryptographie

eMudhra : huit clés privées d'autorités intermédiaires récupérables, sortie du marché SSL/TLS

Ce qui s'est passé: Chaque clé privée aurait dû être un très grand nombre aléatoire. Les huit en question étaient inférieures à 256, donc calculables presque instantanément. Le chercheur a alerté Apple, Google, Microsoft, Mozilla et eMudhra le 17 octobre. Mozilla a retiré sa confiance à la racine le 20 octobre, Chrome suivra le 27 octobre au matin, heure du Pacifique. eMudhra a décidé en conseil de quitter son activité mondiale de certificats SSL/TLS, qui représente environ 1 % de son chiffre d'affaires. Environ 30 000 certificats doivent être migrés, dont 97 % émis via ACME, et la quasi-totalité via le service InCommon destiné à l'enseignement supérieur.
Ce que ça change: pour les sites encore rattachés à la racine ECC, avertissement de sécurité ou blocage complet dans Chrome et Firefox à partir du 27 octobre, donc indisponibilité de services en ligne. Le risque de falsification de certificats reste théorique faute d'usage observé, mais la confiance dans l'opérateur est rompue.
Ce qu'il faut faire: inventorier tous les certificats de son parc chaînés à eMudhra, demander un remplacement hors fenêtre de renouvellement habituelle, et anticiper le fait que les clients ACME standards ne remplacent pas un certificat avant son échéance sauf support d'ACME Renewal Information. Vérifier également les configurations épinglant cette racine. Pour les hébergeurs et les universités, la migration vers une autre autorité est la seule option durable.
Ce qui reste incertain: eMudhra affirme que ses systèmes n'ont pas été compromis et que les clés faibles n'ont jamais servi à émettre des certificats, ce qui n'est pas vérifiable de l'extérieur. Une liste de révocation publiée le 14 octobre porte une signature qui ne correspond pas à la clé de l'autorité concernée ; un participant au rapport de bug évoque une erreur de clé de signature, pas une nouvelle clé faible. Chrome a posé 12 questions publiques restées sans réponse à la date du briefing.

Sources :thehackernews.com bleepingcomputer.com darkreading.com

08ÉlevéeAttaque

Microsoft 365 : 79 organisations compromises sans aucun mot de passe

Ce qui s'est passé: L'attaquant a récupéré des jetons de session déjà validés, principalement via des pages de connexion falsifiées relayant la vraie page Microsoft et le défi MFA (attaque de type adversary-in-the-middle), mais aussi par hameçonnage par code d'appareil. Le jeton étant créé après le MFA, quiconque le détient n'a plus besoin de MFA. Les jetons ont ensuite été rejoués en masse, une pratique que Huntress nomme "token spraying". Dans 19 organisations, les méthodes MFA existantes ont été effacées et une nouvelle enregistrée dans les trois heures suivant la première connexion, parfois une application d'authentification nommée "iPhone 13".
Ce que ça change: lecture et manipulation de boîtes mail, règles de boîte cachées supprimant ou masquant certains messages, et tentative de fraude à la paie documentée. Au moins 48 ordinateurs factices nommés DESKTOP- suivi de huit caractères hexadécimaux ont été enregistrés dans les annuaires pour maintenir l'accès.
Ce qu'il faut faire: révoquer les sessions et non seulement réinitialiser les mots de passe, auditer les méthodes d'authentification enregistrées et les appareils, examiner les règles de boîte aux lettres créées récemment (noms courts du type ".", "sss", "iT"), et déployer des politiques d'accès conditionnel. Dans cette campagne, les politiques d'accès conditionnel ont bloqué 1 052 tentatives venues de quatre organisations seulement : c'est le principal levier disponible.
Ce qui reste incertain: le nombre exact de victimes finales et l'identité de l'attaquant ne sont pas établis. Le fournisseur d'hébergement cité (1337 Services GmbH, Hambourg) est un point d'infrastructure, pas nécessairement un acteur complice.

Sources :helpnetsecurity.com

09ÉlevéeVulnérabilité

GitLab : une faille d'exécution de code à distance de sévérité maximale

Ce qui s'est passé: Un débordement d'entier dans le compilateur d'expressions régulières de GitLab permet à un utilisateur non authentifié d'exécuter du code arbitraire sur le serveur en soumettant une expression régulière spécialement construite. Le défaut touche une très large plage de versions, décrite par The Register comme couvrant douze ans de publications. C'est la troisième faille de sévérité maximale corrigée par l'éditeur en quelques semaines, après un score CVSS 10 signalé dix jours plus tôt et une traversée de répertoire ajoutée au catalogue KEV en septembre.
Ce que ça change: compromission complète du serveur GitLab, donc accès à l'ensemble des dépôts, jetons de CI/CD, secrets de déploiement et artefacts. Pour une organisation, c'est un accès direct à la chaîne de production.
Ce qu'il faut faire: mettre à jour immédiatement, en particulier si l'instance est exposée sur Internet. À défaut, restreindre l'accès réseau à l'instance, surveiller les requêtes anormales vers les endpoints de validation d'expressions régulières et les processus inattendus lancés par le service web. Vérifier les secrets stockés dans les variables CI/CD après tout doute de compromission.
Ce qui reste incertain: l'absence de score CVSS chiffré et de preuve de concept publique ne garantit pas l'absence d'exploit privé. Le nombre exact d'instances vulnérables n'est pas connu, Shadowserver ne distinguant pas les honeypots ni les instances déjà corrigées.

Sources :bleepingcomputer.com theregister.com

10ÉlevéeVulnérabilité

Pillow : le nom de fichier suffit à exécuter des commandes sur le serveur

Ce qui s'est passé: Pillow ouvre les images EPS en passant leur nom de fichier à Ghostscript, sans vérifier ce nom. Ghostscript peut alors interpréter ce nom comme des instructions et aller chercher un second fichier contenant des commandes à exécuter. Le défaut vient donc du nom de fichier, pas du contenu de l'image : un fichier EPS parfaitement bénin peut déclencher l'attaque si l'attaquant contrôle son nom. La faille ne se déclenche que si le programme gs est installé sur l'hôte. La bibliothèque est massivement présente dans les formulaires d'upload, les générateurs de vignettes, les pipelines PDF et la plupart des projets de machine learning, avec environ 436 millions de téléchargements par mois selon OX Security.
Ce que ça change: exécution de commandes avec les droits du service web, donc compromission du serveur applicatif. Les cibles réalistes sont les endpoints d'upload qui conservent ou construisent le nom du fichier stocké à partir d'une entrée utilisateur.
Ce qu'il faut faire: passer à Pillow 13.0.0 et reconstruire les conteneurs, wheels et images de base qui embarquent une version antérieure. À défaut : ne pas installer Ghostscript sur les hôtes qui traitent des uploads non fiables, ne jamais transmettre un nom de fichier contrôlé par l'utilisateur à Image.open() pour du EPS, appeler load() avant thumbnail() sur des JPEG non fiables, et traiter l'enregistrement TIFF en mémoire comme une opération sensible. Renommer systématiquement les fichiers entrants avec un identifiant généré côté serveur reste la mesure de fond.
Ce qui reste incertain: les scores CVE de 9.2 reposent sur des conditions que le score ne capture pas, d'où l'écart avec l'évaluation des mainteneurs. La faille TIFF n'a été transformée en exécution de code qu'avec l'aide d'une seconde faille de fuite mémoire. La découverte de CVE-2026-112403 est attribuée à Anthropic via Claude, avec validation manuelle par Ada Logics.

Sources :thehackernews.com

Tous les jours du radar