Diffusée via Cursor, la version 2.1.313 de Claude Code installait la clé SSH d’un attaquant et un tunnel persistant. Voici comment vérifier si vous êtes touché.
Le post Claude Code : une version piégée de l’extension a ouvert une porte dérobée SSH chez des utilisateurs de Cursor a été publié sur IT-Connect.
Une version piégée de l’extension Claude Code pour Visual Studio Code a été distribuée le 29 octobre dans la boutique Cursor. Elle installait une porte dérobée SSH persistante. Même si le problème a été résolu, l’extension frelatée a été installée par environ 5 000 personnes et pose de nouveau la question des chaînes d’approvisionnement.
Dans la journée du 29 octobre, quelque part entre 10h27 et 21h35 (heure de Paris), une version vérolée de l’extension Claude Code pour VS Code a été distribuée dans la boutique de Cursor. Estampillée 2.1.313, elle est restée suffisamment de temps en ligne pour avoir été téléchargée. Les 5 000 personnes concernées sont actuellement contactées, a indiqué Cursor.
L’éditeur dit avoir supprimé la version, arrêté intégralement sa boutique d’extensions, audité les accès, renouvelé ses clés, reconstruit la boutique et fait mettre hors ligne le serveur de l’attaquant par son hébergeur. Les différents contrôles n’ont révélé aucune autre extension modifiée.
Le principal point flou dans cette histoire est que l’on ne sait pas exactement quand tout a commencé. Tout dépend de qui raconte l’incident.
Chez Phorion par exemple, l’attaque est présentée comme une compromission de la fiche officielle sur Open VSX, la marketplace ouverte de la Fondation Eclipse pour l’écosystème des éditeurs API compatibles avec VS Code. Phorion affirme également qu’Anthropic a retiré la version 2.1.313 d’Open VSX, de npm et même du Marketplace de Microsoft pour VS Code.
OpenSourceMalware, qui a publié la première analyse, indique que l’échantillon analysé provenait bien d’Open VSX. Le site en a déduit une diffusion par npm et le Marketplace de Microsoft en se basant sur un constat : la version 2.1.313 n’y figurait plus. Il précise que la provenance de l’artefact n’est pas établie et que ses conclusions ne prouvent pas une compromission de la distribution officielle d’Anthropic. Et pour cause, les retraits de npn et du Marketplace peuvent n’être qu’une mesure de sécurité, dans l’optique de supprimer toutes les versions 2.1.313 existantes. Problème, pour l’instant, ni Anthropic ni Microsoft n’ont réagi publiquement à l’incident.
Chez StepSecurity, on affirme que la compromission a commencé chez Open VSX avant d’être étendue à Cursor, puisque la boutique de ce dernier est un intermédiaire dont la base se synchronise avec le registre Open VSX. Les contrôles de sécurité appliqués sur ce dernier sont limités, avec un examen portant sur les motifs malveillants les plus connus. Ce qui signifie que l’extension vérolée aurait passé non seulement ces contrôles, mais également ceux de Cursor, plus poussés.
Illustration de ces incertitudes, The Hacker News a mis à jour son article pour indiquer que la compromission venait de Cursor seul. Pour cela, il faudrait que l’infrastructure propre à Cursor ait été compromise, ce que l’éditeur ne dit pas clairement. Cependant, le nombre d’actions entreprises pourrait aller dans ce sens, Cursor ayant renouvelé ses clés et reconstruit son magasin.
Si on ne sait pas comment tout a commencé ni qui est réellement concerné, on connait en revanche mieux le fonctionnement du code malveillant, les analyses de Phorion, OpenSourceMalware et Cursor s’accordant sur les détails.
L’extension contient ainsi un chargeur de 66 lignes, placé en tête du fichier extension.js. Il se lance dès le chargement du module, sans nécessiter d’action de l’utilisateur et donc avant même de lancer une conversation avec Claude. Ce chargeur ajoute une clé publique SSH liée à l’attaquant dans le dossier ~/.ssh/authorized_keys, pour lui donner un accès distant permanent sur l’ordinateur de la victime. La clé est étiquetée « svc-telemetry » pour paraitre anodine.
Le code vérifie ensuite que le service SSH est présent et actif. Dans le cas contraire, il tente de l’activer. Sur la plupart des Mac et PC sous Windows, l’étape échoue, non seulement faute de droits administrateur mais aussi car le code contient des erreurs. Sur Linux, le code réussit.
Le malware cherche ensuite à faire établir une connexion sortante vers le serveur de l’attaquant et à la maintenir ouverte. L’attaquant n’a alors plus qu’à emprunter ce tunnel en sens inverse pour atteindre la porte SSH et entrer avec sa clé privée, ouvrant la voie vers un terminal et la possibilité de lancer des commandes.
Le code installe aussi un petit script qui se relance à chaque démarrage de l’ordinateur et retente la connexion une fois par minute. Sur macOS, ce script se déguise en composant Apple (com.apple.sysmond), sur Windows en tâche Sysmon ou en script dans le dossier Démarrage, et sur Linux en tâche planifiée. La désinstallation de l’extension ne suffit donc pas. Le code envoie enfin une fiche descriptive de la machine avec nom de l’ordinateur, utilisateur, système, adresse IP publique, adresse électronique Git et dossier de travail.
Cette charge utile ne vole donc en elle-même aucune information cruciale, mais elle prépare le terrain. Le danger vient avant tout de ce que le pirate peut réaliser une fois la connexion établie via SSH.
La fiche de Cursor sur l’incident, publiée hier soir, mentionne uniquement des vérifications à faire pour macOS et Windows. L’éditeur ne le dit pas explicitement, mais il semble que Linux ne soit curieusement pas concerné, malgré les détails techniques allant pourtant dans ce sens.
Faute de script officiel, les analyses de Phorion et OpenSourceMalware présentent une série de commandes bash. Dans les trois cas cependant, si une preuve de compromission est détectée, il faudra effectuer plusieurs manipulations. Mais la recommandation est claire : réinstaller complètement la machine sera l’option la plus sûre.
Cursor indique dans son billet que les 5 000 personnes (environ) qui ont installé l’extension modifiée sont contactées pour être averties du problème.
L’entreprise de paris en ligne a dû suspendre l’accès à sa plateforme pendant un peu moins d’une heure : des pirates ont pu accéder aux comptes de certains de ses utilisateurs et récupérer les sommes accumulées. Polymarket rejette le problème sur un prestataire tiers. Celui-ci pourrait être DebugBear.
Ce jeudi 29 octobre, Polymarket a annoncé avoir mis temporairement sur pause l’utilisation de sa plateforme internationale Polymarket.com, sur laquelle elle n’a permis pendant un peu moins d’une heure à ses utilisateurs que d’annuler leurs paris.
« Polymarket.com : La plateforme de change fonctionne actuellement en mode « annulation uniquement » et les opérations des relais sont suspendues le temps que nous menions une enquête sur un incident », informait le compte X de l’entreprise hier soir. Une heure plus tard, elle affirmait que le problème était résolu après avoir expliqué : « L’un de nos prestataires tiers a été victime d’une intrusion, et nous avons signalé ce fait aux autorités compétentes ».
Mais l’incident semble avoir fait perdre leurs portemonnaies à certains utilisateurs de la plateforme. Si l’entreprise n’a pas explicitement confirmé que certains ont perdu de l’argent, elle assurait que « Toute personne ayant subi un préjudice sera indemnisée intégralement ».
Selon CNBC, Polymarket a expliqué à ses utilisateurs sur Discord que les personnes qui ont perdu moins de 10 000 dollars se verront remboursées d’ici le 30 octobre. Pour ceux dont la somme perdue est plus importante, ils devront d’abord signer une décharge pour pouvoir récupérer leur argent. L’entreprise d’analyse de données Bubblemaps a estimé à plus de 700 le nombre d’utilisateurs touchés, et évoque le chiffre de 2,7 millions de dollars volés.
Selon des sources de Reuters, le problème viendrait de l’utilisation des outils de DebugBear. En parallèle de l’incident, cette entreprise qui fournit des outils de monitoring pour les sites web a posté un message sur X expliquant que « Nous sommes actuellement confrontés à un incident de sécurité », et demandant à ses utilisateurs : « si vous utilisez notre produit RUM, veuillez supprimer le code d’intégration de votre site web ». Selon CNBC, comme DebugBear est basée au Royaume-Uni, c’est aux autorités de ce pays que Polymarket a indiqué le problème. DebugBear n’a pas répondu aux sollicitations de nos confrères pour en savoir plus.
Ce problème de sécurisation des portemonnaies des utilisateurs de Polymarket ne va pas arranger ses relations avec les autorités à travers le monde. Rappelons que l’activité de Polymarket est mise en cause par l’État de New York pour activité illégale de jeux d’argent.
En France, le site de l’entreprise est bloqué par les principaux fournisseurs d’accès à Internet via une demande de l’Autorité nationale des jeux (ANJ), qui considère qu’il « fait la promotion d’une offre illégale de jeux d’argent et de hasard ». En septembre, l’entreprise faisait du lobbying en Europe pour assurer aux autorités que son activité était plus à ranger dans celles des « marchés prédictifs » que de sites de paris en ligne.
Le département américain de la Sécurité intérieure (DHS) a des fuites. Et pas qu’un peu. Des données personnelles sur plus de 41 000 employés et prestataires sont dans la nature, tout comme des informations sensibles sur des programmes de surveillance.
Un groupe de pirates se faisant appeler « Department of Peace » aurait obtenu les données volées sur les serveurs du DHS, puis transmises au site Distributed Denial of Secrets (DDoSecrets) qui a publié une archive sous le nom « Icepick ». Les fichiers, mis à jour pour la dernière fois le 19 août, ont été consultés par WIRED.
Le ministère confirme par le biais d’un porte-parole avoir eu connaissance d’une « possible intrusion » et travaille à y remédier « rapidement et efficacement ». « Nous prenons au sérieux toutes les menaces visant la sécurité de nos employés et de nos agents et veillerons à ce que tous soient correctement protégés », ajoute-t-il.
DDoSecrets explique que les données proviennent du système d’authentification Okta du DHS. L’entreprise dément toute intrusion : « Nous avons pris connaissance de ces informations. Okta est sécurisé et nous n’avons aucune preuve que nos données ou nos systèmes aient été compromis ». Quoi qu’il en soit, la fuite expose les données (adresses email, numéros de téléphone, adresses des bureaux) de 41 000 employés et fournisseurs du ministère.
Depuis le retour de Donald Trump à la Maison-Blanche, le DHS, qui chapeaute notamment la police de l’immigration ICE et les services de protection des frontières, s’est transformé en citadelle du secret. Au cœur de la politique migratoire radicale de l’administration, le DHS est critiqué pour ses méthodes musclées de surveillance des opposants et pour l’opacité entourant ses agents et ses opérations.
« Ils ont nos informations, il est donc normal que nous ayons les leurs », se justifient les hackers de Department of Peace. La fuite dépasse cependant l’annuaire d’adresses ; elle révèle aussi les noms de responsables hiérarchiques et plus de 55 000 groupes qui définissent les accès aux outils et systèmes internes du DHS.
Les noms de ces groupes permettent d’identifier les logiciels utilisés – la fuite contient des références à des outils IA comme ChatGPT, Gemini, Copilot et Grok – les programmes de surveillance (comme la plateforme Falcon de Palantir) et certaines opérations (notamment de surveillance et de couverture) auxquels les personnels ont accès.
Cette fuite pourrait par exemple révéler des agents liés aux activités de l’ICE en charge de l’immigration. Toutes ces informations permettent de reconstituer l’organigramme du DHS. La base de données peut être consultée sur un site créé par la chercheuse en sécurité maia arson crimew, qui estime que malgré l’intimidation exercée par le DHS, il ne faut pas « renoncer à enquêter sur eux ».
Alexander Leslie, spécialiste de la sécurité chez Recorded Future spécialisée sur les cybermenaces, explique à WIRED que « si ces données sont authentiques et à jour, elles constituent une source de renseignement d’une valeur exceptionnelle pour quiconque cherche à infiltrer le DHS. »
« [La] valeur [de ces données] augmente considérablement lorsqu’elles sont croisées avec des informations déjà compromises, des données commerciales et d’autres renseignements. Un adversaire pourrait passer des mois à exploiter ces liens pour repérer des personnels vulnérables, préparer des usurpations d’identité convaincantes ou compromettre des enquêtes en cours. »
Cette fuite rappelle celle du FBI orchestrée en septembre dernier par les pirates de ShinyHunters. Ils n’ont cependant jamais publié les données subtilisées. La situation ici est donc différente, puisque les informations du DHS sont disponibles en ligne. Le réseau social Bluesky a d’ailleurs bloqué les liens vers l’archive.
Erreur 403 | #99 - PHP2Shell exploitées et les modèles IA backdoorés
Failles PHP2Shell exploitées, LiteLLM de nouveau compromis, modèle Qwen tentant d’envoyer un fichier vers Pékin, faille Brotli, 11,7 millions de comptes Capcom exposés, etc.
Découvrez REA, le serveur MCP qui permet à Claude Code ou Codex de piloter Ghidra et d'autres outils : installation, cadre légal et démo de rétro-ingénierie.
Le post REA : j’ai testé la rétro-ingénierie pilotée par l’IA avec Claude Code a été publié sur IT-Connect.
Les failles PHP2Shell et Fragnesia (noyau Linux) sont exploitées ensemble pour obtenir un accès root sur 24 firewalls. L'agence CISA a publié une alerte.
Le post Fragnesia et PHP2Shell : la chaîne d’attaque qui a offert un accès root sur 24 firewalls a été publié sur IT-Connect.
Le ransomware C3RB3R s'attaque aux NAS Synology pour chiffrer les données après les avoir compromis en exploitant des failles DSM. Voici comment vous protéger.
Le post NAS Synology : une vague d’attaques du ransomware C3RB3R, voici comment vous protéger a été publié sur IT-Connect.
WordPress 7.1.4 corrige 22 vulnérabilités, dont une faille d'exécution de code à distance liée au processus de mise à jour. Voici ce qu'il faut retenir.
Le post WordPress 7.1.4 corrige 22 vulnérabilités, dont 1 faille menant à l’exécution de code à distance a été publié sur IT-Connect.
L’entreprise de marketing israélienne Discover-Tech a participé à une attaque zéro-clic installant un logiciel espion via des publicités. Elle vise particulièrement les utilisateurs du réseau Starlink, selon des sources de l’agence de presse Reuters.
L’agence de marketing israélienne Discover-Tech, impliquée dans la diffusion d’un logiciel espion via une attaque zéro-clic, est aussi une des entreprises qui enchérissent le plus pour obtenir des publicités sur le réseau Starlink. Ainsi, elle serait en capacité de localiser assez facilement des utilisateurs de ce réseau qui permet à ses utilisateurs de passer à travers les surveillances gouvernementales.
Mi-octobre, on apprenait que Discover-Tech avait mis au point une attaque zéro-clic installant un logiciel espion via la publicité ciblée. Les chercheurs de Citizen Lab et de Cinfiant avaient constaté que des appareils des équipes du média Al Jazeera avaient été choisis pour être infectés avec un logiciel espion attribué à la société Candiru.
En parallèle, des chercheurs de l’entreprise de sécurité Trend Micro publiaient un rapport sur les activités d’un groupe nommé SHADOW-EARTH-79 qui utilise aussi la publicité ciblée pour « suivre et établir le profil de personnes se trouvant dans des zones de conflit, des États soumis à des sanctions et d’autres lieux sensibles à travers le monde ».
Selon plusieurs sources de Reuters, Discover-Tech est l’entité réelle qui se trouve derrière le groupe SHADOW-EARTH-79. Les chercheurs de l’unité TrendAI de Trend Micro ne citent pas le nom de l’entreprise israélienne : cette unité s’est donné des règles très prudentes concernant l’attribution des menaces cyber qu’elle découvre. Mais six sources ont confirmé à l’agence de presse que Shadow-Earth-79 est le nom de code utilisé par TrendAI pour désigner Discover-Tech.
Selon TrendAI, ce groupe est sur le trafic des adresses IP de Starlink, ce groupe est la deuxième entreprise concernant le nombre d’enchères gagnées pour placer des publicités (12,9%) derrière l’entreprise américaine de marketing ciblé Steelhouse qui a obtenu 38,4 % des enchères sur une période de 90 jours étudiée.
TrendAI a pu observer que ce groupe avait gagné des enchères publicitaires dans 150 pays concernant le trafic des adresses IP de Starlink. « Certains de ces pays (le Cameroun, la Syrie, le Soudan, la Birmanie et la Libye) sont des pays où Starlink est officiellement interdit ou soumis à des restrictions réglementaires », remarquent-ils dans leur rapport. Mais on peut y voir qu’y figurent aussi la France, l’Italie ou l’Espagne où le groupe est premier enchérisseur concernant les pubs du trafic de Starlink.
Concernant les enchères publicitaires sur tout le trafic (et non plus seulement Starlink), selon TrendAI, ce groupe est « le premier enchérisseur dans 49 pays où les données publicitaires font l’objet d’enchères ». « Dans plusieurs cas, il détient une part incroyablement dominante de l’ensemble des enchères, ce qui ne correspond pas à un achat publicitaire concurrentiel normal », ajoutaient les chercheurs en cybersécurité. Ils pointaient notamment son « quasi monopole » en Hongrie, en Israël, en Égypte, en Azerbaïdjan et au Venezuela où le groupe fait entre 72 % et 91 % des offres.
Le rapport de TendAI concluait que « les éléments de preuve recueillis indiquent, avec un niveau de confiance modéré à élevé, que la présence publicitaire de SHADOW-EARTH-79 sert d’infrastructure de ciblage et de suivi plutôt que d’opération publicitaire commerciale ».
Contactées par Reuters, Discover-Tech mais aussi SpaceX n’ont pas répondu aux demandes de commentaires sur le sujet de nos confrères.
En mai dernier, Intelligence Online expliquait qu’une autre entreprise israélienne, Targeteam qui a aussi un bureau à Chypre, allait dévoiler un nouvel outil dédié à la désanonymisation des utilisateurs du système Starlink. Cette entreprise est la « nouvelle aventure business d’un vétéran du secteur cyber israélien et légende de l’export, Ron Zilka », selon nos confrères. De son côté, le média israélien Haaretz parlait de deux entreprises du même pays capables de localiser les terminaux satellitaires de Starlink alors que ce système permet, par exemple, à l’armée ukrainienne de se défendre face à l’envahisseur russe. Mais récemment, le pays de Volodymyr Zelensky a accusé Starlink d’avoir restreint l’accès à Internet de ses forces militaires.
Un paquet ICMP suffit pour exécuter du code avant Secure Boot sur une machine en boot PXE. Voici ce qu'il faut savoir sur la faille UEFI CVE-2026-97631.
Le post Faille UEFI CVE-2026-97631 : un paquet ICMP suffit pour exécuter du code avant le Secure Boot a été publié sur IT-Connect.
Une faille de sécurité critique a été découverte dans la plupart des firmwares UEFI utilisés dans les serveurs. Bien qu’elle ne requière pas d’authentification, il faut remplir plusieurs conditions pour l’exploiter, dont l’utilisation du PXE pour le démarrage réseau.
Quand on allume un ordinateur, un petit logiciel est d’abord chargé d’initialiser le matériel et de préparer les conditions au lancement du système d’exploitation. On l’a historiquement appelé « BIOS » (Basic Input/Output System), mais il s’agit depuis longtemps d’un microgiciel (firmware) nommé UEFI (Unified Extensible Firmware Interface). Parmi les fonctions apportées par ce firmware plus moderne, des fonctionnalités réseau en standard.
Dans la grande majorité des cas, les constructeurs n’écrivent pas leur UEFI depuis zéro. Ils se basent sur des travaux existants, en particulier EDK II, une base de code libre maintenue par le projet TianoCore. Presque tous les éditeurs de firmware – dont AMI, Insyde et Phoenix – s’en servent copieusement, y compris Project Mu, une variante renforcée (durcie) d’EDK II maintenue par Microsoft.
Or, c’est dans cette base EDK II que réside la faille.
La faille en question, estampillée CVE-2026-97631, réside dans la fonction de démarrage réseau, ou PXE. Quand elle est activée, la machine ne démarre pas sur son disque, elle récupère son système sur un serveur distant. Ce mécanisme est largement utilisé dans les centres de données pour installer ou réinstaller en masse des serveurs.
Pendant ce démarrage réseau, le pilote PXE (NetworkPkg ou UefiPxeBcDxe) attend d’éventuels messages d’erreur ICMP. S’il en reçoit, il les copie dans une zone de mémoire de taille fixe, précisément 504 octets. Il existe deux variantes du code pour le réseau, une pour IPv4, l’autre pour IPv6. C’est là que réside le problème : dans les deux cas, la copie en mémoire continue même si le message d’erreur dépasse les 504 octets. En outre, le pointeur de destination avance sur la base du total cumulé au lieu de la taille du seul fragment copié.
Dans le scénario d’une attaque, un pirate peut donc exploiter ce mécanisme pour écrire un message trop long, avec des octets choisis en dépassement de la zone prévue en mémoire. Rien en amont ne limite la taille du message, renforçant l’ampleur du problème. Le pirate peut donc glisser des instructions dans ces octets, qui seront alors exécutées par le firmware UEFI.
La faille CVE-2026-97631 affiche un score CVSS 4.0 de 9,5 sur 10, soit très près du maximum. Le seul facteur limitant la portée de l’exploitation est l’obligation d’utiliser PXE, ce qui n’arrive que dans des environnements spécifiques, et a priori pas chez le grand public. Autre condition tout de même, il faut connaitre la version exacte du firmware que l’on veut attaquer.
Si ces deux conditions sont remplies, tout ce que le pirate a à faire est d’envoyer un message d’erreur ICMP spécialement conçu pour y glisser des commandes. Aucune authentification n’est nécessaire. De plus, puisque les commandes sont exécutées à un stade très précoce de la chaine de démarrage, ni Secure Boot ni le démarrage mesuré n’ont le temps d’intervenir.
C’est l’accumulation de ces deux éléments – aucune authentification et déclenchement avant tous les mécanismes de sécurité – qui donne son score de gravité à la faille. S’il parvient à exploiter la faille, le pirate a même le choix : se servir de la corruption mémoire pour provoquer une exception processeur et le blocage du démarrage, ou l’exécution du code qui aura alors le niveau de privilège le plus élevé. Même si ce code ne survit pas lui-même au redémarrage, il peut être utilisé pour installer des composants persistants.
La faille a été découverte par Alex Matrosov d’Anthropic et Dan Holmes-Mitra de Google, qui ont également fourni la solution recommandée. On ne sait pas quand cette découverte a eu lieu, mais la communication de l’équipe de TianoCore a entrainé une réservation de l’identifiant CVE le 24 septembre.
En théorie, les détails d’une telle vulnérabilité restent secrets jusqu’à ce que ces correctifs soient disponibles, mais il y a eu une erreur. Ars Technica parle de « divulgation ratée » : AMI a publié fin septembre une demande de modification publique qui décrivait la faille et contenait le correctif. Alex Matrosov et Dan Holmes-Mitra s’en sont aperçus, ont prévenu TianoCore, qui a alors décidé de rendre public l’avis de sécurité le 22 octobre.
En outre, bien que le correctif ait effectivement été proposé, les différentes parties s’étaient mises d’accord pour attendre une publication des détails en janvier. L’erreur d’AMI a précipité le calendrier, car le délai devait servir aux éditeurs de firmwares à proposer de nouvelles moutures. Il faut désormais surveiller ce que des entreprises comme Dell, Lenovo, SuperMicro ou encore HPE publient. Selon les cas, le mécanisme de mise à jour peut être plus ou moins complexe, mais il réclame dans tous les cas un temps d’immobilisation du serveur.
Les firmwares concernés sont a priori très nombreux, sur la base du code vulnérable d’EDK II. Ars Technica a interrogé Intel et Arm sur la portée du problème, les deux entreprises affirmant que leurs produits ne sont pas concernés. Nos confrères indiquent cependant que l’une comme l’autre utilisent amplement EDK II comme base de référence. Dans le cas d’Intel, le dépôt GitHub pour les binaires FSP (Firmware Support Package) mentionne clairement EDK II et TianoCore. Même chose pour Arm. D’autres entreprises comme AMD, Microsoft et Amazon n’ont pas répondu aux questions de nos confrères, mais elles sont très probablement concernées aussi.
La méfiance est donc de mise. Il est recommandé de dresser l’inventaire des machines utilisant PXE. Si parmi elles certaines l’ont activé sans l’utiliser, mieux vaut le désactiver pour supprimer la surface d’attaque. Si la fonction est nécessaire, il est recommandé de garder le trafic de démarrage sur un segment isolé du réseau, de surveiller les pages de support des constructeurs ou des éditeurs impliqués et de filtrer les messages ICMP inattendus.
Apprenez pourquoi le DNS est un canal d'exfiltration puissant pour les cybercriminels, et les mesures pour le détecter et le bloquer sur votre infrastructure.
Le post Exfiltration DNS : comprendre, détecter et bloquer un canal de fuite discret a été publié sur IT-Connect.
Une faille de sécurité critique située dans le composant CDP Coordinator a été patchée dans Veeam Backup & Replication 13 : CVE-2026-108142. Voici les patchs.
Le post Veeam Backup & Replication 13 (CVE-2026-108142) : une faille critique exploitable sans authentification a été publié sur IT-Connect.
