L'actu cyber du jour

samedi 24 octobre 2026

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

Lecture : 15 min

L'essentiel

Deux failles critiques sont désormais exploitées dans le monde réel et inscrites au catalogue KEV de la CISA : l'injection SQL de l'orchestrateur Arista VeloCloud (CVSS 9.9) et l'injection de commandes de l'application Collabora Online pour Nextcloud. Échéance fédérale américaine : 26 octobre 2026.
La chaîne d'approvisionnement logicielle reste le vecteur le plus rentable : la version 1.107.0 du paquet Python LiteLLM a été publiée avec un voleur d'identifiants et une porte dérobée, après l'exploitation d'une clé maître restée valide depuis mai. L'incident touche directement les piles d'IA d'entreprise.
PHP2Shell (CVE-2026-109618 et CVE-2026-109619) est passé en exploitation de masse : des millions de tentatives, des opérateurs Mirai à l'affût, mais toujours pas d'exécution de code confirmée à grande échelle. Un troisième défaut, non corrigé, est apparu deux jours après les correctifs d'urgence.
L'IA devient une couche d'attaque à part entière : agents autonomes pilotés par des affiliés ransomware (framework Phantom), modèles exposés détournés pour attaquer des tiers (LLMjacking), et SDK de paiement pour agents (x402) qui pouvaient vider un portefeuille.
Côté conformité, l'exposition de données reste massive et banale : 11,7 millions de comptes Capcom ID, secrets d'environnement chez Railway, 70 000 identifiants d'équipements de bordure revendus ou réutilisés.
Tendance dominante de la journée : la périphérie réseau (SD-WAN, pare-feu, VPN, RMM) et les infrastructures d'IA sont désormais les deux ports d'entrée privilégiés, et les correctifs existent presque toujours avant l'exploitation.

01 / 10CritiqueVulnérabilité

Arista VeloCloud : troisième zero-day de l'orchestrateur exploité en quatre mois

Concerné: Arista VeloCloud Orchestrator (VCO), trains 5.2, 6.1 et 6.4. Les passerelles et les équipements Edge VeloCloud ne sont pas affectés, le train 7.0 n'est pas listé.
Correctif: Oui, VCO 5.2.3.18, 6.1.3.10 et 6.4.2.12 pour les déploiements sur site. Les offres Hosted et Dedicated ont déjà été corrigées.

Ce qui s'est passé: VeloCloud Orchestrator est la console centrale qui pilote un réseau SD-WAN d'entreprise : elle configure les sites, les tunnels et les politiques de trafic. Une injection SQL dans son interface web permet à un utilisateur authentifié, même avec le rôle le plus bas (Enterprise Read Only), de devenir superutilisateur local de l'orchestrateur. Il suffit d'un accès réseau à l'interface web et d'un compte valide, par exemple un compte client ou partenaire légitime, ou un compte obtenu par phishing.
Ce que ça change: Prise de contrôle de la console qui administre tout le réseau étendu, donc capacité de réécrire les routes, d'intercepter ou de détourner du trafic, de désactiver des protections, et, selon les avis précédents d'Arista sur le même produit, d'atteindre les équipements Edge. L'attaquant peut aussi exposer ou modifier les données gérées par l'orchestrateur.
Ce qu'il faut faire: Mettre à jour vers les versions corrigées sans attendre l'échéance KEV du 26 octobre 2026 ; restreindre l'interface web du VCO à un segment d'administration ou à une liste d'IP ; rechercher dans les journaux d'accès web les requêtes à composants de chemin inhabituels, caractères encodés, références à des services internes et pics de requêtes ; conserver les journaux web, applicatifs, système et base de données avant toute remédiation en cas de suspicion.
Ce qui reste incertain: Arista ne précise pas la date de début des attaques, le nombre d'organisations touchées, ni les actions menées après l'escalade. On ne sait pas si la mise à jour révoque un accès déjà obtenu.

Sources :thehackernews.com thehackernews.com securityweek.com

02 / 10CritiqueVulnérabilité

Nextcloud : des serveurs backdoorés via l'application Collabora intégrée

Concerné: Application Nextcloud « Collabora Online - Built-in CODE Server » (paquet richdocumentscode), toutes versions antérieures à 26.4.303. Les serveurs Collabora Online autonomes ne sont pas affectés.
Correctif: Oui, version 26.4.303 (11 septembre 2026), qui exige Nextcloud 30 ou ultérieur. La version 26.4.402, censée réécrire la commande de démarrage, provoque des incidents de démarrage selon des administrateurs.

Ce qui s'est passé: Cette application optionnelle installe un serveur de documents Collabora directement sur le serveur Nextcloud, pour éditer des fichiers sans infrastructure séparée. Son script proxy.php insérait le chemin de la requête HTTP dans une commande bash entre guillemets doubles, où la séquence $(...) est interprétée par le shell. Une requête non authentifiée pouvait donc exécuter une commande avec les droits du compte web, mais uniquement au moment où le serveur de documents local était arrêté (redémarrage, mise à jour, plantage).
Ce que ça change: Dépôt d'un web shell PHP d'une ligne, puis recherche de coffres de mots de passe et de portefeuilles de cryptomonnaies (fichiers .kdbx, wallet.dat, keystore.json, dossiers Bitwarden, 1Password, Electrum, Monero, Ethereum). Tout ce que le compte du serveur web pouvait lire doit être considéré comme exposé. Aucun des signalements ne montre d'obtention de root.
Ce qu'il faut faire: Mettre à jour l'application vers 26.4.303 minimum ou la supprimer ; la désactiver ne suffit pas, le script reste appelable ; sur Nextcloud 29 et antérieur, migrer Nextcloud ou retirer l'application ; rechercher les fichiers shx*.php dans apps/richdocumentscode et les supprimer ; analyser les journaux d'accès depuis le 10 septembre à la recherche de requêtes proxy.php?status contenant %2e%2e, $( ou ${IFS}, ainsi que les tentatives sudo du compte web.
Ce qui reste incertain: La date exacte de signalement à Collabora et le moment où l'équipe a compris qu'il s'agissait d'un correctif de sécurité ne sont pas documentés. L'ampleur réelle de la compromission reste inconnue.

Sources :thehackernews.com thehackernews.com

03 / 10CritiqueSupply Chain

LiteLLM : une clé maître oubliée mène à un paquet Python piégé

Concerné: Paquet Python LiteLLM version 1.107.0, images Docker Hub et GHCR publiées le 21 octobre 2026 entre 11 h 46 et 12 h 06 UTC. Mitigé par quarantaine PyPI à 13 h 23 UTC.
Correctif: Oui, la version 1.107.0 a été mise en quarantaine et les étiquettes Docker v1.107.0, latest, main-latest et main-stable ont été retirées ou repointées vers des images propres. Les utilisateurs doivent considérer leurs secrets comme compromis et les révoquer.

Ce qui s'est passé: LiteLLM est une passerelle open source très répandue qui unifie l'accès à plusieurs modèles de langage (OpenAI, Anthropic, Bedrock, etc.). En mai 2026, un fichier de configuration contenant la clé maître d'une plateforme d'agents a été poussé sur un dépôt GitHub public. La clé n'a jamais été révoquée. Le 10 octobre, un attaquant l'a utilisée pour extraire un jeton OAuth GitHub non restreint, appartenant au compte propriétaire de l'organisation, puis a modifié le pipeline de publication pour construire une version à partir d'un dépôt sosie (Berri-AI au lieu de BerriAI).
Ce que ça change: La version 1.107.0 embarque un voleur d'identifiants (SSH, Git, variables d'environnement, jetons npm, PyPI, Maven, Cargo, clés cloud et d'inférence) et une porte dérobée Unix qui récupère et exécute du code toutes les heures. Le code s'active au démarrage de Python via des hooks de site-packages, même si l'application n'importe jamais LiteLLM. Les données étaient exfiltrées vers litellm[.]dev/healthcheck, domaine enregistré le 13 octobre.
Ce qu'il faut faire: Vérifier la présence de litellm==1.107.0 dans les environnements et les images ; ne pas se contenter de désinstaller le paquet, contrôler les fichiers de démarrage Python hors du répertoire applicatif ; révoquer tous les jetons exposés (GitHub, clés d'inférence, bases de données, Redis, Linear, Together AI) ; durcir les workflows GitHub Actions (jetons à portée limitée, environnements protégés, revue obligatoire, interdiction de publication depuis une branche arbitraire) ; surveiller les résolutions DNS vers litellm[.]dev et les webhooks webhook[.]site.
Ce qui reste incertain: Le nombre exact d'organisations ayant installé la version piégée n'est pas publié. LiteLLM indique que son enquête a invalidé certaines hypothèses initiales, ce qui suggère que la chronologie pourrait encore évoluer.

Sources :thehackernews.com helpnetsecurity.com securityweek.com bleepingcomputer.com

04 / 10CritiqueVulnérabilité

PHP2Shell : exploitation de masse, et un nouveau défaut non corrigé

Concerné: PHP, corrigé en 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le défaut CVE-2026-115560 concerne les applications qui changent le gestionnaire de sérialisation de session à l'exécution (php_binary ou php_serialize vers php via ini_set) avant session_start, avec session.upload_progress activé.
Correctif: Oui pour les deux failles principales (versions ci-dessus). Non pour CVE-2026-115560 : PHP recommande de désactiver session.upload_progress.enabled jusqu'à la prochaine version de maintenance.

Ce qui s'est passé: PHP2Shell désigne deux défauts permettant à un attaquant sans compte d'exécuter du code sur un serveur web PHP, ce qui concerne une très large part du web. Les correctifs d'urgence ont été publiés le 21 octobre. Deux jours plus tard, PHP a signalé un troisième chemin d'exécution, jugé peu probable en pratique, qui ne sera corrigé que lors de la prochaine release routinière.
Ce que ça change: Exécution de code arbitraire sur le serveur web, donc accès aux fichiers de configuration, aux secrets applicatifs, aux bases de données, et possibilité d'intégrer la machine à un botnet. Les tentatives non abouties restent coûteuses en bruit et en charge pour les sites non patchés.
Ce qu'il faut faire: Appliquer les versions 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ; désactiver session.upload_progress.enabled par précaution ; vérifier la dette de mise à jour des CMS et des hébergements mutualisés, la lenteur des mises à jour étant documentée côté français ; surveiller les requêtes POST anormales vers les endpoints PHP et les processus enfants inhabituels lancés par le serveur web.
Ce qui reste incertain: La fiabilité réelle des exploits publics reste débattue. Le bilan des compromissions réussies n'est pas établi. Les versions affectées par CVE-2026-115560 et son score de gravité ne sont pas encore publiés.

Sources :thehackernews.com thehackernews.com zdnet.fr securityweek.com

05 / 10ÉlevéeAttaque

Microsoft 365 : 79 organisations compromises sans aucun mot de passe

Concerné: Microsoft 365 et Microsoft Entra ID, indépendamment des versions clientes
Correctif: Sans objet. Les politiques Conditional Access ont bloqué 1 052 tentatives provenant de quatre organisations correctement configurées.

Ce qui s'est passé: Les victimes étaient attirées vers de fausses pages de connexion qui relayaient la vraie page Microsoft et le défi MFA (adversary-in-the-middle), ce qui permettait de récupérer le jeton de session émis après l'authentification. D'autres jetons ont été obtenus par hameçonnage device-code. L'attaquant a ensuite rejoué ces jetons en volume, depuis un hébergeur allemand (1337 Services GmbH) puis six adresses de la plage 193.26.115.0/24 : c'est le « token spraying », même logique que le password spraying mais avec des jetons volés. Les sessions étaient réutilisées en quelques minutes.
Ce que ça change: Accès complet aux boîtes mail, persistance par enregistrement de 48 ordinateurs factices dans les annuaires Entra, effacement des méthodes MFA existantes et enregistrement d'un nouvel authentificateur dans 19 organisations, règles de boîte aux lettres masquant certains messages (mots-clés paie, virement, banque, prime), et dans un cas envoi d'un courriel de paie frauduleux vers un comptable externe. Un nouvel authentificateur survit à une réinitialisation de mot de passe.
Ce qu'il faut faire: Déployer des politiques Conditional Access restrictives (appareil conforme, plage réseau, refus des protocoles legacy) ; bloquer les flux device-code non nécessaires ; auditer les méthodes d'authentification enregistrées et les appareils dans Entra ID ; rechercher les règles de boîte aux lettres suspectes et les noms d'appareils du type DESKTOP- suivi de huit caractères hexadécimaux ; surveiller les connexions réussies depuis des hébergeurs et les changements de MFA dans les trois heures suivant une connexion.
Ce qui reste incertain: Le nom du groupe n'est pas attribué. On ignore le préjudice final pour les 79 organisations, Huntress ne précisant pas si des données ont été exfiltrées.

Sources :helpnetsecurity.com

06 / 10ÉlevéeAttaque

BlackX : un bootkit UEFI contourne Secure Boot sur des Windows pourtant à jour

Concerné: Windows, sur les systèmes dont la liste de révocation Secure Boot (DBX) n'a pas été mise à jour manuellement. Les organisations diplomatiques du Tadjikistan, d'Ouzbékistan et du Turkmène ont été visées début 2026.
Correctif: Partiellement. Le correctif logiciel existe depuis 2023, mais la protection réelle exige d'appliquer manuellement les révocations Secure Boot, notamment l'ajout du certificat « Windows Production PCA 2011 » à la liste DBX. Ce certificat a expiré le 19 octobre 2026, ce qui n'empêche pas les binaires vulnérables de se charger tant qu'il n'est pas bloqué.

Ce qui s'est passé: BlackX est un bootkit, c'est-à-dire un logiciel malveillant qui s'installe dans la mémoire flash de la carte mère (UEFI) et s'exécute avant Windows. Il exploite une faille de contournement de Secure Boot pour charger du code non signé. Kaspersky le rapproche de BlackLotus, un bootkit commercialisé en 2022 dont le code source n'a jamais fuité : l'attaquant l'a donc soit rétroconçu, soit acheté le code. Le contexte visé et l'usage de DLL sideloading font suspecter APT41, sans attribution formelle.
Ce que ça change: Persistance qui survit à la réinstallation du système, injection d'un pilote noyau signé par un certificat depuis révoqué (éditeur Wenjiang District Mingyu Network Technology Service Studio), tentative de neutralisation d'antivirus, et déploiement d'un RAT communiquant via Google Drive, OneDrive et Yandex.Disk pour se fondre dans le trafic d'entreprise, plus une DLL (OxiDLLRunner) détournée via googleupdate.exe.
Ce qu'il faut faire: Vérifier l'application effective des révocations Secure Boot et non seulement la présence des correctifs ; activer le démarrage sécurisé avec mot de passe administrateur UEFI ; surveiller l'apparition de clés MOK inconnues et les modifications de la partition EFI ; restreindre les droits administrateur local ; surveiller les connexions aux services de stockage grand public depuis des serveurs.
Ce qui reste incertain: L'attribution à APT41 reste une évaluation de Kaspersky, non confirmée par un État ou une autre équipe. Le mode de compromission initial n'est pas décrit.

Sources :thehackernews.com securelist.com

07 / 10ÉlevéeIA & Sécurité

Ransomware : des affiliés pilotent leurs intrusions avec des agents IA

Concerné: Équipements exposés et outils d'administration distante, versions non précisées par les sources
Correctif: Sans objet

Ce qui s'est passé: Des affiliés des groupes ransomware INC et The Gentlemen, russophones selon l'évaluation, utilisent un cadre baptisé Phantom, présenté comme une « chaîne de mort red team autonome ». Le fonctionnement est « exécution par IA, approbation humaine » : un opérateur fournit un prompt propre à la victime et valide chaque étape, tandis que l'intrusion est menée via OpenCode et des modèles commerciaux hébergés par OpenRouter. Une base de connaissances gérée par IA suit victimes, identifiants volés et avancement.
Ce que ça change: Exploitation à grande échelle de FortiClient EMS, SimpleHelp, cPanel et passerelles VPN, puis élévation de privilèges, vol d'identifiants, priorisation des fichiers finance, RH, juridique et direction, exfiltration via tunnels SOCKS inverses, désactivation d'EDR par technique BYOVD (pilote Zemana), et extorsion assistée par IA avec calcul de la capacité de paiement.
Ce qu'il faut faire: Patcher et restreindre l'accès aux consoles d'administration (FortiClient EMS, RMM, cPanel) ; supprimer la réutilisation de mots de passe, qui a permis à un seul secret de déverrouiller VPN, serveurs, RMM, sauvegarde et console de sécurité ; bloquer les pilotes vulnérables connus (zam64.sys) ; journaliser les accès aux partages finance et RH ; tester la détection des tunnels SOCKS inverses.
Ce qui reste incertain: Les issues des rançons sont inconnues, aucun portefeuille ni paiement n'a été retrouvé. Quand les modèles refusent, l'opérateur reformule en « test d'intrusion autorisé », ce qui brouille l'évaluation de l'efficacité réelle de l'IA.

Sources :thehackernews.com socradar.io

08 / 10ÉlevéeIA & Sécurité

LLMjacking : des modèles d'IA exposés transformés en agents d'attaque

Concerné: Serveurs de modèles auto-hébergés exposés sans authentification, passerelles d'IA, environnements de test internes, serveurs MCP (Model Context Protocol), interfaces compatibles OpenAI
Correctif: Sans objet, il s'agit de configuration

Ce qui s'est passé: Les opérateurs scannent Internet à la recherche de modèles accessibles sans authentification, puis leur envoient un prompt complet et un jeu d'environ 74 définitions d'outils. Le modèle détourné ne se contente pas de répondre : il planifie et exécute. Il scanne de nouvelles cibles, exploite des frameworks web (Django, Jupyter, Laravel), vole bases de données et identifiants, installe des mineurs de cryptomonnaies, jusqu'à 100 000 étapes sans validation humaine. Le coût de calcul est supporté par la victime, ce qui assure aussi l'anonymat de l'attaquant.
Ce que ça change: Campagnes d'exploitation automatisées à faible coût pour l'attaquant, minage de Monero via XMRig sur les serveurs compromis, et vol de secrets. Le prompt est enveloppé dans un jailbreak qui présente la lecture de fichiers .env et de clés d'API comme un travail de développement normal, et bannit les mots « illégal », « éthique » ou « je ne peux pas ». Une variante cible les serveurs de caméras et les installations Home Assistant via go2rtc.
Ce qu'il faut faire: Ne jamais exposer un endpoint de modèle ou un serveur MCP sans authentification ; placer une passerelle avec quotas, journalisation et filtrage des outils ; inventorier les serveurs MCP et les tests oubliés ; surveiller les pics de consommation de jetons et les appels d'outils inhabituels ; bloquer la sortie vers les pools de minage.
Ce qui reste incertain: Symantec n'attribue pas la campagne. Le nombre de modèles effectivement détournés n'est pas chiffré. Le pot de miel n'a pas exécuté les charges, donc l'efficacité finale des attaques n'est pas mesurée.

Sources :helpnetsecurity.com

09 / 10ÉlevéeVulnérabilité

GitLab : un RCE non authentifié noté 10.0, causé par le moteur d'expressions régulières de Ruby

Concerné: GitLab auto-hébergé, CVE-2026-110264 touchant toutes les versions depuis 7.0. Ruby 4.0.9, 3.4.12 et 3.3.13 corrigent le moteur Onigmo. Ruby 3.2 et antérieur ne recevront pas de correctif (fin de vie au 1er avril 2026).
Correctif: Oui. GitLab 19.5.1 pour CVE-2026-110264, rétroporté jusqu'à 18.11.13 ; GitLab.com est déjà corrigé. Ruby 4.0.9, 3.4.12, 3.3.13. Attention : la version 4.0.8 ne contient pas le correctif de CVE-2026-110264.

Ce qui s'est passé: GitLab compile des expressions régulières fournies par ses utilisateurs, par exemple dans les configurations CI/CD. Le moteur Onigmo de Ruby corrompt la mémoire lors de la compilation d'un motif spécialement forgé, ce qui peut aboutir à une exécution de code. Ruby souligne que toute application qui construit une expression régulière à partir d'une chaîne contrôlée par un attaquant est concernée, pas seulement GitLab.
Ce que ça change: Exécution de code à distance sans authentification sur un serveur GitLab auto-hébergé, donc accès au code source, aux secrets CI/CD, aux jetons de déploiement et aux runners. Les deux failles de septembre exigeaient un compte, celles d'octobre non.
Ce qu'il faut faire: Mettre à jour GitLab vers 19.5.1 ou le correctif rétroporté ; sinon, cesser de compiler des expressions régulières issues d'une entrée non fiable ; ne pas compter sur Regexp.timeout ni sur une limite de longueur, qui ne protègent pas ; déployer les règles de détection publiées par GitLab (plantages du worker natif Onigmo).
Ce qui reste incertain: Les scanners de vulnérabilités ne détecteront pas le problème côté Ruby, faute d'identifiant CVE propre et parce que les enregistrements GitLab ne nomment que GitLab comme produit. Le nombre d'instances exposées n'est pas connu.

Sources :thehackernews.com bleepingcomputer.com

10 / 10ÉlevéeVulnérabilité

Node2Shell : une faille dans le décodeur Brotli de Google touche Node.js, Bun, Python et Envoy

Concerné: Bibliothèque Brotli C 1.0.3 à 1.2.0 ; Node.js 22.x, 24.x, 26.x avant correctif (20.x et antérieur en fin de vie) ; Bun 1.4.3 et antérieur ; Envoy 1.39.2, 1.38.5, 1.37.7, 1.36.11 ; Istio 1.31.1, 1.30.5, 1.29.8 et antérieurs ; paquets Python Brotli 1.2.0 et brotlicffi 1.2.0.x ; cdxgen.
Correctif: Oui. Brotli 1.0.10, 1.1.1, 1.2.1 ; Node.js 22.23.4, 24.22.1, 26.12.1 ; Bun 1.4.4 ; Envoy 1.40.0, 1.39.3, 1.38.6, 1.37.8, 1.36.12 ; Istio 1.31.2, 1.30.6, 1.29.9 ; Brotli Python 1.2.1 et brotlicffi 1.2.1.0. Debian 13 corrigé le 23 octobre.

Ce qui s'est passé: Brotli est un format de compression créé par Google, très utilisé pour compresser les pages web. Le défaut se situe dans le code C qui décompresse le flux : des données compressées forgées peuvent écrire au-delà d'un tampon mémoire et corrompre le processus, provoquant un plantage, une fuite mémoire ou une exécution de code. Chaque logiciel embarque sa propre copie du décodeur, donc chacun doit être mis à jour séparément.
Ce que ça change: Un serveur non patché qui accepte une entrée compressée peut être pris de contrôle par un client malveillant, et un client non patché (par exemple curl --compressed) peut être compromis par un serveur malveillant. Pour Node.js, l'exposition passe par fetch() d'une réponse en Content-Encoding: br ou par un corps de requête Brotli via Express 5 ou body-parser 2. En Python, la simple présence du paquet suffit : requests, urllib3, httpx et aiohttp décodent Brotli automatiquement.
Ce qu'il faut faire: Mettre à jour puis redémarrer les processus et reconstruire les images de conteneurs, un processus en cours conservant l'ancien décodeur ; rejeter les requêtes portant Content-Encoding: br avant tout proxy ou analyseur si la mise à jour est impossible ; désactiver le décodage Brotli automatique côté clients HTTP ; désinstaller Brotli et brotlicffi en Python pour revenir à gzip ; ne pas se fier uniquement au pare-feu applicatif, qui ne couvre pas les réponses récupérées par les fonctions.
Ce qui reste incertain: L'exploit Node2Shell n'a été validé que sur une seule compilation et n'est pas public. Les évaluations de gravité divergent (9.2 contre 8.1). Les scanners de dépendances peuvent manquer les paquets Python, le CVE ne nommant que le dépôt Google.

Sources :thehackernews.com thehackernews.com

Demain aussi

Suivez DecodeVox pour ne rien manquer.

L'essentiel de l'actu cyber en vidéo courte, chaque jour, sur vos réseaux.

Tous les jours du radar Flux RSS