L'actu cyber du jour

vendredi 30 octobre 2026

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

Lecture : 17 min

L'essentiel

La journée confirme un basculement : l'IA n'est plus seulement un sujet de sécurité, elle devient un maillon de la chaîne d'attaque. Anthropic indique qu'un de ses modèles a écrit un exploit fonctionnel pour une faille noyau Linux notée 9.8, et les chercheurs de Dream retrouvent Claude Code, une plateforme d'attaque assistée par LLM et des scripts visiblement générés par IA dans l'infrastructure d'une campagne chinoise ayant rooté 25 pare-feux.
Côté exposition, les chiffres donnent le vertige : environ 19 000 interfaces de gestion de pare-feux indexées par FOFA, 51 000 passerelles Cisco ASA SSL VPN exposées sur Internet (Shadowserver), plus de 42 000 boutiques Drupal Commerce et 13,4 millions d'installations d'extensions Chrome détournées. La dette d'exposition reste le vrai multiplicateur de risque.
Les échéances de la CISA se sont encore resserrées : trois jours pour GitLab (CVE-2026-97229, CVSS 10.0), 31 octobre pour Fragnesia (CVE-2026-46300), 10 novembre pour Node2Shell (CVE-2026-111497), 11 novembre pour le défaut de journalisation VMware ESX (CVE-2026-41709). Le temps de correction utile se compte désormais en jours.
Deux zero-days réseau supplémentaires touchent Cisco : un déni de service sur ASA/FTD (CVE-2026-76418) et l'exploitation de CVE-2026-20127 sur les contrôleurs SD-WAN pour y déployer le maliciel KeyDrift, qui vole les clés IPsec du plan de données.
La supply chain de l'outillage IA est devenue une cible de premier choix : version piégée de l'extension officielle Claude Code, modèles malveillants sur Hugging Face avec trust_remote_code, faux kit Solana destiné à tromper les agents de codage, navigateurs embarqués de Codex et VS Code encore non corrigés.
Le vol record de 6,3 milliards de dollars chez Binance rappelle que l'endpoint d'un ingénieur DevOps reste la porte d'entrée la plus rentable : pas de clé privée volée, mais un accès à un conteneur de service et des retraits non autorisés.

01 / 10CritiqueAttaque

PHP2Shell et Fragnesia : 25 pare-feux rootés, un réseau gouvernemental atteint, et 22 machines encore armées

Concerné: PHP (chaîne d'exploitation via PHP 8.0.30 et le mécanisme session.upload_progress du serveur de gestion appweb) ; noyau Linux pour Fragnesia. L'éditeur des pare-feux touchés n'est pas nommé par Dream, mais les versions citées et le contexte pointent vers une gamme de pare-feux d'entreprise largement déployée.
Correctif: Oui, pour PHP (branches 8.5, 8.4, 8.3, 8.2) et pour le noyau Linux ; le correctif doit être déployé par chaque distribution et surtout par les appliances, souvent en retard d'un cycle.

Ce qui s'est passé: PHP2Shell désigne deux défauts de gestion mémoire dans PHP qui permettent à un attaquant non authentifié de faire exécuter du code au serveur web. Fragnesia est une faille du noyau Linux qui permet de passer de l'utilisateur du service web à root. Séparément, chacune demande du travail. Enchaînées, elles donnent root sur une appliance. Dream a reconstitué la campagne complète : reconnaissance via le moteur de recherche d'actifs FOFA, scan de versions, filtrage géographique, puis exécution automatisée par lots.
Ce que ça change: L'attaquant obtient root sur le pare-feu, y dépose un webshell PHP dans un répertoire accessible publiquement, ouvre un tunnel SSH inverse vers l'intérieur du réseau, atteint un serveur de gestion de pare-feux accessible uniquement par ce tunnel, puis attaque Active Directory : déchiffrement du mot de passe du compte de service LDAP, énumération des utilisateurs, pulvérisation de mots de passe construits sur le thème de l'organisation et tentative de création de comptes backdoor.
Ce qu'il faut faire: Recenser toutes les interfaces de gestion exposées à Internet et les fermer (accès par jump host uniquement). Appliquer les correctifs PHP et noyau des appliances, y compris celles dont le cycle de mise à jour est trimestriel. Rechercher les webshells PHP récents dans les répertoires web, les tunnels SSH sortants depuis des équipements réseau et les entrées authorized_keys inattendues. Auditer les journaux d'Active Directory pour des créations de comptes et des échecs d'authentification en rafale. Renouveler les secrets stockés sur les pare-feux et les comptes de service LDAP. Les 22 autres pare-feux rootés restent, selon Dream, équipés de webshells actifs.
Ce qui reste incertain: Dream ne nomme pas l'éditeur des pare-feux, et le lien avec Palo Alto Networks relève d'une coïncidence de calendrier, non d'une confirmation. Le succès de la phase Active Directory (identifiants valides obtenus, comptes backdoor créés) n'est pas établi. La qualification d'« assistée par IA » repose sur des artefacts (Claude Code installé, clés API FOFA, plateforme aiscan configurée avec DeepSeek et Kimi, style de code homogène sur une quarantaine de scripts), pas sur une preuve directe. L'affirmation selon laquelle un groupe rançongiciel utiliserait PHP2Shell contre des pare-feux Palo Alto provient d'un chercheur unique, Kevin Beaumont.

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

02 / 10CritiqueIA & Sécurité

Une IA d'Anthropic écrit un exploit root pour le noyau Linux : CVE-2026-98432, CVSS 9.8, distributions encore non corrigées

Concerné: Noyau Linux, code d'établissement des connexions TCP IPv4 ; distributions citées : Ubuntu, Red Hat Enterprise Linux, Amazon Linux, Oracle Linux, SUSE. Le vecteur réel passe par les sockets en écoute utilisant Multipath TCP (MPTCP).
Correctif: Partiellement. Le correctif est en amont (commit noyau cité en source) et rétroporté sur les branches stables, mais sa disponibilité côté distribution dépend de chaque éditeur. Vérifier la version de noyau proposée par votre distribution avant de considérer le sujet clos.

Ce qui s'est passé: Lors de l'ouverture d'une connexion TCP, le noyau manipule des structures partagées entre plusieurs coeurs d'exécution. Une condition de course dans cette séquence permet de libérer une zone mémoire puis de la relire, un schéma dit « use-after-free ». Un attaquant distant, sans identifiants, peut exploiter cette lecture pour exécuter du code avec les privilèges du noyau, donc en root. Le lien avec MPTCP vient de la publication d'Anthropic : le noyau n'active MPTCP que si l'application le demande, mais depuis Go 1.24 les programmes Go l'activent par défaut sur leurs sockets en écoute, ce qui élargit la population de serveurs réellement vulnérables.
Ce que ça change: Exécution de commandes en root à distance et sans authentification sur les serveurs qui écoutent en MPTCP, donc prise de contrôle complète de l'hôte, avec les conséquences habituelles : persistance, vol de secrets applicatifs, pivot latéral. La nuance importante est que l'exploit dépend de conditions de course, donc d'un taux de réussite variable selon la charge et le matériel.
Ce qu'il faut faire: Inventorier les services en écoute MPTCP (ss -M, ou vérification de net.mptcp.enabled). Si MPTCP n'est pas nécessaire, le désactiver (sysctl net.mptcp.enabled=0) en attendant le noyau corrigé, et prioriser les serveurs exposés à Internet. Pour les services Go, vérifier si le runtime utilisé active MPTCP par défaut. Surveiller les journaux noyau pour des traces de corruption mémoire et les comportements post-exploitation (nouveaux processus root, modules chargés). Ne pas se fier au seul score 9.8 : la criticité réelle dépend de l'exposition MPTCP.
Ce qui reste incertain: Ni la fiche CVE ni le correctif ne mentionnent MPTCP ; le lien vient de la publication d'Anthropic et de l'avis de l'équipe sécurité de Go. Le périmètre exact des versions de noyau affectées par distribution n'est pas consolidé dans les sources consultées. Le fait qu'un modèle d'IA ait produit l'exploit est une déclaration d'Anthropic, cohérente avec le crédit de découverte attribué à son chercheur Xinyang Ge, mais non auditée indépendamment.

Sources :thehackernews.com anthropic.com git.kernel.org

03 / 10CritiqueVulnérabilité

GitLab : CVE-2026-97229, CVSS 10.0, exploitée contre Alpine Linux et ajoutée au KEV avec trois jours de délai

Concerné: GitLab Community Edition et Enterprise Edition. La faille se situe dans Onigmo, le moteur d'expressions régulières de Ruby, et non dans GitLab lui-même : les instances compilées avec leur propre Ruby restent vulnérables même après mise à jour de GitLab.
Correctif: Oui, GitLab 19.3.6, plus Ruby 3.3.13, 3.4.12 ou 4.0.9 selon la branche si vous fournissez votre propre interpréteur Ruby.

Ce qui s'est passé: GitLab exécute du code fourni par les utilisateurs, notamment les fichiers de configuration CI/CD. Une validation insuffisante de certaines expressions régulières dans le moteur Ruby Onigmo permet à un utilisateur non authentifié de déclencher une corruption mémoire, puis une exécution de code sur le serveur, simplement en poussant une configuration CI piégée. La faille est d'autant plus gênante qu'elle vit dans une dépendance : mettre à jour l'application ne suffit pas si l'environnement Ruby est géré séparément.
Ce que ça change: Exécution de code arbitraire sur le serveur GitLab, donc accès aux dépôts de code source, aux secrets de CI (jetons de déploiement, clés cloud), aux runners et, par ricochet, à la chaîne de build et de publication logicielle. C'est le scénario de compromission de supply chain le plus direct qui existe.
Ce qu'il faut faire: Mettre à jour GitLab et Ruby, redémarrer les services, puis vérifier les jobs CI et les comptes récemment créés. Auditer les secrets exposés aux runners et les faire tourner. Restreindre l'inscription publique et l'exécution de pipelines pour les nouveaux comptes. Comparer les artefacts de build publiés autour de la fenêtre d'exposition. Alpine Linux a reconstruit son instance de zéro et réinitialisé tous les mots de passe : c'est le bon niveau de réaction quand on ne peut pas exclure l'exécution de code.
Ce qui reste incertain: Alpine indique n'avoir trouvé aucune preuve d'exécution de code, tout en précisant ne pas pouvoir l'exclure. L'attribution de l'attaque n'est pas établie. Le décompte exact des versions affectées (douze ans) provient de la couverture presse et non d'un avis éditeur consulté directement.

Sources :securityweek.com bleepingcomputer.com thehackernews.com

04 / 10ÉlevéeAttaque

Cisco SD-WAN : KeyDrift vole les clés de chiffrement du plan de données, sur fond de réseau furtif Silent Train

Concerné: Contrôleurs et managers Cisco Catalyst SD-WAN. Le maliciel KeyDrift s'installe dans les processus du plan de contrôle, notamment via des scripts de démarrage de service modifiés pour injecter du code dans vdaemon.
Correctif: Oui, correctif Cisco pour CVE-2026-20127 depuis février 2026, plus un guide de durcissement dédié aux déploiements Catalyst SD-WAN.

Ce qui s'est passé: Le contrôleur SD-WAN est le cerveau qui décide comment les sites d'une entreprise se parlent et avec quelles clés ils chiffrent leurs échanges. Une fois authentifié frauduleusement sur ce contrôleur, un attaquant peut ajouter des pairs légitimes à ses yeux. KeyDrift pousse l'exercice plus loin : le module LittleFilch s'accroche à la fonction de déchiffrement SSL du contrôleur pour lire les messages de contrôle après déchiffrement, en extraire les identifiants d'adresses et un champ de 32 octets interprété comme une clé IPsec AES-256, puis exfiltre le tout, chiffré en RSA, via UDP.
Ce que ça change: L'attaquant obtient de quoi déchiffrer ou usurper le trafic entre sites, avec un accès persistant au contrôleur. C'est de l'espionnage de niveau étatique : intercepter les échanges d'un réseau privé d'entreprise sans avoir à se placer sur le chemin du trafic. Le framework PolyFlame fournit en plus l'exécution de commandes, le transfert de fichiers et le relais vers d'autres pairs.
Ce qu'il faut faire: Vérifier l'application effective du correctif de février 2026, puis auditer la liste des pairs et des contrôleurs enregistrés. Contrôler l'intégrité des scripts de démarrage de service et des binaires vdaemon, et rechercher la présence de /var/tmp/vdaemon.bin. Surveiller les flux UDP sortants anormaux depuis les contrôleurs et les connexions administratives hors fenêtres de maintenance. Renouveler les clés IPsec et les secrets de contrôle. Filtrer la sortie Internet des équipements réseau, qui n'ont aucune raison de parler à un serveur inconnu.
Ce qui reste incertain: Le lien entre UAT-11473 et Volt Typhoon est présenté par Talos comme un recoupement d'infrastructure, sans attribution définitive. Talos ne date pas précisément les intrusions. Le rôle exact de Silent Train dans ces attaques reste une évaluation de Lumen Black Lotus Labs.

Sources :bleepingcomputer.com helpnetsecurity.com securityweek.com

05 / 10ÉlevéeVulnérabilité

Cisco ASA et FTD : un zero-day de déni de service exploité sur les passerelles SSL VPN

Concerné: Cisco Secure Firewall ASA et FTD, uniquement les configurations contenant le mot-clé webvpn avec SSL VPN activé sur au moins une interface.
Correctif: Oui, versions logicielles corrigées publiées par Cisco. Contournement possible : désactiver l'authentification secondaire sur le tunnel group DefaultWEBVPNGroup ou sur les listes configurées.

Ce qui s'est passé: Lorsqu'une authentification secondaire est configurée sur un groupe de tunnels, une erreur de logique dans le traitement de la requête de connexion VPN permet à un attaquant non authentifié d'envoyer une requête qui fait redémarrer l'équipement. Le résultat est un déni de service : plus de VPN, donc plus d'accès distant pour les télétravailleurs et les partenaires.
Ce que ça change: Indisponibilité de l'accès distant, avec un effet opérationnel immédiat. Un attaquant peut aussi utiliser ce type de faille comme bruit de couverture pour une autre action, ou pour forcer le basculement vers un chemin moins protégé.
Ce qu'il faut faire: Identifier les équipements ASA/FTD avec webvpn et authentification secondaire, puis appliquer le correctif ou désactiver l'authentification secondaire. Placer les portails SSL VPN derrière un contrôle d'accès et une limitation de débit. Surveiller les redémarrages inattendus et corréler avec les journaux VPN. Shadowserver recense plus de 51 000 passerelles ASA SSL VPN exposées sur Internet : l'exposition reste massive.
Ce qui reste incertain: Cisco ne publie ni indicateurs de compromission ni informations sur les acteurs. On ne sait pas si l'exploitation visait des cibles précises ou un balayage opportuniste.

Sources :bleepingcomputer.com thehackernews.com

06 / 10ÉlevéeVulnérabilité

Node2Shell : la faille Brotli CVE-2026-111497 est exploitée, et l'écosystème entier doit reconstruire ses images

Concerné: Décodeur Brotli de Google, versions 1.0.3 à 1.2.0. Touchés par ricochet : Node.js, .NET, Bun, Envoy, Istio, bibliothèques Python, et PAN-OS en cours de correctifs à chaud.
Correctif: Oui, publié le 21 octobre côté Node.js et Google, avec des mises à jour Microsoft d'urgence pour .NET, des correctifs pour Bun, Envoy, Istio et les paquets Python concernés, et des correctifs à chaud PAN-OS.

Ce qui s'est passé: Brotli compresse une grande partie du trafic web. Son décodeur, écrit en C, ne vérifie pas correctement une valeur de retour et peut écrire au-delà de la mémoire allouée quand il décompresse un flux malveillant. Comme à peu près tous les serveurs et clients décompressent des données venues d'Internet, la faille dépasse très largement Node.js, son point de découverte. Le détail qui fâche : le correctif était commité en février 2026 dans le dépôt public, mais aucune version ni avis n'a été publié pendant huit mois.
Ce que ça change: Fuite de mémoire (donc de secrets), déni de service, et exécution de code à distance dans certains cas. Sur un serveur applicatif, cela signifie compromission du processus, puis du conteneur, puis de l'hôte selon les privilèges.
Ce qu'il faut faire: Mettre à jour les runtimes et bibliothèques, redémarrer les processus, reconstruire et redéployer les images de conteneurs (un correctif applicatif ne corrige pas une couche de base obsolète). Si le patch n'est pas possible immédiatement, bloquer les requêtes compressées en Brotli au niveau du proxy ou désactiver le décodage. Vérifier les images de base utilisées par vos équipes, y compris celles qui ne sont pas reconstruites régulièrement.
Ce qui reste incertain: Le score CVSS varie selon les sources et aucun score éditeur unique n'est publié. Les rapports de honeypots ne documentent pas de compromission réussie en production.

Sources :bleepingcomputer.com securityweek.com securityweek.com

07 / 10ÉlevéeSupply Chain

L'extension officielle Claude Code piégée : backdoor SSH persistante via la place de marché d'extensions

Concerné: Extension Claude Code pour éditeurs compatibles VS Code, publiée sous l'identifiant légitime anthropic.claude-code. Exposition d'environ 11 heures le 29 octobre 2026, jusqu'à 5 000 utilisateurs selon Cursor. Les places de marché concernées : celle de Cursor et Open VSX (place de marché communautaire gérée par la Eclipse Foundation), utilisée par les éditeurs dérivés de VS Code.
Correctif: Oui, version 2.1.314 publiée sur Open VSX et sur la place de marché Microsoft. Les versions malveillantes ont été retirées et le serveur de l'attaquant mis hors ligne avec l'hébergeur.

Ce qui s'est passé: Le fichier extension.js de la version piégée commence par une fonction immédiatement invoquée, ajoutée avant le code légitime. Elle s'exécute dès que Node charge le fichier, avant même l'activation de l'extension : l'utilisateur n'a rien à faire. Le code ajoute la clé SSH de l'attaquant aux clés autorisées du compte, ouvre un tunnel SSH sortant vers un serveur contrôlé, et met en place une persistance propre à chaque système : fichier de démarrage au nom évoquant Apple sur macOS, entrée cron sur Linux, tâche planifiée nommée SysMon sur Windows, avec repli sur le dossier de démarrage.
Ce que ça change: Accès interactif durable à la machine du développeur, donc au code source, aux secrets de build, aux jetons cloud. Le maliciel remonte aussi le nom d'hôte, l'utilisateur, l'OS, le répertoire courant, l'adresse e-mail Git, l'IP publique et les noms de jusqu'à 40 variables d'environnement ressemblant à des clés ou des jetons : de quoi cartographier les machines à attaquer en priorité, sans même exfiltrer les valeurs.
Ce qu'il faut faire: Vérifier les fichiers authorized_keys, les LaunchAgents, les entrées cron et la tâche SysMon sur les postes de développeurs. Rechercher les connexions SSH sortantes persistantes vers des adresses inconnues. Faire tourner les identifiants présents sur les machines ayant installé des extensions entre le 29 et le 30 octobre. Épingler les versions d'extensions et n'autoriser que des éditeurs vérifiés. Considérer un poste de développeur comme un actif critique, pas comme un endpoint secondaire.
Ce qui reste incertain: Le mode d'introduction de la mise à jour malveillante sous l'identité de l'éditeur reste inconnu : compromission d'un jeton de publication, faille de la place de marché, ou insiders. Anthropic et Cursor se renvoient partiellement la responsabilité, Cursor affirmant que la version n'a pas été développée par Anthropic, ce qui ne règle pas la question de l'identité de publication. Le décompte de 5 000 utilisateurs est une estimation de Cursor. Les sources divergent sur la place de marché exacte (Open VSX côté Help Net Security, place de marché Cursor côté The Hacker News et Cursor), ce qui suggère une publication sur Open VSX consommée par Cursor.

Sources :thehackernews.com helpnetsecurity.com opensourcemalware.com

08 / 10ÉlevéeAttaque

Binance : 6,3 milliards de dollars volés, la plus grande attaque crypto jamais enregistrée

Concerné: Plateforme d'échange Binance, portefeuilles sur dix chaînes de blocs
Correctif: Sans objet. Binance a suspendu dépôts et retraits, révoqué les autorisations de l'adresse concernée et annoncé une couverture des pertes par son fonds SAFU.

Ce qui s'est passé: L'attaque ne repose pas sur le vol d'une clé privée. Selon Binance, un ordinateur portable d'ingénieur DevOps a été compromis, ce qui a donné accès à un conteneur de service, puis permis de soumettre des transactions de retrait non autorisées. Le co-directeur général Richard Teng insiste : ni un simple usage des droits d'un ingénieur, ni un clic unique, mais un processus complexe, avec d'autres points de compromission encore à l'étude.
Ce que ça change: Le plus gros vol de l'histoire des cryptomonnaies, environ quatre fois le piratage de Bybit de février 2025. Deux cabinets d'analyse de chaîne, TRM Labs et Chainalysis, attribuent l'opération à TraderTraitor, unité nord-coréenne aussi suivie sous les noms Lazarus et APT38, avec un degré de confiance élevé. Binance n'a pas attribué publiquement.
Ce qu'il faut faire: Pour les organisations exposées, le modèle d'attaque se transpose directement : un poste d'administrateur ou de développeur qui atteint un plan de contrôle financier devient la cible prioritaire. Segmentation stricte entre postes de travail et environnements de production, authentification matérielle, approbations multiples hors bande pour les opérations de retrait, surveillance comportementale des transactions et des accès aux conteneurs, et journalisation immuable des actions d'administration. Côté particuliers, considérer que les fonds laissés sur une plateforme centralisée restent exposés au risque de contrepartie.
Ce qui reste incertain: Le montant a évolué dans la journée (5,8 puis 6,3 puis 6,36 milliards), et les avoirs gelés bougent encore. L'attribution à la Corée du Nord est une évaluation de sociétés d'analyse privées, pas une attribution gouvernementale. Le détail technique de la compromission du poste et du conteneur n'est pas publié.

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

09 / 10ÉlevéeVulnérabilité

Drupal Commerce Core : CVE-2026-118539 exploitée sur plus de 42 000 boutiques en ligne

Concerné: Module contrib Commerce Core pour Drupal, versions 3.x antérieures à 3.3.13 et toutes versions antérieures à 8.x-2.41. Plus de 42 000 sites l'utilisent selon les statistiques de Drupal.
Correctif: Oui, Commerce Core 3.3.13 ou 8.x-2.41 et au-delà.

Ce qui s'est passé: Commerce Core ajoute un panier et un tunnel de commande aux sites Drupal. Certaines routes et certains champs ne vérifient pas correctement qui a le droit d'y accéder. Un visiteur non authentifié peut donc atteindre des fonctions réservées, ce qui peut conduire à consulter ou manipuler des commandes. L'éditeur demande explicitement aux marchands d'auditer leurs commandes pour détecter des incohérences.
Ce que ça change: Selon la configuration, accès à des données de commandes (donc de clients), modification d'états de paiement ou de montants, et dans les cas les plus favorables à l'attaquant, obtention gratuite de biens ou de services. Drupal évoque un impact financier direct pour le marchand.
Ce qu'il faut faire: Mettre à jour le module immédiatement, puis auditer les commandes des dernières semaines (montants, statuts de paiement, adresses de livraison). Vérifier les comptes administrateurs récemment créés et les journaux d'accès aux routes Commerce. Si la mise à jour n'est pas possible, restreindre l'accès aux routes concernées par règle de reverse proxy. La même journée de publication comptait 38 avis Drupal, dont près d'une douzaine classés critiques : la revue complète du parc de modules est justifiée.
Ce qui reste incertain: Drupal ne précise ni le mode opératoire des attaques, ni les acteurs, ni le nombre de sites touchés, ni si la faille a servi de zero-day avant le correctif. Aucun score CVSS n'est disponible à ce stade.

Sources :securityweek.com thehackernews.com bleepingcomputer.com

10 / 10ModéréeVulnérabilité

TeamViewer : CVE-2026-111585, un hôte malveillant peut prendre le contrôle du poste du technicien

Concerné: Clients TeamViewer Windows, macOS, Linux et application Android de contrôle à distance ; composants Remote Management. Corrigé en version 15.83, avec des mises à jour pour plusieurs branches historiques.
Correctif: Oui, client 15.83 et mises à jour des branches anciennes, plus six correctifs d'élévation de privilèges locales dans les modules complémentaires Remote Management.

Ce qui s'est passé: Dans une session de contrôle à distance, l'hôte annonce la taille de son écran et le poste du technicien alloue un tampon mémoire en conséquence, sans plafond. Un hôte malveillant peut déclarer une surface de 32 768 par 32 768 pixels en 32 bits, ce qui dépasse la capacité d'un entier 32 bits et provoque des écritures hors limites. Aucune interaction particulière n'est nécessaire au-delà de l'acceptation de la session, et l'hôte peut refuser de négocier les codecs vidéo pour forcer ce chemin de décodage logiciel.
Ce que ça change: Plantage répété du client, et surtout exécution de code arbitraire sur le poste du technicien de support, avec ses privilèges. Or ces postes sont précisément ceux qui disposent d'accès larges et d'outils d'administration. Le schéma inverse est nouveau : ce n'est plus le technicien qui prend la main sur la victime, c'est la victime qui prend la main sur le technicien.
Ce qu'il faut faire: Mettre à jour en priorité les postes des équipes support et des prestataires, qui se connectent à des machines non maîtrisées. Restreindre les sessions sortantes aux identifiants attendus, journaliser les sessions entrantes, isoler les postes d'administration (bastion, compte dédié, pas de navigateur ni de messagerie). Surveiller les exécutions de processus inhabituels dans le contexte du client TeamViewer.
Ce qui reste incertain: La fiabilité de l'exploitation dépend de la version et de la présence d'un décodeur matériel. Aucune exploitation observée à ce jour, mais la fenêtre entre publication et armement est courte sur ce type de produit.

Sources :securityweek.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