Trois décennies que ReactOS essaie de devenir un clone open source de Windows, et le projet vient de mettre en place deux changements assez gros pour mériter un coup d'œil.

La 0.4.16 est entrée en phase finale cette semaine, avec des release candidates qui devraient suivre dans la foulée, et elle apporte une image d'installation unifiée plus un nouveau storage stack ATA. Deux gros morceaux qui devraient simplifier la vie de ceux qui veulent tester le truc sur de vraies machines.

Premier changement, fini les deux ISOs séparées. Avant, il fallait choisir entre l'image live (pour tester sans installer) et l'image d'installation. Maintenant tout est dans une seule image. Voilà.

Du coup, vous pouvez booter en live, voir si ça marche sur votre machine, et lancer l'installation directement depuis là si ça vous convient. Au passage, le vieil installeur en mode texte façon Windows 2000 risque d'être bientôt mis à la retraite au profit d'un parcours plus moderne.

Le deuxième changement est plus technique mais peut-être plus important. Le projet a remplacé son driver de stockage UniATA, qui datait de pas mal d'années, par un nouveau storage stack PnP-aware compatible NT6+.

Concrètement, ça veut dire un meilleur support des contrôleurs ATA et AHCI modernes, et donc une meilleure compatibilité avec le matos réel qu'on trouve dans les PC de 2026. C'était l'un des plus gros problèmes pour faire tourner ReactOS sur du hardware physique plutôt qu'en machine virtuelle.

ReactOS reste avant tout un projet pour les passionnés. La compatibilité avec les applications Windows modernes est encore très partielle, et quasi tout ce qui dépend de DirectX récent ou des frameworks .NET de dernière génération va planter.

Mais pour faire tourner un vieux logiciel pro orphelin, un jeu Win98 ou XP, ou simplement explorer comment fonctionne un OS de type Windows en open source, c'est tout indiqué.

Pour rappel, ReactOS n'est pas une distribution Linux qui imite Windows, c'est une réimplémentation complète et indépendante qui vise la compatibilité binaire avec les drivers et applications Windows NT.

L'objectif est de pouvoir lancer un .exe Windows directement, sans Wine ni couche d'émulation. Le projet est sur les rails depuis 1996, et même si ça avance lentement, chaque release apporte son lot d'améliorations concrètes.

Bref, si vous aviez ReactOS dans un coin de votre tête comme curiosité, la 0.4.16 sera sans doute le bon moment pour le retester sur une vieille machine.

Source : Hackaday

Quand j'achète un truc avec ma CB, c'est vrai que j'évite maintenant de demander le ticket de carte bancaire. Ça ne me sert à rien, et puis j'en fais quoi après ? Je le jette à la poubelle ?

Heureusement qu'il n'y a pas de données confidentielles dessus et que tous les chiffres de ma CB sont masqués avec des petites étoiles sauf une partie, généralement les 4 derniers, qui sont en clair évidemment.

Bref, tout roule, nan ? Hé bien noooon, parce que Metin Ozyildirim, un chercheur en sécurité, vient d'expliquer sur son site comment ces étoiles en fait c'est pas vraiment un secret.

En fait, quand vous effectuez un achat en ligne, le marchand pose une question à votre banque pour valider la carte, du genre "hey Crédit Agricole, est-ce que ce numéro existe ?" et la banque répond connement oui ou non.

Et le souci c'est que cette question, n'importe qui peut la poser depuis n'importe où dans le monde, en testant des numéros au pif jusqu'à tomber sur le bon. C'est ce qu'on appelle du brute force, et avec une bonne machine et une connexion correcte, ça permet de tourner tranquillement à la fréquence de 6 tentatives par seconde, soit environ 130 000 essais possibles étalés sur une nuit. C'est donc très largement assez pour reconstituer les chiffres manquants quand on n'en a que 6 à deviner.

Et surtout, il arrive parfois que le marchand soit un peu trop bavard. Par exemple si vous tapez un mauvais numéro, il vous répond "Cette carte de crédit n'est pas valide". Si la date d'expiration est fausse, il vous dit gentiment "Cette carte a expiré". Et si le CVV est faux ? "Le code CVV n'est pas correct".

Comme le dit Metin dans son post, ce genre d'indice aide carrément à bruteforcer les infos de la CB. Bah oui, si le marchand vous confirme noir sur blanc que vous êtes à 3 chiffres près du jackpot, pourquoi s'arrêter hein ? C'est un peu comme dans ces films où y'a un gars qui braque un coffre-fort qui fait "clic" à chaque bon chiffre.

Et comme ça donc que Metin Ozyildirim s'est fait piller son compte bancaire il y a environ 1 an. L'attaquant a fait tourner son bruteforce comme ça durant 6 heures, en répartissant ses requêtes sur plusieurs sites e-commerce différents pour passer sous les radars.

Et une fois la carte complète reconstituée, restait plus qu'à dépenser le pognon ! Et là pareil, certains marchands acceptent encore les paiements sans demander la double authentification 3D Secure. Ces marchands là, ce sont eux qui payent en cas de fraude, car ils prennent le risque. L'attaquant a juste eu à choisir un de ces marchands "hack-friendly", et a transféré l'argent vers un porte-monnaie électronique, qu'il a ensuite converti en cash.

Et voilà comment le plafond de la carte de Metin était à zéro avant qu'il ait terminé son premier café du matin !

La bonne nouvelle, c'est que la banque l'a remboursé. Par exemple en France, vous avez 13 mois pour contester une transaction frauduleuse via votre banque. C'est un droit et pas une faveur hein ! Mais si la banque considère que vous avez été négligent (carte prêtée, code partagé, phishing évident...etc), elle peut tout à fait refuser le remboursement, donc gardez des preuves et contestez vite !

Maintenant, la mauvaise nouvelle, c'est que ce qui est arrivé à Metin est de plus en plus fréquent. Visa a même documenté que ce genre d'attaques explose, et que la majorité des sites e-commerce sont mal protégés contre ce genre de bots qui font tourner ces scripts de bruteforcing.

Bref, y'a pas grand chose à faire de notre côté pour nous protéger de ça, si ce n'est d'activer les notifs de notre banque sur chaque transaction, configurer le plafond le plus bas possible (sans que ce soit gênant), et quand votre banque vous propose une carte virtuelle à usage unique pour les achats en ligne, n'hésitez pas à l'utiliser.

Et la prochaine fois que vous laisserez traîner un reçu de CB sur la table d'un resto, dites-vous que vous offrez peut-être un accès à votre compte au prochain margoulin qui passe !

Source

Le NCSC, l'agence de cybersécurité du Royaume-Uni rattachée au GCHQ (l'équivalent britannique de la NSA américaine, qui s'occupe du renseignement électronique pour l'État), a sorti un boîtier qui s'intercale entre un ordinateur et son écran pour bloquer les attaques transitant par le câble HDMI ou DisplayPort.

Le produit s'appelle SilentGlass, il se branche sans configuration, et il a été présenté à la conférence CYBERUK. Première mondiale, dit-elle.

Première surprise pour qui n'y a jamais pensé : le câble qui relie votre PC à votre écran ne sert pas qu'à faire passer l'image. Il transporte aussi des données dans les deux sens (réglages de l'écran, infos sur la résolution, anti-copie sur les contenus protégés), et il émet des ondes électromagnétiques qui peuvent fuiter loin du bureau.

En 2024, des chercheurs de l'Université de la République à Montevideo ont montré qu'on pouvait reconstituer à distance le texte affiché sur un écran rien qu'en captant le rayonnement émis par le câble HDMI, avec un peu d'IA derrière. C'est le principe de l'attaque TEMPEST, théorisée dans les années 80 par les agences de renseignement, mais qui devient aujourd'hui accessible à des attaquants disposant de moyens beaucoup plus modestes.

SilentGlass se branche en série sur le câble, comme un petit module qu'on intercale. Il regarde le trafic qui circule par le canal annexe du HDMI ou du DisplayPort (celui qui sert à dialoguer entre PC et moniteur, en plus de l'image), et il bloque tout ce qui ne ressemble pas à une communication d'écran normale.

L'idée, c'est de couper la route à des programmes malveillants qui passeraient leurs ordres en se faisant passer pour des commandes anodines de réglage. La logique est celle d'un pare-feu, sauf que c'est posé entre l'unité centrale et l'écran, là où personne ne pensait à en mettre un.

La fabrication est confiée à Goldilock Labs, une entreprise britannique de cybersécurité, en partenariat avec Sony UK Technology Centre, l'usine galloise de Pencoed que Sony exploite depuis longtemps. C'est la première fois que le NCSC met son nom sur un produit grand public.

Le dispositif est déjà installé sur des sites du gouvernement britannique, et l'agence vise désormais les opérateurs d'infrastructures critiques (énergie, transports, banques), les ministères, les entreprises de défense, et plus largement toutes les organisations qui pensent être dans la cible d'États étrangers. Le prix exact n'a pas été annoncé, mais le NCSC parle d'un produit abordable pour son marché.

Le produit règle une faille qui n'est pas anodine. La sécurité du câble vidéo est traitée depuis trente ans comme un sujet de niche réservé aux militaires, mais avec la multiplication des écrans connectés, des bureaux partagés et des chaînes d'approvisionnement où chaque câble a pu passer par dix mains avant d'arriver chez vous, le périmètre s'est élargi.

Pour un développeur dans une startup avec un MacBook et un écran 27 pouces, l'intérêt est faible. Pour une salle de marché bancaire ou un centre de surveillance vidéo, c'est tout autre chose.

Vous l'avez compris, le NCSC sort ici un produit étatique pour un risque que la plupart ignorent. Une agence de renseignement qui vend du matériel commercial, c'est quand même nouveau, mais ça va dans le bon sens.

Source : Security Affairs

La première release candidate de Linux 7.1 est sortie, avec un tout nouveau pilote NTFS écrit pour le noyau, qui annonce des écritures multi-thread deux fois plus rapides et un montage de disque jusqu'à quatre fois plus véloce que l'ancien.

La sortie stable est prévue pour la mi-juin selon le calendrier de Linus Torvalds. Au total, la fenêtre de merge a vu passer plus de 13 000 commits, ce qui en fait une release plutôt costaude.

Le pilote NTFS dans Linux a une longue histoire compliquée. Pendant des années, le kernel a embarqué deux pilotes : ntfs en lecture seule maintenu par Anton Altaparmakov, et ntfs3 contribué par Paragon Software puis pratiquement abandonné depuis 2024.

La version qui débarque dans 7.1 est une réécriture complète, optimisée pour les usages dual-boot et les disques externes formatés en NTFS, qui restent monnaie courante quand on échange des fichiers avec Windows.

L'autre nouveauté, c'est l'activation par défaut de FRED, le mécanisme Flexible Return and Event Delivery développé par Intel pour remplacer le vieux système d'IDT et d'interruptions hérité du x86. Cette activation doit simplifier la gestion des exceptions et des appels système, avec moins de cycles perdus à chaque commutation de contexte. Sur les puces Intel récentes qui le supportent, c'est un petit gain de performance qu'on récupère sans rien faire.

Côté ménage, on vous en a déjà parlé , Linux 7.1 retire le support du i486, processeur sorti en 1989, et abandonne plusieurs vieux pilotes réseau et SoC qui n'avaient plus d'utilisateurs réels. Personne ne regrettera. Le kernel garde son équilibre entre support legacy et code moderne, en évacuant les morceaux qui coûtent en maintenance pour zéro retour visible.

Pour les utilisateurs de tous les jours, le gros impact ça sera cette affaire d'NTFS. Avoir un pilote rapide, fiable et maintenu directement dans le kernel mainline change la vie de tous ceux qui jonglent entre Linux et Windows sur la même machine. Plus besoin de dépendre de ntfs-3g en userspace ou de monter en lecture seule pour éviter les corruptions, ce qui était le quotidien de pas mal de gens depuis bien trop longtemps.

C'est aussi un bon indicateur pour l'écosystème : du code propre, écrit en interne, sans dépendre d'un éditeur tiers qui peut se désengager du jour au lendemain.

Linux 7.1 fait donc un gros ménage et règle un problème bien relou. Pour ceux qui galèrent avec leurs disques NTFS depuis bien longtemps, c'est une libération.

Source : Phoronix

SentinelOne a publié une analyse qui peut redessiner la chronologie connue de la cyberguerre. Baptisé FAST16, ce framework de sabotage informatique a été compilé en 2005, soit cinq ans avant la découverte de Stuxnet. Si les analyses tiennent la route, ça en fait la plus ancienne cyberarme étatique documentée à ce jour.

Le principe est fourbe. FAST16 ne détruit rien, ne chiffre rien, ne vole rien. Il corrompt des calculs. Le driver kernel (fast16.sys) s'installe silencieusement sur la machine cible, se place dans le flux d'entrée/sortie du système de fichiers, et modifie le code exécutable de certains logiciels de calcul haute précision pendant leur chargement en mémoire.

Le logiciel tourne normalement, affiche des résultats cohérents en apparence, mais ils sont légèrement faux. Pendant des mois, voire des années, les ingénieurs prennent des décisions sur des données faussées sans jamais rien voir. Plutôt vertigineux.

Les logiciels visés sont très spécifiques : LS-DYNA 970 pour la simulation de crash et les calculs structurels, PKPM pour le BTP (utilisé essentiellement en Chine), et MOHID pour la modélisation hydrodynamique. LS-DYNA, justement, a des usages documentés dans la recherche nucléaire iranienne. Ce qui ramène toujours au même dossier.

L'architecture est aussi très sophistiquée : un module porteur avec une machine virtuelle Lua 5.0 embarquée qui exécute du bytecode chiffré, le driver de sabotage, et un module de reporting qui passe par les callbacks Windows RAS.

Pour rappel, l'usage d'une VM Lua embarquée précède de trois ans les plus anciens échantillons de Flame (2012). Ces gens étaient très en avance.

Autre signal intéressant, le nom "fast16" apparait dans la fuite ShadowBrokers de 2017, plus précisément dans les composants "Territorial Dispute" attribués à la NSA, accompagné d'une mention cryptique qui disait en substance "rien à voir ici, circulez".

Visiblement, il y avait quelque chose à voir. Le code contient aussi des traces SCCS/RCS, des conventions de versioning Unix des années 70-80, ce qui pointe vers des développeurs issus d'environnements d'ingénierie ancienne école, probablement étatiques.

Bref, SentinelOne n'accuse personne, mais les indices pointent vers les États-Unis ou un allié. Ça repousse de cinq ans la frontière connue de la cyberguerre offensive.

Source : The Register

Si vous avez installé Bitwarden CLI via npm entre 17h57 et 19h30 PM (heure de New York) ce 22 avril, faut faire le ménage sur votre machine de toute urgence !! En effet, le package @bitwarden/cli version 2026.4.0 a été compromis durant 93 minutes, et le malware qui s'y trouvait a fait des dégâts chez les 334 personnes qui l'ont téléchargé pendant cette fenêtre.

Mais alors c'est quoi cette histoire encore ?

Hé bien des attaquants ont réussi à piéger le pipeline GitHub Actions de Bitwarden, à y injecter un fichier bw1.js dans le package npm officiel, et à le publier sans qu'aucune alerte ne parte. Jusqu'à ce que l'équipe sécurité de Bitwarden capte le truc et retire le package une heure et demie plus tard.

Et y'a un truc qui fait tiquer dans cette histoire, c'est que le malware s'annonce fièrement comme "Shai-Hulud: The Third Coming". En fait c'est la troisième vague d'une campagne npm qu'on avait déjà croisée en septembre 2025 . Et les attaquants restent cohérents dans leur branding puisque les dépôts publics qu'ils créent chez les victimes portent des noms issu de Dune comme atreides, fremen, sardaukar ou harkonnen. Donc sachez le, si vous voyez ça apparaître sur votre GitHub, vous êtes cuit !

Le payload, lui, est propre dans son approche crasseuse, selon l'analyse de Socket . Il chope tout ce qui traîne sur votre machine : tokens GitHub (ghp_*), tokens npm, credentials AWS dans ~/.aws, tokens Azure, SSH keys, fichiers .npmrc, configs Claude et MCP.

Puis il chiffre le tout en AES-256-GCM avec une clé RSA éphémère, balance le paquet vers audit.checkmarx[.]cx/v1/telemetry (un domaine qui imite Checkmarx pour brouiller les pistes), puis injecte une backdoor dans vos .bashrc et .zshrc. Ah et le malware vérifie également votre localisation système et se barre en silence sans faire de dégâts si elle commence par "ru". Ohhh comme c'est bizarre ^^.

Bref, si vous êtes concerné, voici la liste des trucs à faire dans l'ordre :

• npm uninstall -g @bitwarden/cli puis npm cache clean --force
• Rotation complète de vos secrets : tokens GitHub, tokens npm, credentials AWS/Azure/GCP, clés SSH
• Vérifiez vos repos GitHub pour des créations suspectes avec des noms Dune
• Cherchez "LongLiveTheResistanceAgainstMachines" dans vos commits (c'est leur marker d'exfiltration)
• Virez les modifications suspectes dans vos ~/.bashrc et ~/.zshrc
• Installez la version 2026.4.1 qui est propre

Faut bien le reconnaître, Bitwarden a été hyper réactif dans cette histoire. Détection en interne, mise en quarantaine en 93 minutes, communication claire, et CVE émis dans la foulée. Et heureusement, aucune donnée utilisateur n'a fuité vu que les vaults restent chiffrés côté client de toute façon, et que seuls les développeurs qui ont installé le CLI pendant ce créneau sont touchés. Les extensions navigateur, l'app desktop, mobile, le package snap, rien de tout ça n'a bougé.

Mais ça reste quand même la preuve que npm est devenu LE cauchemar de la supply chain moderne. Après Axios le mois dernier et la campagne Shai-Hulud de septembre, on en est au point où chaque package JS avec un script d'install équivaut à une bonne vieille roulette russe. Donc si vous bossez dans un environnement CI/CD, soyez vigilant et jetez aussi un oeil à safe-npm pour mettre un peu de paranoïa automatisée dans votre workflow quotidien.

Voilà, si vous avez installé Bitwarden CLI avant-hier soir via npm, vous avez du boulot. Sinon, respirez car Bitwarden a tenu bon !

Source

Un logiciel malveillant destiné à effacer définitivement les données de postes informatiques vient de faire surface dans le secteur énergétique vénézuélien.

La bête a été baptisée "Lotus" par les chercheurs de Kaspersky qui l'ont analysé en premier, il a été mise en route en décembre 2025 depuis un ordinateur vénézuélien, et sa cible principale semble être PDVSA, la compagnie pétrolière d'État.

Côté technique, Lotus ne fait pas dans la dentelle. Deux scripts batch préparatoires, OhSyncNow.bat et notesreg.bat, désactivent toutes les défenses, coupent les comptes utilisateurs et ferment les interfaces réseau, histoire de bien tout bloquer.

Ensuite, le binaire principal passe en mode destruction avec diskpart, robocopy et fsutil pour manipuler le système de fichiers, puis descend au niveau IOCTL pour écraser directement des secteurs physiques du disque. Les points de restauration sont supprimés, le journal USN est effacé. Aucune récupération possible.

LKaspersky ne pointe personne, et aucun élément technique ne désigne un État ou un groupe criminel en particulier. Le timing est quand même troublant : fin 2025 et début 2026, le Venezuela a traversé une crise politique majeure avec la capture de l'ancien président Nicolás Maduro le 3 janvier, et les tensions toujours fortes autour des infrastructures énergétiques. Coïncidence ou coordination, on ne saura probablement pas avant longtemps.

En pratique, un wiper qui cible PDVSA, ça rappelle immédiatement les attaques contre les infrastructures critiques qu'on a vues en Ukraine avec Stryker ou contre des clusters Kubernetes avec la variante TeamPCP.

L'objectif n'est pas le chantage ni le vol, c'est la destruction pure. Les opérateurs ne cherchent pas à exfiltrer quelque chose, ils veulent rendre l'infrastructure inutilisable le plus vite possible, pour déstabiliser ou punir.

Un réseau d'alimentation électrique ou de distribution de carburant paralysé quelques jours, ça a des conséquences directes sur la vie quotidienne et sur la stabilité politique d'un régime.

Ce qui inquiète, c'est aussi la qualité du code. Lotus n'est pas un script amateur collé à la va-vite : il enchaîne plusieurs étapes de sabotage méthodique, de la désactivation des défenses à la destruction bas niveau du disque.

Pour un pays qui n'a déjà pas la réputation d'avoir la cybersécurité la plus pointue du continent, encaisser ce genre d'outil, ça fait mal. Et la probabilité que d'autres échantillons du même auteur circulent déjà ailleurs est loin d'être nulle.

Bref, un wiper bien fichu sur une compagnie pétrolière d'État dans un pays en crise, c'est rarement l'œuvre d'un adolescent dans son garage. Affaire à suivre donc.

Source : Bleeping Computer

Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.

GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.

L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.

Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.

Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.

Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.

Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.

En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.

Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.

Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.

Source : The Register

Une IA a rooté une télé Samsung tournant sous KantS2, la plateforme logicielle d'un ancien modèle de la marque. C'est Codex, le modèle de code d'OpenAI, qui a trouvé un driver laissé avec des droits d'écriture sur le firmware, mappé la mémoire physique, et est passé root en quelques étapes. Les chercheurs de califio lui ont juste fourni un accès shell et le code source du firmware. À partir de là, c'est Codex qui a enchaîné la chaîne d'exploitation tout seul.

Et ce qui est marquant dans cette histoire, je trouve, c'est pas tellement la faille mais le fait qu'un driver laissé en accès libre sur un firmware embarqué des années 2018-2020, ça se trouve à la pelle. Heureusement, Samsung a patché cette TV-là.

Ce qui est super fort, c'est que Codex a fait de l'énumération de surface d'attaque, a lu le code source, a testé ses hypothèses sur l'appareil en live, a pondu un PoC en 2 secondes, puis l'a exploité. 5 petites étapes que des chercheurs humains mettent typiquement des semaines à enchaîner.

Et Codex n'est pas un cas isolé puisque Anthropic a annoncé que son modèle Claude Mythos a trouvé des milliers de vulnérabilités sur Windows, macOS, Linux et les gros navigateurs, dont une partie en critique. De son côté, AISLE a sorti les douze vulnérabilités critiques patchées dans OpenSSL fin janvier de cette année, trouvées également par son système IA. Trend Micro de son côté fait tourner ÆSIR et revendique 21 CVEs sur NVIDIA, Tencent et MLflow depuis mi-2025. Bref, on a basculé dans autre chose niveau cybersec.

Du coup, la question qui me gratte, c'est pas "est-ce que l'IA peut trouver des failles". Pour ça, on connait la réponse. Non, c'est plutôt : Mais qui va tenir le putain de rythme côté défense ?. Parce que les fabricants, eux, patchent toujours à la vitesse d'un humain qui lit un rapport, teste, valide, et pousse quand ils ne sont pas en congés, alors que pendant ce temps, un système IA bien configuré peut passer au scanner le firmware d'un objet connecté en boucle, sans se fatiguer et sans pause café jusqu'à ce qu'il le déboite.

Côté utilisateur, honnêtement, y'a pas grand-chose à faire. La faille Samsung est corrigée par une mise à jour, encore faut-il avoir branché la TV au réseau et accepté les updates. Et pour une TV achetée il y a cinq ans et qu'on rallume uniquement pour Netflix le soir, c'est loin d'être garanti. Le bon réflexe, c'est donc de vérifier les mises à jour sur tout ce qui a un firmware et qui traîne en bout de course. Routeurs, caméras IP, domotique, et tous ces vieux trucs qu'on a oublié de patcher depuis trois ans.

En tout cas, je vous le dis direct, le sujet va revenir encore et encore, vous allez voir... Parce que si une IA de ce niveau peut trouver une escalade root sur une TV avec juste un shell et du code source, elle peut s'attaquer à pas mal d'autres appareils connectés qui partagent les mêmes mauvaises habitudes de permissions. Le hack de TV , en 2012, c'était un passe-temps de chercheur alors qu'en 2026, c'est devenu industrialisable.

Les IA accélèrent vraiment la découverte de 0-days, et l'écart avec les équipes humaines se creuse fortement. Donc si vous avez du matos connecté chez vous, un petit audit ce weekend, ça ne mangera pas de pain.

Source : Califio

Des utilisateurs de Claude Desktop sont en train de découvrir que l'application d'Anthropic se permet d'aller bidouiller les réglages de plusieurs navigateurs, y compris ceux qui ne sont pas installés sur la machine.

L'idée est simple, c'est pré-configurer l'accès pour que, le jour où vous installeriez Chrome, Firefox ou Edge, Claude puisse directement automatiser votre navigation sans avoir à redemander la permission.

Sur le papier, ça part d'une intention louable. Éviter de vous ennuyer avec un prompt de permission à chaque installation, pourquoi pas. Sauf que voilà, personne n'a demandé à ce que Claude Desktop touche aux navigateurs absents, et encore moins à ceux que l'utilisateur a délibérément choisi de ne pas avoir.

On a par exemple un chercheur en sécurité qui n'avait jamais installé la moindre extension Anthropic, qui s'est retrouvé avec toutes ces préconfigurations silencieuses, selon The Register.

Le problème devient plus sérieux quand on regarde comment ça marche. 

L'application pont qui fait le lien entre Claude et les navigateurs tourne hors du sandbox navigateur, avec les privilèges complets de l'utilisateur. Ce qui veut dire qu'elle peut lire vos pages, remplir vos formulaires, capturer l'écran sur des sessions authentifiées, bref agir comme vous, sans aucune boîte de dialogue qui vienne prévenir ou demander confirmation.

Côté Anthropic, silence radio. On imagine bien que l'argument défensif sera qu'il s'agit juste de préparer le terrain pour Computer Use, la fonctionnalité qui permet à Claude d'utiliser votre PC comme un humain.

Sauf qu'installer des hooks dans des navigateurs absents ressemble quand même plutôt du squatting de permissions qu'à une préparation technique légitime.

Ce qui est rageant dans cette histoire, c'est qu'Anthropic se positionne depuis des mois comme l'acteur "sérieux" de l'IA, celui qui fait des papiers d'alignement et parle éthique à longueur de blog posts. Voir leur app desktop se comporter comme un logiciel de 2005 qui colle Ask Toolbar sans prévenir, c'est un camouflet côté image.

Pour les entreprises qui regardent si elles peuvent déployer Claude Desktop en flotte, ce genre de comportement va clairement peser dans la balance sécurité, et pas dans le bon sens.

Bref, on est là sur une histoire de permissions qui n'aurait jamais dû exister sur un produit d'une boîte qui se présente comme le pro de la sécurité IA.

Source : The Register

Vercel, c'est la plateforme d'hébergement web utilisée par des milliers de développeurs et d'entreprises pour déployer leurs sites et applications (c'est eux qui font Next.js, entre autres).

Un de leurs employés s'est inscrit sur Context.ai, un assistant IA pour la bureautique, en utilisant son compte professionnel Google. Au moment de l'installation, l'app a demandé l'accès à ses emails, ses fichiers, son agenda, bref tout le Google Workspace de la boîte. Il a cliqué "autoriser tout". Erreur classique.

Sauf que Context.ai s'est fait pirater en février. Un de leurs propres employés a chopé un malware (Lumma, un voleur de mots de passe) en téléchargeant des scripts de triche pour Roblox. Le genre de bêtise qui ouvre la porte à tout le reste.

L'attaquant a récupéré l'accès que Context.ai avait sur le Google Workspace de Vercel, avec des permissions très larges : emails, fichiers internes, infrastructure de déploiement.

ShinyHunters, un groupe de pirates connu, a revendiqué le coup sur un forum et mis en vente des clés d'accès, du code source, des données de bases et des clés API de Vercel.

Le PDG de Vercel estime que le nombre de clients touchés est "assez limité", sans donner de chiffres. Mais côté crypto, plusieurs projets hébergés sur la plateforme ont quand même lancé en urgence un changement de tous leurs mots de passe et clés d'accès, ce qui donne une idée de l'ambiance.

Ce qui rend cette affaire intéressante, c'est le mécanisme. Personne chez Vercel n'a été directement attaqué. C'est un outil tiers, un outil IA installé par un employé, qui a servi de pont. L'employé donne un accès large à un service externe, le service se fait pirater trois mois plus tard, et tout le contenu professionnel de l'entreprise se retrouve exposé.

C'est exactement le scénario que les experts en sécurité décrivent depuis un an quand ils parlent des outils IA qui demandent des permissions tentaculaires sur vos comptes pro.

Bref, le vrai problème n'est pas Vercel. C'est le "autoriser tout" sur un outil IA qu'un employé a installé sans se poser de questions.

Source : SecurityWeek

GIMP 3.2.4 est sorti le 19 avril avec une fournée de corrections de bugs, dont une qui remonte à 1999 dans le code de gestion du format XCF, le format natif de GIMP. 26 ans. Le bug traînait dans le code source depuis les premières versions du logiciel et n'avait jamais été repéré ni corrigé.

Pour ceux qui ne connaissent pas, XCF est au GIMP ce que PSD est à Photoshop : le format de fichier natif qui stocke calques, masques, chemins et métadonnées.

Un bug dans le parsing XCF, même mineur, peut entraîner des pertes silencieuses de données ou des comportements incohérents à la réouverture d'un projet commencé des mois plus tôt.

La version précédente, GIMP 3.2.2, avait en fait introduit une régression en essayant de corriger un autre problème. Certains calques de texte devenaient impossibles à éditer après avoir été rechargés depuis un fichier XCF. GIMP 3.2.4 corrige ça, et corrige au passage le bug historique de 1999 qui était à l'origine de comportements erratiques dans le parsing du format.

L'autre correction notable concerne la fonction "Ouvrir en tant que calques" avec des fichiers XCF multi-calques. Les noms de calques étaient modifiés à l'import, ce qui posait des problèmes dans les workflows automatisés ou les scripts qui comptent sur des noms stables.

Le projet GIMP fête ses 30 ans cette année, et le passage à la branche 3.x était le plus gros chantier depuis son lancement. Ici on est sur une release de maintenance, pas de nouvelles fonctions, mais corriger des bugs de fond dans le format de fichier natif quand on est en pleine transition majeure, ça évite que les utilisateurs se retrouvent avec des fichiers corrompus ou des calques cassés sur la durée.

Bref, si vous bossez avec GIMP et des fichiers XCF, la mise à jour est recommandée.

Source : Phoronix

Attention les amis, si vous avez une chaîne YouTube, vous allez probablement recevoir ce mail d'un certain "Edward Evans" ou autre qui vous explique très poliment que vous avez utilisé sa musique dans une vidéo, qu'il a déposé une plainte, et qu'il serait ravi de résoudre ça "peacefully".

Surtout ne répondez pas !

J'en ai reçu un hier sur ma boite mail... Un message courtois où le type explique qu'il y a eu une petite incompréhension et qu'on va arranger ça entre gens biens. Sauf que ce mail, c'est en fait le premier étage d'une arnaque bien ficelée qui a pour but final de dérober votre compte Google et de détourner votre chaîne.

Le premier red flag qui saute tout de suite quand on clique sur le nom de l'expéditeur c'est le display name qui affiche "Edward Evans", mais dont l'adresse réelle derrière est [email protected]. Deux prénoms féminins + 4 chiffres au pif, c'est très typique d'un Gmail jetable créé pour la campagne.

Perso, je m'en fous qu'un ayant droit utilise Gmail, car ça arrive. Par contre, un nom totalement différent entre ce qui est affiché et la vraie boîte mail, ça c'est un premier signal probable qu'on vous balade !

Le deuxième truc qui trahit l'arnaque, c'est le vide complet du mail. Aucune URL de la vidéo incriminée, aucun nom de morceau, aucun timestamp... juste "my audio track/music" bien générique. Le problème, c'est qu'un vrai détenteur de droits qui contacte en direct fournit généralement la vidéo exacte, l'œuvre concernée avec son numéro d'enregistrement et le passage précis.

Là, y'a rien.

Le mail est en fait volontairement flou pour maximiser les réponses, peu importe le contenu réel de votre chaîne. Par acquit de conscience, je suis allé chercher le gars sur GitHub, Twitter, Reddit, Gravatar, et compagnie mais zéro trace nulle part. C'est un pur Gmail fantôme créé juste pour l'occasion.

Et si vous répondez un truc du genre "bonjour, quelle vidéo exactement ?", ce que j'ai failli faire avant de me raviser, vous recevrez un deuxième mail avec un lien vers un prétendu dossier de preuve. Le hic, c'est que le lien pointe vers dmca-notification[.]info ou une variante, un site documenté récemment par Malwarebytes .

En fait le site clone l'interface YouTube, récupère votre vraie photo de profil, vos vrais subs, votre dernière vidéo, et vous invite très naturellement à vous connecter avec Google pour "consulter la réclamation". Et peu importe que vous soyez sur macOS, Windows ou Linux, le piège fonctionnera dans n'importe quel navigateur. Et si vous tombez dans le panneau, BAM, ça part en credentials volés, et donc en compte Google récupéré, et dont la chaîne est ensuite souvent renommée, pillée et détournée, tout ça en quelques heures !

L'arnaque fonctionne en mode Phishing-as-a-Service. Plusieurs attaquants partagent le même backend, chacun avec son affiliate ID. Un peu comme Uber Eats, mais pour l'extorsion... sympa hein ? Selon l'analyse Malwarebytes, le kit cible spécifiquement les chaînes sous les 3 millions d'abonnés plutôt que les gros YouTubeurs, parce qu'au-dessus les créateurs ont des contacts directs chez YouTube et le kit se fait démonter trop vite. Du coup, attention si vous bossez sur votre chaîne sans équipe juridique derrière comme moi, vous êtes clairement pile dans la cible.

Voici donc ce qu'il faut faire si vous recevez ce mail. Premier réflexe, ne pas répondre et signaler comme phishing directement dans Gmail. Ensuite, il faut bloquer l'expéditeur pour couper les relances. Enfin, vérifiez que votre compte Google a bien la double authentification activée, idéalement avec une clé physique type YubiKey au lieu d'un SMS (plus costaud parce qu'un SIM swap, ça peut se faire en quelques minutes avec un minimum d'ingénierie sociale.

Allez faire aussi un tour sur myaccount.google.com/security pour lister les sessions actives et les apps autorisées, et virez tout ce que vous ne reconnaissez pas. Ne zappez pas non plus les gestionnaires tiers sur votre chaîne dans YouTube Studio, y'a souvent des vieilles autorisations qui traînent.

Et n'oubliez pas, LA source de vérité pour tout problème de copyright, c'est YouTube Studio, dans l'onglet Contenu, colonne Restrictions. Si y'a pas de restriction affichée en Studio, alors le mail c'est du phishing de merde, point.

Voilà, si vous avez une chaîne ou pas, parlez-en aussi à vos potes créateurs autour de vous car cette arnaque tourne fort en ce moment.

Source

Plus de 230 modèles de points d'accès Wi-Fi Cisco ont un problème. Les versions 17.12.4 à 17.12.6a de IOS XE embarquent une bibliothèque qui génère un fichier log, cnssdaemon.log, à raison de 5 Mo par jour. Le fichier ne sert à rien. Et impossible de le supprimer depuis la ligne de commande.

5 Mo par jour. Ça paraît rien. Sauf qu'un point d'accès Wi-Fi n'a pas un disque de 500 Go. La mémoire flash de ces appareils est limitée, et au bout de quelques semaines ou mois, elle sature.

Quand c'est plein, plus moyen de télécharger ou d'installer une mise à jour logicielle. La borne fonctionne encore, mais elle est figée sur sa version actuelle, sans possibilité de patch de sécurité ou de correction de bug.

Et c'est là que le piège se referme. Pour corriger le problème, il faut mettre à jour IOS XE. Mais si la mémoire flash est déjà pleine, la borne n'a pas la place pour stocker la nouvelle image système.

Cisco prévient que tenter la mise à jour dans cet état peut provoquer un bootloop, la borne redémarre en boucle sans jamais finir le boot. Du coup, l'admin se retrouve avec un appareil qu'il ne peut ni patcher ni laisser en l'état.

Cisco a publié un bulletin avec les procédures de test et de remédiation. Il faut d'abord vérifier la version IOS XE, puis libérer de l'espace manuellement avant de tenter la mise à jour.

Ça se fait, mais c'est du travail manuel sur chaque borne, et dans un réseau d'entreprise avec des centaines de points d'accès, la facture en heures de boulot est salée.

Ce genre de bug est particulièrement agaçant parce qu'il est silencieux. Personne ne surveille l'espace disque d'une borne Wi-Fi au quotidien, le problème se découvre en général le jour où une mise à jour échoue, c'est-à-dire trop tard.

Et le fait que la suppression du fichier soit impossible en CLI est quand même un oubli difficile à excuser sur du matériel vendu aux entreprises.

Bref, si vous avez du Cisco en IOS XE 17.12.x, vérifiez vos bornes avant qu'elles ne se bloquent toutes seules.

Source : The Register

Des attaquants se sont fait passer pour un responsable connu de la Linux Foundation sur le Slack du TODO Group, un groupe de travail dédié aux bureaux de programmes open source. L'objectif, piéger les développeurs en les amenant à cliquer sur un lien d'apparence officielle, puis à installer un faux certificat racine sur leur machine.

Le lien était hébergé sur Google Sites, ce qui aide à passer les filtres de sécurité et donne un vernis légitime. Les victimes arrivent sur une fausse page d'authentification Google Workspace, qui récupère leur adresse email et un code de vérification, avant de leur demander d'installer un "certificat Google" pour finaliser la connexion.

C'est là que tout bascule. Installer un certificat racine, c'est donner à l'attaquant la possibilité de signer ou d'intercepter n'importe quel trafic TLS sur la machine.

Sur macOS, le faux certificat télécharge et exécute un binaire nommé gapi depuis une IP externe (2.26.97.61), avec toutes les conséquences qu'on imagine. Sur Windows, c'est une boîte de dialogue de confiance navigateur qui pousse l'installation. Dans les deux cas, la machine est compromise.

OpenSSF, Socket et Help Net Security ont documenté la campagne, qui s'inscrit dans une tendance plus large.

Les attaquants visent de plus en plus les workflows développeurs et les relations de confiance interne plutôt que de chercher une faille zero-day dans le code, parce qu'un ingénieur qui fait confiance à un Slack privé reste une cible bien plus rentable que la lecture de 50 000 lignes de C obscures.

La règle de sécurité à retenir est simple. Aucun service légitime, jamais, ne vous demandera d'installer un certificat racine via un lien reçu en chat ou par email.

Si un message Slack vous y pousse, même depuis un compte interne qui semble légitime, c'est un compromis ou une usurpation. Signalez, ne cliquez pas.

Ce qui est relou, c'est que l'attaque marche précisément parce que les devs open source travaillent beaucoup sur Slack, au milieu de messages techniques qu'ils traitent à la chaîne. C'est donc franchement fourbe.

Bref, vous l'avez compris, un certificat racine demandé par chat, c'est toujours non.

Source : The Register

Une vulnérabilité Microsoft patchée en 2012, deux fois, refait surface en 2026 dans des attaques actives. Elle fait partie des quatre failles que la CISA a collées lundi dans son catalogue des bugs activement exploités, avec obligation pour les agences fédérales américaines de patcher sous deux semaines. 14 ans plus tard, un vrai bug zombie.

La plus vieille, c'est CVE-2012-1854, un chargement de bibliothèque non sécurisé dans Visual Basic for Applications. Microsoft l'a corrigée une première fois en juillet 2012, puis encore en novembre de la même année.

Ça n'a pas suffi. Des attaquants trouvent toujours des machines non patchées sur lesquelles elle fonctionne, et exécutent du code à distance via VBA. Un classique des macros Office qui refuse de mourir.

Les trois autres ne sont pas plus rassurantes. CVE-2023-21529, une désérialisation de données non fiables dans Exchange Server, permet à un attaquant authentifié de faire de l'exécution de code à distance.

Elle était patchée en février 2023. CVE-2023-36424 touche le driver Common Log File System de Windows et ouvre la porte à une escalade de privilèges (patchée en novembre 2023). Et la dernière, CVE-2025-60710, est une faille de link-following dans Windows qui donne également de l'escalade de privilèges.

Côté exploitation active, les chasseurs de menaces Microsoft pointent Storm-1175, un gang financièrement motivé qui combine la faille Exchange avec 15 autres pour entrer dans des organisations, siphonner leurs données et déployer le ransomware Medusa. Du classique en plusieurs étapes, sauf que le point d'entrée est une faille colmatée depuis trois ans.

Ce qui est frappant dans la liste, c'est que trois failles sur quatre disposent d'un patch depuis des années. La CISA ne découvre pas des zero-days, elle constate que le parc à patcher est toujours aussi béant, y compris dans les administrations fédérales US. Côté SI de PME françaises qui tournent sur un Exchange vieillissant, je vous rassure le tableau n'a aucune raison d'être meilleur.

Patcher Exchange reste un gros chantier pour beaucoup d'équipes IT, entre les dépendances métier, les interfaces custom et la peur de casser la messagerie. Sauf que voilà, tant que ce n'est pas fait, le ransomware a un boulevard.

Bref, si vous avez un Exchange ou un Windows qui traîne avec des patches manquants depuis 2012 ou 2023, c'est vraiment le moment de vous y coller.

Source : The Register

Le groupe de hackers ShinyHunters affirme avoir piraté Rockstar Games. Ils menacent de publier tous les documents confidentiels volés sur le dark web si le studio ne leur verse pas de rançon. Le message des hackers est clair : "Pay or leak."

Les pirates ne sont pas entrés chez Rockstar par la grande porte. Ils sont passés par Anodot, un outil que le studio utilise pour analyser ses factures cloud. Une brèche chez Anodot début avril leur a donné des identifiants qui ouvraient aussi les bases Snowflake de Rockstar, là où dormaient une bonne partie des documents internes.

C'est la même méthode qu'en 2024, quand un autre pirate avait vidé les comptes Snowflake de Ticketmaster, AT&T et Santander en récupérant leurs mots de passe ailleurs. Snowflake n'est pas piraté, ce sont ses clients qui se font prendre leurs clés.

Côté butin, rien de très excitant a priori pour un fan de GTA. D'après les premiers éléments, les pirates ont surtout récupéré des contrats, des documents financiers, des plans marketing et d'autres fichiers sans intérêt. Pas de code source, pas de cinématiques, pas de données de joueurs, en tous cas sur le papier.

Rockstar confirme d'ailleurs la brèche dans un communiqué très calibré : le studio parle d'une "quantité limitée d'informations non stratégiques" volées chez un prestataire, et assure que l'incident n'a "aucun impact sur notre organisation ni sur nos joueurs."

Rassurant ? À moitié. ShinyHunters n'est pas un collectif de bricoleurs, le groupe est actif depuis 2020 et a déjà siphonné Microsoft, Ticketmaster, Cisco, AT&T ou Wattpad. Quand ils annoncent avoir des fichiers, ils les ont, et ils savent les revendre sur les forums fermés.

Personne ne sait encore si les plans marketing volés contiennent des détails sur GTA VI, dont la date de sortie continue de faire transpirer Take-Two, l'éditeur du studio.

Le plus embêtant pour Rockstar, c'est surtout que ça recommence. En 2022, un adolescent britannique avait infiltré le Slack du studio pour diffuser des vidéos d'un GTA VI en pré-production, affaire soldée par une condamnation au Royaume-Uni.

Quatre ans plus tard, le studio se refait attraper, cette fois via un prestataire. Visiblement, le maillon faible n'est plus toujours en interne : un petit outil de suivi de coûts cloud peut suffire à faire sauter le verrou, comme un compte admin oublié.

Bref, les fans vont scruter la moindre ligne leakée, Rockstar va serrer la vis côté prestataires, et ShinyHunters continuera de taper partout où traînent des accès Snowflake mal sécurisés.

Source : Kotaku

Le FBI, la CISA, la NSA, l'EPA, le département de l'Énergie et le Cyber Command américain ont publié un avis conjoint qui ne laisse pas beaucoup de place au doute. Des hackers affiliés à l'Iran ciblent activement les automates programmables connectés à internet sur le sol américain.

Plus précisément, ce sont les contrôleurs Rockwell Automation / Allen-Bradley qui sont visés, et si vous ne comprenez pas de quoi on parle, ce sont en fait les petits ordinateurs industriels qui pilotent des vannes, des pompes ou des turbines dans les usines.

Le groupe en question, déjà connu sous le nom de CyberAv3ngers et lié au Corps des Gardiens de la révolution islamique, scanne le web à la recherche de PLC exposés sur plusieurs ports (44818, 2222, 102, 502).

Une fois en place, les attaquants peuvent manipuler les interfaces homme-machine et les écrans SCADA, modifier des fichiers de projet et, dans certains cas, tenter de déployer des malwares de type "wiper" pour effacer les données des systèmes compromis.

Eau, énergie, collectivités locales, la totale

Les secteurs touchés sont ceux qu'on redoute le plus dans ce genre de scénario : stations de traitement d'eau, installations énergétiques (centrales, raffineries), et même des collectivités locales. Plusieurs victimes ont subi des arrêts de production forcés, avec un basculement en mode manuel et des pertes financières que le FBI n'a pas voulu chiffrer publiquement.

Ce n'est pas la première fois que ce groupe fait parler de lui. Fin 2023, CyberAv3ngers avait déjà piraté des automates Unitronics dans une station d'eau en Pennsylvanie, tout simplement en exploitant des mots de passe par défaut.

Dès 2024, ils sont passés à la vitesse supérieure avec du malware sur mesure contre des systèmes d'eau et de carburant. La campagne actuelle, qui est active depuis mars 2026, marque un nouveau cran dans l'escalade.

Même s'il baisse un peu en intensité depuis quelques heures, le conflit entre les États-Unis, Israël et l'Iran a débuté le 28 février 2026 avec des frappes aériennes. Depuis, les opérations cyber iraniennes se sont accélérées, aussi bien contre des cibles américaines qu'israéliennes.

"Les acteurs iraniens bougent plus vite, plus largement, et ciblent désormais à la fois les infrastructures IT et OT", a résumé Sergey Shykevich, chercheur chez Check Point.

Côté recommandations, les agences américaines demandent aux opérateurs de déconnecter immédiatement tous les équipements industriels d'internet, d'appliquer les correctifs Rockwell, d'activer l'authentification multifacteur et de surveiller le trafic entrant sur les ports concernés. Le b.a.-ba donc, mais visiblement pas encore appliqué partout.

En tous cas, six agences fédérales qui publient un avis commun, ça donne une idée de la gravité du truc. Le fait que des hackers puissent encore trouver des automates industriels directement accessibles depuis internet en 2026, c'est quand même assez idiot. Surtout quand ils contrôlent des stations d'eau ou des centrales énergétiques.

Source : CNN

ChipSoft, l'éditeur qui fournit le logiciel de dossiers médicaux à environ 80 % des hôpitaux aux Pays-Bas, vient d'être touché par un ransomware. Le site de l'entreprise est hors ligne depuis le 7 avril, et on ne sait pas encore si des données de patients ont été volées.

Ce qu'il s'est passé

L'attaque a été confirmée le 7 avril par Z-CERT, l'agence néerlandaise qui surveille la sécurité informatique dans le secteur de la santé. ChipSoft développe le logiciel HiX, qui gère les dossiers médicaux de patients dans la grande majorité des hôpitaux du pays. Le site web de l'entreprise est tombé dans la journée et reste inaccessible.

Z-CERT a envoyé un mémo confidentiel aux clients de ChipSoft pour leur demander de couper leur connexion VPN vers les systèmes de l'éditeur. Onze hôpitaux ont déconnecté leurs systèmes par précaution. Les autres ont indiqué que leurs données patients étaient en sécurité et que leurs services continuaient de fonctionner.

Des données patients potentiellement compromises

ChipSoft a confirmé qu'il y avait eu un "incident de données" avec un "possible accès non autorisé". L'entreprise ne peut pas garantir que des données de patients n'ont pas été consultées ou copiées. Le groupe de hackers derrière l'attaque n'a pas été identifié, et aucun montant de rançon n'a été rendu public.

Plusieurs hôpitaux, dont le Rijnstate Hospital, l'Antoni van Leeuwenhoek (spécialisé en cancérologie) et le Franciscus Hospital ont déclaré ne pas être affectés. Mais la portée réelle de l'attaque reste floue.

Le secteur de la santé toujours en première ligne

Z-CERT classe les ransomwares et l'extorsion comme les menaces principales pour les organisations de santé néerlandaises dans son rapport annuel.

Le secteur reste une cible privilégiée parce que les données médicales ont une valeur élevée sur le marché noir, et que les hôpitaux ne peuvent pas se permettre de rester longtemps sans accès à leurs systèmes.

Quand un seul éditeur gère les dossiers médicaux de 80 % des hôpitaux d'un pays, une attaque sur cet éditeur prend une dimension un peu inquiétante.

Pour l'instant les dégâts semblent contenus, mais le fait que ChipSoft ne puisse pas exclure un vol de données, c'est quand même un gros point d'interrogation. Et ça rappelle qu'un système de santé aussi centralisé, ça peut vite devenir une faiblesse.

Source : NL Times