L'actu cyber du jour

mercredi 4 novembre 2026

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

Lecture : 17 min

L'essentiel

Deux vulnérabilités viennent d'entrer au catalogue KEV de la CISA en moins de 24 heures, et les deux sont massivement déployées : WordPress Core (CVE-2026-119977, CVSS 8,1) avec 13 095 attaques bloquées par Wordfence en 24 heures, et la chaîne Ivanti Connect Secure toujours exploitée en zero-day avec plus de 5 000 appliances encore exposées sur Internet.
La journée est dominée par les failles de composants intermédiaires, pas par les applicatifs métier : Active Storage de Ruby on Rails (CVSS 9,8), le code de copie de pages du noyau Xen (évasion de VM vers dom0), l'autoupdate de cPGuard, le pare-feu Barracuda. Ce sont les briques que personne ne regarde et que tout le monde exécute.
L'IA est désormais simultanément l'outil de l'attaquant, la cible et le détecteur : Claude (Anthropic) a trouvé la faille Xen, le framework Artex automatise les intrusions contre les plateformes de développement IA, et Binance révèle qu'un de ses propres outils d'IA internes a servi à pivoter vers les systèmes de signature de portefeuilles.
Le modèle économique de la criminalité s'est déplacé vers les secrets d'IA : une douzaine de plateformes de développement IA ont été compromises en un mois pour voler des jetons d'accès, avec un marché de revente structuré et des clés réutilisées par plusieurs groupes.
Le vibe coding produit des fuites de données à l'échelle industrielle : sur 34 545 projets Lovable adossés à Supabase, 24 664 bases répondaient sans aucune authentification, dont des passeports et 200 000 messages privés.
L'OT et le froid restent la surface la plus fragile : après la vague de septembre en France, plus de 115 magasins européens ont été touchés, avec des consignes portées à 50 °C, et environ 13 000 systèmes de réfrigération européens tourneraient encore sur des logiciels vulnérables.

01 / 10CritiqueVulnérabilité

WordPress Core : la faille de mise à jour est exploitée en masse, la CISA impose un correctif avant vendredi

Concerné: WordPress Core, sur les versions antérieures à 7.1.4. La faille se situe dans le processus de mise à jour du coeur, pas dans un greffon ni dans un thème.
Correctif: Oui, WordPress 7.1.4, publié le 28 octobre 2026.

Ce qui s'est passé: Lors d'une mise à jour complète du coeur, WordPress télécharge l'archive, l'extrait dans un répertoire temporaire accessible depuis le web, puis déplace les fichiers. Entre le moment où le fichier est vérifié et celui où il est utilisé, un attaquant peut faire changer la cible du lien : c'est une condition de course de type TOCTOU (« time-of-check to time-of-use »). Comme le chemin de dépôt temporaire est prévisible et joignable par HTTP, un attaquant peut déposer ou faire exécuter un fichier PHP pendant cette fenêtre.
Ce que ça change: Exécution de code PHP sur le serveur web, donc prise de contrôle du site, vol de la base, de la configuration et des jetons d'administration, puis rebond vers l'hébergement mutualisé. La fenêtre est étroite et la complexité élevée, mais elle est déclenchable sans compte, ce qui explique l'automatisation.
Ce qu'il faut faire: Passer immédiatement en 7.1.4 ou ultérieur. Vérifier la version réelle en base (wp core version) et pas seulement dans l'interface. Interdire l'exécution de PHP dans wp-content/uploads et wp-content/upgrade. Surveiller les requêtes HTTP vers wp-admin/update-core.php et vers les répertoires upgrade ou upgrade-temp-backup, ainsi que l'apparition de fichiers PHP à date de modification récente hors des répertoires de greffons.
Ce qui reste incertain: Le vecteur exact utilisé par les attaquants en production n'est pas détaillé par la CISA. Le score CVSS de 8,1 n'est pas rattaché à une source explicite dans les articles consultés. On ignore le volume de sites effectivement compromis, les 13 095 attaques bloquées étant des tentatives et non des succès.

Sources :bleepingcomputer.com thehackernews.com cisa.gov

02 / 10CritiqueVulnérabilité

Ivanti Connect Secure : trois failles enchaînées, root sans authentification, et 5 000 appliances encore exposées

Concerné: Ivanti Connect Secure (ICS), passerelle d'accès distant. Les versions corrigées ne sont pas détaillées dans les sources consultées.
Correctif: Oui, Ivanti a publié des correctifs pour les trois failles (octobre 2026 pour CVE-2026-104935, puis novembre 2026 pour les deux autres). Les numéros de version ne sont pas précisés dans les sources consultées.

Ce qui s'est passé: La première faille permet de contourner l'authentification de la passerelle. Une fois à l'intérieur, l'attaquant enchaîne deux autres défauts pour élever ses privilèges et déposer des fichiers, jusqu'à obtenir l'exécution de commandes en root sur une appliance pourtant à jour. Le détail le plus dérangeant est la discrétion de la méthode : pas de porte dérobée installée, donc rien à trouver sur le disque, et les journaux ont été altérés pour tromper l'outil d'intégrité d'Ivanti.
Ce que ça change: Prise de contrôle totale de la passerelle d'accès distant, donc accès au réseau interne de l'entreprise, capacité d'interception du trafic VPN et de vol d'identifiants. C'est le point d'entrée idéal pour une intrusion ciblée ou un rançongiciel.
Ce qu'il faut faire: Appliquer les trois correctifs sans attendre, puis réinitialiser les secrets de l'appliance. Ne pas se fier à l'Integrity Checker Tool seul : comparer les journaux à une source externe (syslog distant, SIEM) et rechercher des requêtes répétées vers les points d'entrée d'administration. Restreindre l'interface d'administration à des adresses internes, activer l'authentification à deux facteurs et surveiller les connexions VPN inhabituelles.
Ce qui reste incertain: Les descriptions divergent selon les sources. La CISA classe CVE-2026-111357 comme « authentification manquante pour une fonction critique » et CVE-2026-118527 comme « génération de nombres ou d'identifiants prévisibles », tandis que BleepingComputer décrit la première comme une élévation de privilèges et la seconde comme un dépôt de fichier par un attaquant authentifié. Les deux lectures ne se recoupent pas totalement et méritent vérification dans les avis Ivanti d'origine.

Sources :bleepingcomputer.com cisa.gov

03 / 10CritiqueVulnérabilité

Ruby on Rails : une faille 9,8 dans Active Storage permet de lire et écrire n'importe quel fichier du serveur

Concerné: Toutes les versions d'Active Storage antérieures à 8.0.5.2, et les versions 8.1 antérieures à 8.1.4.1. Les séries antérieures à 8.0 ne sont plus maintenues et ne recevront pas de correctif. Trois conditions cumulatives : le processeur de variantes est :mini_magick (valeur par défaut pour les applications en load_defaults 6.1 ou antérieur), la politique de sécurité ImageMagick du serveur ne bloque pas les codeurs concernés (celles de Debian et Ubuntu ne les bloquent pas), et l'application accepte des téléversements venant d'utilisateurs non fiables.
Correctif: Oui, Rails 8.1.4.1 et 8.0.5.2, qui embarquent en plus une politique de sécurité ImageMagick.

Ce qui s'est passé: ImageMagick choisit le module de traitement (un « codeur ») en fonction du contenu du fichier, pas de son extension. Certains codeurs, comme MSL, lisent et écrivent des fichiers désignés à l'intérieur du script fourni. Active Storage n'impose aucune limite sur les codeurs utilisables : la seule barrière était la politique ImageMagick du serveur, souvent permissive. Un fichier SVG suffit à atteindre le codeur MSL. L'analyseur d'Active Storage se déclenche au moment de l'attachement, donc l'upload seul suffit.
Ce que ça change: Écriture de fichiers arbitraires sur le serveur, et, si le service Disk est utilisé, lecture de tout fichier accessible par l'application, notamment secret_key_base et les identifiants d'autres systèmes. À partir de là, l'attaquant peut forger des cookies signés, usurper des sessions ou pivoter vers les services liés. L'exécution de code à distance est atteignable en écrivant un fichier interprété.
Ce qu'il faut faire: Mettre à jour vers 8.1.4.1 ou 8.0.5.2. Vérifier config.active_storage.variant_processor : s'il vaut :mini_magick, la mise à jour est impérative. Vérifier que la nouvelle politique est bien chargée avec bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'. Restreindre les formats acceptés au niveau applicatif et ne jamais laisser un utilisateur non authentifié téléverser une image traitée par ImageMagick.
Ce qui reste incertain: Aucun CVE n'est encore attribué, donc les scanners de vulnérabilités ne remonteront pas la faille. On ignore le nombre d'applications exposées. La seconde faille corrigée (GHSA-v924-7rp8-4mxh, CVSS 8,8 selon Rails) repose sur la conservation de l'extension d'origine dans les noms temporaires passés à ImageMagick et FFmpeg.

Sources :thehackernews.com github.com

04 / 10CritiqueVulnérabilité

Xen : deux failles permettent à une VM invitée de lire et écrire la mémoire de dom0, et Claude les a trouvées

Concerné: Toutes les versions de Xen depuis 4.6. Les versions 4.5 et antérieures ne sont pas vulnérables. Des correctifs sont fournis pour xen-unstable, Xen 4.19.x et la branche 4.18.x / 4.17.x.
Correctif: Oui, par application des jeux de patches XSA-523 sur la branche stable. Aucune mitigation de contournement n'est proposée.

Ce qui s'est passé: Quand un invité enchaîne des copies de pages adjacentes, Xen met en cache des informations déjà validées pour aller plus vite. Les conditions de revalidation de ce cache étaient fausses : les numéros de page et les références de grant pouvaient être confondus (CVE-2026-102703), et le contrôle qui réserve la copie par numéro de page à la mémoire de l'appelant était mal placé (CVE-2026-102704). Résultat : un invité peut lire et écrire de la mémoire qui ne lui appartient pas.
Ce que ça change: Lecture et écriture arbitraires dans la mémoire des autres domaines, y compris dom0, le domaine qui gère l'hôte. C'est une évasion de VM complète : un client de cloud, un conteneur hébergé sur une VM ou une VM compromise peut atteindre les autres locataires du même hyperviseur et, à terme, l'hôte entier. Sur une infrastructure multi-tenant, l'impact sur la confidentialité est maximal.
Ce qu'il faut faire: Patcher tous les hyperviseurs Xen et redémarrer les hôtes, ce qui implique une migration des invités ou une fenêtre de maintenance. En attendant, réduire la densité de locataires non fiables sur un même hôte et cloisonner les charges sensibles. Surveiller les invités qui génèrent massivement des opérations grant copy vers des plages adjacentes.
Ce qui reste incertain: Aucune note CVSS officielle, donc la priorisation formelle est difficile. L'avis indique que la faille a été découverte par Anthropic à l'aide de Claude, puis validée par Stephan Lipp (Ada Logics) et rapportée indépendamment par l'équipe CodeAnt AI Security Research. La méthodologie exacte de découverte par le modèle n'est pas publiée, et l'on ignore depuis combien de temps la faille existe.

Sources :xenbits.xen.org thehackernews.com

05 / 10CritiqueAttaque

Binance : 6,34 milliards de dollars volés via un faux entretien d'embauche et un outil d'IA interne détourné

Concerné: Non applicable. L'attaque cible des postes de travail d'ingénieurs, la chaîne d'outils de développement (Homebrew, dépôts de code) et l'infrastructure de signature de portefeuilles de Binance.
Correctif: Sans objet côté victime. Binance indique avoir reconstruit le système de portefeuilles concerné et l'outil d'IA, remplacé les postes et révoqué les identifiants.

Ce qui s'est passé: La campagne démarre en juin 2026. Un ingénieur DevOps télécharge une installation Homebrew piégée en cherchant un outil de codage IA via un moteur de recherche. L'équipe sécurité détecte, remplace la machine et réinitialise les secrets, mais l'attaquant a déjà cartographié l'équipe et ses habitudes. En septembre, un deuxième ingénieur est approché par un faux directeur de projet : deux entretiens, dont un avec un faux PDG d'une société inexistante, puis un « exercice de codage » à installer sur le poste de travail. Le dépôt exécute du code à l'ouverture et remplace un composant légitime par une version malveillante. Le 20 octobre, l'attaquant utilise la machine infectée et un outil d'IA interne pour atteindre deux autres systèmes. Le 29 octobre, il déploie un conteneur avec les droits du premier ingénieur et lance le script.
Ce que ça change: Accès au service interne de signature de portefeuilles, transferts de XRP, SOL, OP et BTC depuis les portefeuilles chauds, et abus du mécanisme Ethereum EIP-7702 pour donner à un contrat contrôlé par l'attaquant des droits partiels d'exécution sur un portefeuille chaud. Le mécanisme étant inscrit on-chain, il continuait d'agir indépendamment de l'infrastructure de retrait, et le portefeuille étant protégé par calcul multipartite, Binance ne disposait d'aucune clé unique pour annuler la délégation immédiatement.
Ce qu'il faut faire: Considérer les recruteurs comme une surface d'attaque à part entière, et n'exécuter aucun exercice technique reçu par messagerie sur un poste de travail. Isoler les environnements de développement des systèmes de signature par une séparation réseau stricte et des jetons à portée limitée. Détenir une clé de secours ou une procédure d'urgence capable de révoquer une délégation on-chain sans dépendre du MPC. Surveiller les téléchargements d'installeurs de gestionnaires de paquets vers des domaines non officiels.
Ce qui reste incertain: Binance ne détaille pas comment l'outil d'IA interne a été utilisé pour pivoter, ce qui empêche d'évaluer si le défaut est dans l'outil ou dans ses droits d'accès. La Corée du Nord conteste publiquement l'attribution du FBI. Le montant total est celui annoncé par Binance ; environ 2,85 milliards ont été récupérés, le solde définitif n'est pas connu.

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

06 / 10CritiqueSupply Chain

cPGuard : une mise à jour automatique malveillante installe une porte dérobée sur près de 3 000 serveurs

Concerné: CPGuard versions 5.88.12 à 5.88.19, distribuées par le canal de mise à jour d'OpsShield. Correctif en 5.88.25 ou ultérieur. cPGuard est une suite de sécurité pour serveurs web Linux, utilisée avec cPanel, DirectAdmin et Plesk, et proposée par des hébergeurs comme Namecheap.
Correctif: Oui, version 5.88.25 ou ultérieure, qui retire la porte dérobée et les fichiers déposés. OpsShield annonce aussi une mise à jour pour supprimer les clés d'accès support précédemment installées.

Ce qui s'est passé: L'attaquant a pris le contrôle de l'infrastructure de distribution (CDN) d'OpsShield et a poussé un script par le mécanisme de mise à jour normal. Le script ciblait des données sensibles : hachages de mots de passe Linux, configuration root de MariaDB et MySQL, historique shell root, fichiers d'autorisation SSH et known_hosts. Les données étaient renvoyées vers le serveur de licences de l'éditeur, via un compte compromis, puis récupérées. L'éditeur a constaté l'exfiltration de 32 fichiers par serveur client.
Ce que ça change: Un attaquant dispose des hachages de mots de passe et des clés SSH de milliers de serveurs d'hébergement, donc d'un chemin direct vers les sites hébergés, les bases de données clientes et les comptes de facturation. C'est un effet de levier sur toute la chaîne d'hébergement, pas sur un seul client.
Ce qu'il faut faire: Mettre à jour en 5.88.25 ou ultérieur, puis réinitialiser tous les mots de passe locaux, rotation des identifiants de base de données, des secrets cloud et des clés SSH. Révoquer les clés d'autorisation SSH inconnues et vérifier known_hosts. Rechercher des connexions sortantes vers le domaine de licences de l'éditeur depuis les serveurs, et auditer les comptes créés entre le 2 et le 3 novembre.
Ce qui reste incertain: On ne sait pas comment les identifiants de l'éditeur ont été obtenus. L'éditeur n'a pas établi la liste exacte des données collectées par serveur, seulement le nombre de fichiers (32). Certains serveurs ont pu manquer la mise à jour selon l'intervalle de vérification.

Sources :bleepingcomputer.com securityweek.com helpnetsecurity.com

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

Plateformes de développement IA : une douzaine de compromissions en un mois pour voler des jetons d'accès

Concerné: Non applicable. Victimes citées : WorkOS, Northflank, Trigger.dev, Chainstack, CommandCode, Brev (NVIDIA), Fireworks AI, Lightning AI, OpenCode.
Correctif: Sans objet. Trigger.dev indique avoir bloqué le vecteur utilisé et notifié les clients affectés.

Ce qui s'est passé: Les attaquants ne cherchent plus des données clients mais des secrets : variables d'environnement, clés d'API de fournisseurs de modèles, jetons GitHub, jetons de session actifs. Ces plateformes sont des intermédiaires qui détiennent les identifiants de nombreux clients en aval, donc une seule intrusion expose les clés de dizaines de comptes d'inférence. Trigger.dev, plateforme d'exécution durable pour agents IA en TypeScript, a confirmé l'exfiltration de variables d'environnement d'un sous-ensemble d'organisations. WorkOS a vu son application interne de vente compromise le 30 octobre. Chainstack a perdu une base d'informations de comptes et des hachages de mots de passe, avec un risque sur les identifiants de noeuds.
Ce que ça change: Accès facturé aux modèles d'IA d'autrui, capacité de lire des données traitées par des agents, et rebond vers les services connectés (Stripe, Supabase, Slack pour Trigger.dev). Les clés volées alimentent un marché secondaire, avec des intrusions secondaires observées dans les 30 minutes suivant l'accès chez le fournisseur.
Ce qu'il faut faire: Inventorier tous les jetons d'IA et secrets stockés chez des plateformes tierces, et les considérer comme compromis si le fournisseur a été touché. Mettre en place une rotation courte et un coffre-fort de secrets central, avec des clés par client plutôt que partagées. Surveiller les pics de consommation et les appels depuis des adresses inattendues, et poser des plafonds de dépense par clé.
Ce qui reste incertain: SecurityWeek indique que les incidents ne semblent pas liés entre eux, tout en notant des similarités d'objectif. Le nombre exact de victimes varie selon les sources (« une douzaine »). L'attribution au groupe Storm-0940 pour certains cas repose sur des analyses tierces, non confirmées par les éditeurs.

Sources :securityweek.com theregister.com bleepingcomputer.com

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

Lovable et Supabase : 24 664 bases de données lisibles sans mot de passe, dont des passeports

Concerné: Applications générées par Lovable AI et adossées à Supabase, sans règles de sécurité au niveau des lignes (Row Level Security) correctement configurées
Correctif: Sans objet côté produit. La correction est côté client : activer et vérifier les règles RLS. Lovable renvoie à un problème plus large de configuration Supabase.

Ce qui s'est passé: Les chercheurs de Crissy Field ont extrait 159 041 projets Lovable depuis l'archive Common Crawl, puis interrogé leurs bases comme le ferait un visiteur. Sur 34 545 projets utilisant Supabase, 24 664 ont renvoyé des enregistrements sans aucune authentification. Des adresses e-mail étaient lisibles sur 7 403 sites, réparties sur plus de 10 500 tables. Un prestataire exposait plus de 1 000 dossiers de passeports avec dates d'expiration et nationalités. Un forum a laissé fuiter plus de 200 000 messages et 80 000 profils. Étaient aussi accessibles des dizaines de milliers de contrats, factures, albums photo et conversations WhatsApp internes.
Ce que ça change: Usurpation d'identité à partir de pièces d'identité authentiques, fraude au paiement à partir de données de commande, et fuite de données personnelles au sens du RGPD pour des responsables de traitement qui n'ont souvent pas conscience d'en être. La clé d'API exposée dans le navigateur suffit, il n'y a pas besoin d'exploit.
Ce qu'il faut faire: Pour tout projet Lovable ou Supabase en production, vérifier immédiatement que la RLS est activée sur chaque table et que la clé anon ne donne pas de lecture libre. Tester avec la seule clé publique du navigateur, sans compte. Classifier les données stockées et retirer les pièces d'identité des bases applicatives. Intégrer une revue de permissions avant toute mise en production, y compris pour les projets générés par IA.
Ce qui reste incertain: L'échantillon provient d'une archive de crawl et non d'un recensement exhaustif. Les chercheurs n'attribuent pas la faute à Lovable, et l'entreprise renvoie à Supabase ; la répartition des responsabilités n'est pas tranchée. Aucune notification aux personnes concernées n'est documentée à ce stade.

Sources :cybernews.com crissyfield.de

09 / 10ÉlevéeAttaque

APT29 : des chaînes d'exploits n-day en zero-clic contre iOS et Android via des sites piégés

Concerné: IOS 16.7 et iOS 18.5 identifiés dans les chaînes analysées ; Chrome pour Android versions 139 à 145, à l'exclusion de la 143. Des correctifs existent pour l'ensemble de ces failles, y compris des rétroportages vers d'anciennes versions d'iOS.
Correctif: Oui, Apple et Google ont corrigé toutes les failles ciblées.

Ce qui s'est passé: Des sites légitimes compromis (un producteur de gaz ukrainien, une association professionnelle américaine de l'industrie chimique, un site militaire bulgare) et des domaines imitation (America250, hôtel Raffles London) injectent un JavaScript qui profile le visiteur et sa version de navigateur. Le serveur de commande renvoie ensuite la chaîne d'exploit adaptée à la plateforme. Les attaquants ont aussi compromis le service d'analytique ukrainien Plerdy et modifié son traceur SEO, chargé par des milliers de sites entre le 27 août et le 3 septembre. Aucune persistance n'est installée : un redémarrage suffit à arrêter l'activité, jusqu'à la prochaine visite d'un site piégé.
Ce que ça change: Vol de cookies Safari, des bases de données WhatsApp et Telegram, des identifiants du trousseau, des données de localisation et des photos. Sur Android, l'outil AndroSnitch récupère les cookies Chrome, les identifiants enregistrés, l'historique et les mots de passe Wi-Fi sauvegardés. C'est de la collecte de renseignement, pas de la destruction.
Ce qu'il faut faire: Mettre à jour iOS et Chrome sur Android, y compris sur les appareils anciens. Comme il n'y a pas de persistance, un redémarrage après exposition suspecte limite la fenêtre. Bloquer les domaines imitation identifiés et surveiller les chargements de scripts tiers, en particulier les traceurs SEO. Restreindre l'usage des navigateurs tiers sur les flottes sensibles.
Ce qui reste incertain: L'attribution à APT29 repose sur des similarités d'infrastructure et des recoupements, pas sur une preuve définitive. Sekoia note que quatre autres failles ont été identifiées dans des chemins inatteignables ou alternatifs mais n'ont pas été utilisées dans les chaînes analysées. Le nombre de victimes n'est pas estimé.

Sources :bleepingcomputer.com

10 / 10ÉlevéeAttaque

Froid et OT : des consignes poussées à 50 °C dans plus de 115 magasins européens, et des sites français visés

Concerné: Systèmes de régulation de froid de magasins, notamment ceux du fournisseur Sabcobel. Danfoss, fabricant danois de régulation, est cité dans la campagne de revendications. Aucune version logicielle n'est publiée.
Correctif: Inconnu. Les techniciens ont déconnecté les installations affectées. Aucun correctif éditeur n'est identifié.

Ce qui s'est passé: Dans la nuit du 1er au 2 novembre, des attaquants ont modifié à distance les consignes de chambres froides et de congélateurs. Dans certains cas les meubles ont été arrêtés, dans d'autres le dégivrage a été déclenché, et un responsable d'enseigne suédoise rapporte un système qui s'est mis à produire de la chaleur. Un gérant de magasin ICA indique que les consignes ont été portées à +50 °C et n'étaient plus modifiables, ce qui a imposé de jeter des surgelés. The Register rapporte le 4 novembre une attaque contre des sites français de stockage de plasma sanguin, où des consignes de chambre froide auraient été réglées à 110 °C, les sécurités ayant évité les pertes de stock.
Ce que ça change: Perte de stock alimentaire, rupture de la chaîne du froid, fermeture partielle de magasins, et sur des produits de santé, risque de destruction de lots ou de perte de traçabilité. La répétition à trois semaines d'intervalle montre que le vecteur n'est pas fermé.
Ce qu'il faut faire: Recenser les régulations de froid joignables depuis Internet et les sortir du réseau public. Changer les identifiants par défaut, isoler l'OT derrière un accès distant chiffré avec authentification à deux facteurs, et journaliser les changements de consigne. Mettre en place une alerte sur écart de température et une procédure de bascule manuelle. Le secteur agroalimentaire et la santé partagent la même exposition.
Ce qui reste incertain: Les revendications de NoName057(16) et Z-Pentest Alliance ne sont pas vérifiables : les deux canaux Telegram ont été supprimés au moment de la publication, et un chercheur cité par CyberNews doute qu'il s'agisse d'une intrusion réelle plutôt que d'une récupération de crédit. Le nombre exact de magasins touchés varie selon les enseignes et les jours. Le chiffre d'environ 13 000 systèmes européens vulnérables est une estimation d'analystes, non un recensement.

Sources :bleepingcomputer.com cybernews.com theregister.com darkreading.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 du radar