L'actu cyber du jour

lundi 19 octobre 2026

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

L'essentiel

Une compromission de fournisseur est en cours et touche des centaines de locataires Microsoft 365. Le secret applicatif de ConnectWise Cloud Backup (ex-SkyKick) a été utilisé pour obtenir des jetons Graph dans au moins 173 tenants, puis pour s'élever Global Administrator et poser de nouveaux secrets sur d'autres applications. Le service est coupé depuis le 15 octobre, mais les jetons déjà émis et les identifiants ajoutés survivent à la coupure.
Un défaut non corrigé et sans CVE dans le WPS de Broadcom permet à un attaquant à portée radio d'obtenir du code en root sur des millions de routeurs, sans mot de passe Wi-Fi. Broadcom connaît le problème depuis 2018 et refuse d'attribuer un identifiant ; les puces eCos anciennes sont un « forever day ».
L'IA accélère les deux camps. Le chercheur qui a trouvé la faille Broadcom a utilisé l'agent Codex d'OpenAI (GPT-5.6) pour analyser les firmwares ; à l'inverse, un PoC Plex publié le 16 octobre était exploité en production le 17, et MITRE normalise désormais le prompt injection dans ATT&CK v20.
Les secrets d'IA sont devenus une monnaie. Une intrusion chez OpenCode Console pourrait avoir exposé des clés OpenAI, Anthropic et Google de 1,4 % des utilisateurs du service hébergé, avec des factures frauduleuses rapportées par des utilisateurs ; le lien revendiqué par l'éditeur avec une « attaque de distillation à grande échelle » n'est pas documenté.
La supply chain logicielle reste le point de rupture le plus rentable : faux accélérateur Web3 diffusant des paquets npm qui détournent le trafic des agents de codage, modèles « open-weight » que l'on peut porter avec une porte dérobée pour 0,02 % de paramètres modifiés, et un implant Fortinet vivant uniquement en mémoire chez un opérateur télécom.
Tendance dominante : la persistance ne passe plus par un fichier ni par un mot de passe, mais par un jeton, un secret applicatif ou un artefact de confiance. Le contrôle qui compte n'est plus « la version est-elle à jour » mais « qui peut encore s'authentifier en notre nom ».

01CritiqueSupply Chain

ConnectWise : le secret d'une sauvegarde devient la clé de centaines de tenants Microsoft 365

Ce qui s'est passé: ConnectWise Cloud Backup est une application tierce que les prestataires informatiques (MSP) installent dans les Microsoft 365 de leurs clients pour sauvegarder boîtes mail, OneDrive, SharePoint et Teams. Pour ce faire, elle reçoit des permissions très larges et s'authentifie avec un secret applicatif, un mot de passe de machine, pas d'utilisateur. Ce secret a fuité. Avec lui, un attaquant demande à Microsoft Entra ID des jetons au nom de l'application, sans jamais avoir le mot de passe d'un seul employé, et hérite de tous les droits de la sauvegarde.
Ce que ça change: lecture des boîtes mail, des fichiers OneDrive/SharePoint, des conversations Teams et de l'annuaire, sur tous les tenants où l'application est consentie. Dans au moins un tenant, l'attaquant a utilisé une seconde application ConnectWise (Teams) pour s'ajouter au rôle Global Administrator, puis a exécuté un script Python (User-Agent Python-urllib/3.12) ajoutant de nouveaux client secrets à deux applications de confiance, dont un outil de sécurité et une application de gestion MSP. C'est une porte dérobée durable : révoquer le secret initial ne la ferme pas.
Ce qu'il faut faire: (1) auditer les journaux de connexion des principaux de service dans Entra ID (Monitoring → Sign-in logs → onglet *Service principal sign-ins*) en filtrant sur les sept Application ID listés, en ignorant l'onglet « User sign-ins » qui ne montre rien ; (2) rechercher toute attribution du rôle Global Administrator à ces applications et tout ajout de client secret/certificat sur des applications du tenant ; (3) révoquer les jetons et pas seulement désactiver l'application ; (4) tourner tous les secrets des applications auxquelles ces identités avaient accès ; (5) vérifier les règles de boîte mail et les délégations créées depuis le 14 octobre ; (6) côté MSP, cartographier quels clients avaient l'application consentie, ConnectWise ne peut pas le faire à leur place.
Ce qui reste incertain: le vecteur initial de compromission du secret n'est pas établi ; ConnectWise indique ne pas avoir constaté d'accès aux archives de sauvegarde, qui restent chiffrées et isolées ; le nombre total de tenants touchés au-delà des 173 observés par Huntress est inconnu ; aucune attribution d'acteur n'a été faite ; l'implication éventuelle d'une vulnérabilité produit est « à l'étude ».

Sources :bleepingcomputer.com thehackernews.com thehackernews.com theregister.com

02CritiqueVulnérabilité

Broadcom : root à distance sur des millions de routeurs, sans mot de passe Wi-Fi et sans CVE

Ce qui s'est passé: le WPS permet d'associer un appareil au Wi-Fi sans taper le mot de passe. Le code Broadcom qui réassemble les messages WPS fragmentés ne vérifie pas correctement les longueurs : en envoyant une série de messages forgés, un attaquant à portée radio corrompt la mémoire du routeur. À partir de là, Kaiser a construit deux primitives : une lecture mémoire (qui lui a permis d'exfiltrer la clé Wi-Fi depuis les réglages) et une exécution de code en root, utilisée pour ouvrir un shell inverse porté par des trames Wi-Fi, sans serveur externe.
Ce que ça change: prise de contrôle totale du routeur ou de la passerelle, sans authentification ni appairage. Sur la passerelle Orange Belgium, la clé PSK a été lue et renvoyée par les airs, puis utilisée pour rejoindre le réseau. Sur la BBOX3V+ de Proximus, un shell root à distance. Pour un attaquant, cela signifie interception et manipulation du trafic, accès au réseau interne, et un point d'appui discret pour rebondir, exactement le mode opératoire des attaques de proximité attribuées à des acteurs étatiques russes.
Ce qu'il faut faire: inventorier les passerelles et points d'accès Broadcom, en priorité ceux fournis par les FAI et les matériels en fin de support ; utiliser les règles YARA et le script de détection du chercheur sur les firmwares extraits, en gardant en tête qu'un positif n'est qu'un indice (un équipement corrigé peut correspondre) ; remplacer les puces eCos, sans attendre un correctif qui n'existera pas ; pour les sites sensibles, considérer le Wi-Fi comme un canal hostile au même titre qu'Internet (cloisonnement, 802.1X, surveillance des associations WPS) ; documenter le risque résiduel en acceptation formelle, faute de CVE pour le suivi par les scanners.
Ce qui reste incertain: le nombre mondial d'équipements touchés est inconnu (≈1,5 million estimé en Belgique, chiffres « napkin maths » : 850 000 Proximus, 500 000 VOO, 210 000 Orange) ; une partie de la liste de produits repose sur des tests automatiques non confirmés ; Broadcom n'a pas commenté publiquement ; la portée exacte de l'attaque au-delà de la portée visuelle des antennes n'est pas chiffrée.

Sources :thehackernews.com cybernews.com quentinkaiser.be github.com

03CritiqueAttaque

Fortinet : un implant mémoire chez un opérateur télécom, et CVE-2025-61624 ajouté au KEV

Ce qui s'est passé: l'attaquant est entré par FortiManager (le poste de commandement des pare-feux FortiGate), y a enregistré un FortiGate virtuel illégitime et exfiltré une archive de configuration couvrant le FortiManager, plus de 500 pare-feux FortiGate gérés et la topologie du réseau victime. Il a ensuite exploité une traversée de chemin pour obtenir root sur le système sous-jacent et déployer PeerStitch, un implant ARM64 écrit en C qui vit uniquement en mémoire.
Ce que ça change: un implant qui n'ouvre aucun port en écoute, n'initie aucune connexion sortante et communique via le trafic de processus légitimes. Il agit comme un injecteur « one-shot » qui patch la mémoire des démons de journalisation et du service VPN IKE/IPsec de FortiOS pour créer un pont de communication occulte entre eux, en contournant les validations par défaut. L'attaquant a aussi usurpé l'identité du FortiManager dans les échanges FortiGate↔FortiManager (FGFM) pour envoyer des commandes depuis une infrastructure externe, et a effacé massivement les artefacts forensiques. Avec 500 pare-feux cartographiés et un accès root, la porte est ouverte à une modification de règles, un interception de VPN et un mouvement latéral durable.
Ce qu'il faut faire: patcher FortiManager et l'ensemble de la gamme FortiOS/FortiProxy/FortiPAM/FortiSwitchManager sans délai ; considérer tout FortiManager comme un actif de niveau « tier 0 » et isoler son accès d'administration ; rechercher les FortiGate virtuels enregistrés non autorisés et les incohérences d'identité dans les échanges FGFM ; réinitialiser les secrets et certificats susceptibles d'avoir été exfiltrés via l'archive de configuration ; mettre sous surveillance les redémarrages inexpliqués et les écarts de mémoire des démons VPN ; prévoir une reconstruction plutôt qu'un simple nettoyage si un implant mémoire est suspecté.
Ce qui reste incertain: l'attribution à un acteur étatique est décrite comme « suspectée » par SecurityWeek et Palo Alto ; le nombre exact de victimes n'est pas public ; le lien entre CVE-2024-26008 (utilisée pour tuer la session du FortiManager légitime) et la chaîne complète est rapporté par Unit 42 mais non recoupé indépendamment ici.

Sources :securityweek.com unit42.paloaltonetworks.com thehackernews.com

04ÉlevéeVulnérabilité

PwnEscape (CVE-2026-99999) : une VM invitée peut lire la mémoire de l'hôte

Ce qui s'est passé: Linux autorise un paquet réseau à transporter des métadonnées indiquant où commence le calcul de checksum et où écrire son résultat, une optimisation légitime de « checksum offload ». Le problème survient quand ces métadonnées, contrôlées par une VM invitée non fiable, influencent une écriture après que l'en-tête du paquet a déjà passé les validations. La fonction skb_checksum_help corrompt alors l'en-tête réseau. Quelques paquets IPv4 malformés suffisent.
Ce que ça change: franchissement de la frontière invité/hôte, c'est-à-dire la garantie sur laquelle repose tout le cloud public. Red Hat décrit un impact potentiel incluant exécution de code arbitraire sur l'hôte, crash (déni de service) ou divulgation de mémoire sensible. Un attaquant qui contrôle une charge de travail invitée, cas trivial dans un cloud mutualisé ou un environnement CI, peut lire ce qu'il ne devrait pas voir, et potentiellement atteindre les autres VM du même hôte.
Ce qu'il faut faire: prioriser le patch des hyperviseurs multi-tenant et des plateformes de virtualisation internes ; vérifier la version de noyau réellement utilisée par les nœuds, pas celle du conteneur ; pour les environnements non patchables à court terme, réduire la co-localisation de charges de travail de niveaux de sensibilité différents et surveiller les erreurs de checksum anormales ; considérer ce type de bug comme un argument supplémentaire pour la micro-segmentation et les VM dédiées aux traitements les plus sensibles.
Ce qui reste incertain: la liste des versions affectées/corrigées n'est pas fournie dans les articles consultés ; le score 9.3 est attribué à une source secondaire ; aucune exploitation dans la nature n'a été signalée, mais l'absence de signal n'est pas une preuve d'absence.

Sources :theregister.com thehackernews.com pwn.ai

05ÉlevéeVulnérabilité

Plex2Shell : du PoC à l'exploitation en production en 24 heures

Ce qui s'est passé: les quatre failles se combinent pour exécuter du code arbitraire sur un serveur Plex exposé, sans identifiants valides, avec les privilèges du service Plex. Elles ont été signalées à Plex le 27 juillet, confirmées et récompensées le 4 août, corrigées le 1er septembre. Le chercheur a publié l'analyse et un PoC le 16 octobre ; moins de 24 heures plus tard, des attaquants l'utilisaient.
Ce que ça change: sur le pot de miel, deux charges utiles ont été déposées : un mineur de cryptomonnaie basé sur XMRig, puis un programme nommé myawesomeproxy transformant la machine en proxy résidentiel. Le chercheur souligne la logique : un serveur Plex est souvent hébergé sur une IP résidentielle, et une IP résidentielle est très recherchée pour accéder à des VPN d'entreprise et à des messageries sans déclencher les filtres « datacenter ». Le serveur média devient un relais d'accès, pas seulement une machine à miner.
Ce qu'il faut faire: mettre à jour vers 1.43.3 (Desktop 1.115.0) immédiatement, y compris sur NAS où le paquet peut être en retard, installation manuelle si nécessaire ; retirer Plex de l'exposition directe à Internet (accès distant via VPN ou reverse proxy authentifié) ; rechercher les processus XMRig, les connexions sortantes vers des services de proxy résidentiel et les binaires inconnus dans le répertoire Plex ; vérifier la charge CPU et le trafic sortant des serveurs média, trop souvent exclus du périmètre de supervision.
Ce qui reste incertain: aucun score CVSS publié ; les indicateurs de compromission publiés ne couvrent que l'activité vue sur le pot de miel, pas une campagne à grande échelle ; le nombre de serveurs compromis est inconnu ; l'identité des attaquants n'est pas établie.

Sources :securityweek.com forums.plex.tv zmain.info

06ÉlevéeVulnérabilité

SiteGuard : injection de commandes exploitée sur un WAF présent sur 500 000 sites WordPress

Ce qui s'est passé: SiteGuard est un pare-feu applicatif japonais revendiquant la protection de plus de 1,5 million de sites, et actif sur environ 500 000 sites WordPress selon WordPress.org. Une injection de commandes système dans la fonction de statistiques permet à un attaquant d'exécuter des commandes avec les privilèges root ou SYSTEM sur le serveur qui héberge le WAF. Autrement dit, le composant censé filtrer les attaques web devient lui-même le point d'entrée, avec les droits les plus élevés.
Ce que ça change: exécution de commandes en root/SYSTEM, donc prise de contrôle du serveur, accès aux sites hébergés, aux bases de données et aux secrets qui y sont stockés. Le WAF étant en amont du site, la compromission est particulièrement discrète : elle ne passe pas par l'application surveillée.
Ce qu'il faut faire: mettre à jour vers 8.00 Update 5 (ou 7.00 Update 6 sur FreeBSD) ; avant toute remédiation, préserver les preuves, l'éditeur prévient que le correctif peut effacer les traces, et indique de télécharger et conserver les « Diagnostic information » depuis l'interface d'administration ; ensuite, rechercher des webshells, des comptes ajoutés et des tâches planifiées sur les serveurs concernés ; vérifier si la fonction de statistiques est réellement nécessaire et la désactiver sinon.
Ce qui reste incertain: aucun score CVSS n'est publié dans les sources consultées ; l'identité des attaquants, les victimes et l'échelle de la campagne ne sont pas documentées par les avis ; le chiffre de 500 000 sites est une statistique de déploiement, pas un décompte de victimes.

Sources :bleepingcomputer.com

07ÉlevéeAttaque

ETS : un seul identifiant compromis, des millions de dossiers d'élèves californiens copiés

Ce qui s'est passé: un tiers de confiance chargé des tests mandatés par l'État californien utilisait un site de transfert de fichiers pour échanger des données avec le ministère. Un tiers a utilisé un identifiant compromis, à plusieurs reprises pendant près de quatre mois, pour copier des fichiers. Personne ne l'a vu avant le 25 septembre. Ce n'est pas une attaque sophistiquée : c'est un identifiant valide utilisé trop longtemps sans détection.
Ce que ça change: les données de tous les élèves inscrits dans les trois années scolaires précédentes, plus des élèves ayant quitté le système californien depuis 2006 lorsque leur transfert n'a pas été confirmé. Le California Department of Education comptait plus de 5,7 millions d'élèves inscrits en 2025-2026. Les fichiers contiennent nom, date de naissance, adresse, école, district, niveau, identifiants locaux et d'État, genre, origine ethnique, langue maternelle, pays d'origine, statut d'apprenant anglophone, et pour certains : handicap et statut Section 504, type de handicap principal, aménagements de test, résultats et inscriptions aux tests, éligibilité Title I, McKinney-Vento ou « military-connected ». Pas de numéros de sécurité sociale, mots de passe ni données bancaires selon l'avis.
Ce qu'il faut faire: imposer MFA et, mieux, une authentification par clé avec liste d'IP sur tout serveur SFTP d'échange inter-organisations ; surveiller le volume et la granularité des téléchargements (une copie de masse est un signal, pas un usage normal) ; cloisonner les données d'élèves par programme et par année, avec purge automatique ; journaliser et alerter sur les accès hors horaires et les réutilisations d'identifiants ; pour les organismes publics, exiger contractuellement une détection et une notification sous 72 heures.
Ce qui reste incertain: aucun décompte de victimes n'a été fourni ; la période de quatre mois entre le premier accès et la détection n'est pas expliquée ; l'identité de l'attaquant et l'usage des données ne sont pas connus ; on ne sait pas si les fichiers ont été exfiltrés intégralement ou partiellement.

Sources :securityweek.com cde.ca.gov cde.ca.gov

08ÉlevéeIA & Sécurité

OpenCode : les clés API des Fournisseurs d'IA étaient stockées côté éditeur

Ce qui s'est passé: OpenCode Console permet à une équipe de stocker une clé OpenAI, Anthropic ou Google dans un espace de travail ; le service s'en sert pour appeler le modèle, sans que les membres voient la clé. Un intrus a atteint un système hérité (« legacy ») dans la nuit du 16 octobre. Les clés collées dans Console ont pu être exposées ; celles ajoutées localement dans le CLI ou l'application de bureau n'ont jamais transité par l'éditeur.
Ce que ça change: une clé fournisseur est un porteur de valeur : quiconque en détient une copie peut émettre des requêtes facturables au compte du propriétaire jusqu'à révocation. Supprimer la clé de Console ne la révoque pas, et un budget Console ne peut pas plafonner cet usage, car Console ne voit que les requêtes passant par sa passerelle. Des utilisateurs rapportent des montants non sollicités, 281 $ sur OpenAI et 168 $ sur Anthropic pour l'un, 1 700 $ pour un autre, 400 $ et environ 200 € pour d'autres, mais ce sont des déclarations publiques d'utilisateurs, non vérifiées. L'éditeur évoque un lien avec une « attaque de distillation à grande échelle », c'est-à-dire le pompage massif des réponses d'un modèle pour entraîner un concurrent.
Ce qu'il faut faire: révoquer puis recréer les clés chez le fournisseur (ne pas se contenter de les supprimer de Console) ; auditer la facturation depuis le 16 octobre ; accorder une clé par outil et par environnement, avec plafond de dépense et alerte ; ne jamais stocker de clé de production dans un service tiers d'agrégation, préférer des identités de workload ou des proxys sortants contrôlés ; journaliser les appels sortants vers les API de modèles pour repérer un usage anormal.
Ce qui reste incertain: l'éditeur n'a pas confirmé que des clés ont été copiées ou utilisées ; le nombre d'utilisateurs derrière « 1,4 % » n'est pas donné ; le système hérité visé, le mode d'accès et le lien exact avec la distillation ne sont pas documentés ; les pertes financières citées sont des témoignages non recoupés.

Sources :thehackernews.com x.com

09ÉlevéeSupply Chain

REF8801 : un faux accélérateur Web3 utilise npm et MCP pour détourner le trafic des agents de codage

Ce qui s'est passé: l'opération se présente comme un accélérateur de capital-risque Web3, « Apex Accelerator », promettant 235 000 $ d'investissements et des crédits gratuits pour Claude et Gemini. Elle approche des développeurs sur X, puis leur demande d'exécuter son outil de « due diligence ». @apexacc/cli s'affiche comme un conseiller IA pour fondateurs Web3, @apexacc/audit comme un serveur MCP exposant 18 outils d'audit de contrats intelligents. Les deux livrent des voleurs d'informations et des portes dérobées pour Windows et macOS.
Ce que ça change: trois effets distincts. (1) Vol d'identifiants et de portefeuilles. (2) Détournement : l'opération a reconditionné un agent de codage légitime pour envoyer les requêtes de modèle vers des services qu'elle contrôle, donc lecture des prompts, du code et des secrets qui y circulent, et facturation à son profit. (3) Tromperie sur l'audit : les outils d'audit génèrent de faux résultats de sécurité, ce qui donne une apparence de conformité à des projets crypto. Le chargeur observé se déguise en application Apple (com.apple.system.loader).
Ce qu'il faut faire: bloquer les scopes npm @apexacc et @apexfdn ; exiger la provenance npm et la signature des paquets, avec 2FA sur les comptes de publication ; traiter tout serveur MCP comme du code exécutable tiers, avec revue avant installation et exécution en bac à sable ; surveiller les sorties réseau des postes de développement vers des endpoints d'API de modèles inconnus, y compris depuis des agents de codage ; sensibiliser les fondateurs et développeurs crypto, cible privilégiée de ce type d'approche par « opportunité d'investissement ».
Ce qui reste incertain: le nombre de victimes et l'ampleur de l'exfiltration ne sont pas publics ; on ne sait pas si les données de prompts déjà interceptées ont été exploitées ; la durée exacte d'activité de l'infrastructure n'est pas établie.

Sources :thehackernews.com elastic.co

10ModéréeIA & Sécurité

Modèles open-weight : la sécurité redevient une responsabilité de l'entreprise

Ce qui s'est passé: Microsoft et NVIDIA publient un document conjoint sur les risques des modèles à poids ouverts, des modèles dont les paramètres sont téléchargeables, inspectables et modifiables. Leur thèse : « l'ouverture des poids ne détermine pas à elle seule le risque » ; ce qui change, c'est qui fournit les garde-fous. Un modèle fermé arrive avec la surveillance et les filtres du fournisseur ; un modèle ouvert arrive souvent comme un simple fichier. Une entreprise qui détient les poids peut modifier ou retirer le comportement de sûreté, et les protections de l'éditeur « ne sont plus universellement applicables ». Le document classe les risques en cinq catégories et trente types.
Ce que ça change: un modèle peut être altéré, reconditionné ou redistribué avant d'arriver chez l'utilisateur, perdant au passage ses protections d'origine. Le fine-tuning, la fusion ou la compression peuvent affaiblir les garde-fous sans dégrader les performances apparentes, donc sans signal évident. ProjectDiscovery a caché une porte dérobée dans Qwen2.5-7B-Instruct avec un jeu de données public et un GPU loué ; exécuté via le CLI Codex d'OpenAI, le modèle a livré les identifiants du projet dès qu'il a vu son déclencheur. BadEngram, de Pillar Security et Fujitsu Research of Europe, modifie environ 0,02 % des paramètres pour implanter une porte dérobée durable dans la mémoire de modèles récents. Autre canal : les fichiers de modèle distribués au format Pickle peuvent exécuter du code arbitraire au chargement.
Ce qu'il faut faire: « établir la provenance avant le comportement », vérifier la signature cryptographique et l'empreinte du fichier avant tout test, et consigner l'absence de signature comme un risque ouvert ; préférer les formats sûrs (safetensors) à Pickle ; ne pas considérer un scan de dépôt comme une garantie ; conserver des contrôles superposés et rapidement modifiables (filtrage d'entrée, modération de sortie, restrictions d'accès, limitation de débit, supervision humaine) ; surveiller les nouvelles variantes d'un modèle et les changements sur les dépôts qui le distribuent.
Ce qui reste incertain: il s'agit d'un document d'orientation de deux fournisseurs, pas d'une divulgation de vulnérabilité ; les scénarios de porte dérobée sont des démonstrations de recherche, non des campagnes observées ; aucune donnée d'exposition réelle n'est fournie.

Sources :helpnetsecurity.com

Tous les jours du radar