Environ 75 000 pare-feu Fortinet ont vu leurs identifiants de connexion volés puis vérifiés un par un, des FortiGate, ces boîtiers qui filtrent l'accès au réseau des entreprises et servent très souvent de porte d'entrée VPN pour les salariés en télétravail.

Baptisée FortiBleed par les chercheurs qui l'ont mise au jour, la campagne couvre 194 pays et plus de 21 000 domaines, soit à peu près la moitié des pare-feu Fortinet exposés sur Internet à l'heure actuelle.

Parmi les organisations dont les accès se sont retrouvés dans la nature, on relève des noms qui n'ont rien d'amateur en matière de sécurité : Foxconn, Samsung, Comcast, Siemens, Lenovo, FedEx, Accenture ou encore Oracle.

Toute l'ironie de l'affaire tient là : le pare-feu, l'appareil précisément chargé de tenir les intrus à l'écart du réseau, s'est transformé en point d'entrée qui leur a ouvert la porte en grand.

Sur le plan technique, les attaquants interceptaient l'authentification du SSL VPN, cet accès distant chiffré qui permet de rejoindre le réseau interne d'une entreprise depuis l'extérieur, récupéraient l'empreinte chiffrée des mots de passe et la cassaient sur une grappe de 45 cartes graphiques pilotée par l'outil Hashtopolis, avant de basculer vers l'Active Directory, l'annuaire qui gère l'ensemble des comptes Windows de l'organisation.

Les volumes traités donnent la mesure de l'opération : 1,16 milliard de tentatives de connexion lancées contre 320 000 équipements FortiGate, et 2,1 milliards d'autres dirigées en parallèle vers 160 000 serveurs de bases de données Microsoft.

Au moins quatre organisations ont été entièrement compromises, avec déplacement des attaquants d'une machine à l'autre à l'intérieur du réseau, au Japon, à Taïwan, au Vietnam, en Irak et en Turquie. Le cas le plus sérieux touche un sous-traitant turc de la défense, membre de l'OTAN, chez qui des documents classifiés ont été volés. Tout ça est attribué à un groupe cybercriminel russophone à plusieurs opérateurs.

C'est le chercheur Bob Diachenko qui a repéré les intrusions, avant que Hudson Rock (une société spécialisée dans l'analyse des données aspirées par les logiciels espions) ne décortique le tout et que Kevin Beaumont confirme que les identifiants étaient bien valides.

Hudson Rock a d'ailleurs mis en ligne une liste des domaines concernés, histoire que chaque entreprise vérifie si elle figure au tableau de chasse.

Fortinet, de son côté, minimise et parle d'un recyclage de données issues d'incidents passés et de simples attaques par force brute, pas d'une nouvelle faille dans ses produits.

Sauf que voilà : la plupart des boîtiers concernés sont toujours en ligne. Recyclées ou pas, ces données ouvrent une porte bien réelle tant que les mots de passe VPN et administrateur n'ont pas été changés, et changer tous les accès d'un pare-feu dans une grande organisation ne se fait pas en claquant des doigts.

Bref, faille ou vieux stock recyclé, ça ne change rien pour les boîtes touchées : on change les mots de passe VPN tout de suite, et on active la double authentification.

Source : The Register

Le FBI possède sa propre ville, sauf que personne n'y habite, et pour cause, elle a été montée de toutes pièces dans un hangar de Huntsville, en Alabama, avec ses maisons meublées, son hôtel, sa station-service, son épicerie, son tribunal, son hôpital et jusqu'à sa compagnie d'électricité, le tout dans un seul but assez vertigineux, la pirater dans tous les sens sans jamais déranger âme qui vive.

Le décor porte d'ailleurs un nom, le Kinetic Cyber Range, près de 2 000 mètres carrés de fausse bourgade américaine ouverte en février 2025 et pensée comme un gigantesque bac à sable pour cyberattaques en conditions réelles.

Le fisc italien a frappé fort il y a quelques jours. La Guardia di Finanza, sous la direction du parquet de Bologne, vient de démanteler un réseau de piratage de streaming baptisé Cinemagoal, dans une opération nommée "Tutto Chiaro" (tout clair, en italien).

Plus de 100 perquisitions ont été menées dans 17 régions du pays, plus des saisies coordonnées en France et en Allemagne via Eurojust (l'agence européenne qui coordonne les enquêtes judiciaires entre pays de l'UE). Joli coup de filet.

Le système était assez bien huilé. Cinemagoal proposait à ses clients un accès à Netflix, Disney+, Spotify, Sky et DAZN pour 40 à 130 euros par an, soit une fraction du prix de l'ensemble des abonnements officiels.

Pour faire fonctionner ce petit business, l'équipe derrière l'appli avait monté une infrastructure de machines virtuelles en Italie qui aspiraient en permanence les clés de déchiffrement DRM (les codes numériques qui débloquent la lecture des contenus protégés) à partir de vrais comptes payants.

Toutes les trois minutes, de nouvelles clés étaient renvoyées aux clients, ce qui rendait le système difficile à bloquer en temps réel par les plateformes officielles.

L'astuce des trois minutes n'était pas innocente. En renouvelant les clés à intervalle court, Cinemagoal contournait les outils antifraude que Netflix et consorts utilisent pour détecter les comportements bizarres sur un compte. Difficile pour la plateforme de repérer un piratage à grande échelle quand chaque clé volée n'est utilisée que quelques minutes avant d'être remplacée.

Côté budget, l'enquête estime à environ 300 millions d'euros le manque à gagner cumulé pour les ayants droit sur plusieurs années. Les autorités ont aussi mis la main sur les serveurs étrangers qui hébergeaient le code source complet de l'appli et les bases de données de clés, ce qui devrait empêcher le service de redémarrer sous un autre nom.

Plus inhabituel, l'opération s'attaque aussi aux utilisateurs finaux. Environ un millier d'abonnés à Cinemagoal ont été identifiés et reçoivent en ce moment des avis d'amende administrative allant de 154 à 5 000 euros. C'est une approche assez différente de ce qu'on voit en France, où les pirates côté consommateurs sont rarement inquiétés (ouf). L'idée du parquet italien, c'est vraiment de faire peur.

Et puis il y a la question de la durée. Cinemagoal tournait depuis plusieurs années sans gros problème, ce qui veut dire que les plateformes officielles ont mis du temps à repérer la fuite, ou en tout cas à coordonner une réponse efficace avec les autorités. Vu les sommes en jeu, ça pose quand même la question de la solidité des protections DRM actuelles face à des équipes techniques motivées pour tout pirater.

Source : Bleeping Computer

Si vous venez d'acheter un portable HP équipé d'un Intel Core Ultra Series 3 (nom de code Panther Lake) et que vous y faites tourner Linux, vous allez accueillir cette nouvelle avec une certaine satisfaction. Intel et HP ont enfin poussé le firmware nécessaire à l'activation du fameux Integrated Sensor Hub dans linux-firmware.git, le dépôt officiel utilisé par à peu près toutes les distributions Linux du marché.

Petite mise en contexte quand même... Vous le savez, le firmware, c'est le tout petit logiciel bas niveau qui permet à un composant matériel de fonctionner. Et l'Integrated Sensor Hub (l'ISH pour les intimes), c'est un co-processeur intégré dans les puces Intel récentes.

Son job est de gérer les capteurs du laptop (orientation de l'écran, accéléromètre, gyroscope, capteurs de lumière, etc.) sans déranger les gros cœurs du CPU principal. Ça permet en fait à la machine de capter ce qu'il se passe autour d'elle même quand elle est en veille, sans vider la batterie.

Le problème, c'est que ce petit co-processeur a besoin d'un firmware spécifique pour fonctionner. Et sans ce firmware, l'ISH était muet sur Linux. Résultat : des fonctions comme la rotation automatique de l'écran sur un PC convertible, l'allumage à la détection de présence ou les économies d'énergie liées aux capteurs ne fonctionnent tout simplement pas, ou alors franchement mal.

Le pilote était déjà dans le noyau Linux depuis longtemps. C'est la pièce manquante, le firmware lui-même, qui était à la bourre. Sans lui, il faut bidouiller, copier des fichiers à la main depuis Windows, ou faire une croix sur certaines fonctions. C'est le genre de situation qui fait fuir les utilisateurs vers Windows ou macOS sur du matos neuf.

De la part d'HP, c'est plutôt un bon rattrapage. Le constructeur historique pousse régulièrement des laptops pré-installés avec Linux à destination des développeurs et des entreprises (la gamme ZBook sous Ubuntu, par exemple, qui existe depuis quelques années). Avoir un bon support dès la sortie du carton, ça compte vraiment pour ce public-là, qui ne veut pas passer une heure à chasser les firmwares disparus pour faire marcher son trackpad ou son lecteur d'empreintes.

Intel, de son côté, a fait pas mal d'efforts ces derniers temps pour simplifier sa licence de firmware et accélérer la mise à dispo de ces fichiers binaires pour Linux. On a d'ailleurs vu la même histoire avec le firmware NPU (la puce dédiée à l'intelligence artificielle) qui a été publié juste avant pour Panther Lake.

Bref, pour qui voulait passer à un laptop HP Panther Lake sous Linux dès maintenant, le timing est devenu nettement meilleur.

Source : Phoronix

Si vous avez remarqué récemment que les logos de vos correspondants pros sont remplacés par une vilaine croix rouge dans Outlook, ou pire, que certaines pièces visuelles disparaissent purement et simplement de vos mails, ce n'est ni votre antivirus ni votre connexion.

The Register a sorti le sujet la semaine dernière, et Microsoft a fini par confirmer un bug introduit dans la version 2604 (Build 19929.20164) de Classic Outlook, qui fait planter l'affichage de certaines images dans les emails.

Le problème ne touche pas n'importe quelle image. La condition pour le déclencher, c'est d'avoir une option de mise en page particulière activée, "Habiller le texte en haut et en bas" (l'image flotte au-dessus du texte avec le contenu qui s'écoule au-dessus et en dessous).

Avec cette configuration, Outlook se prend les pieds dans le tapis et affiche à la place un message d'erreur du genre "L'image liée ne peut pas être affichée. Le fichier a peut-être été déplacé, renommé ou supprimé.", ou parfois rien du tout, juste un trou blanc.

Le plus pénible, c'est que les premières victimes sont les signatures de mail qui contiennent un logo d'entreprise. Vous savez, ce petit truc obligatoire qui doit faire identité de marque sur chaque message envoyé. Eh bien, chez pas mal de monde, ces logos se retrouvent désormais accompagnés d'une jolie croix rouge ou d'une boîte vide. Pratique pour faire pro auprès des clients.

Microsoft a publié sur son site de support un correctif temporaire qui consiste à demander aux utilisateurs de changer le réglage d'habillage de leurs images, en passant sur un autre mode (intégré dans le texte, derrière le texte, etc.). Pas idéal. Encore moins quand on ne sait même pas où trouver ce réglage et qu'on l'a mis en place il y a deux ans avec l'aide du service info de la boîte.

Pour la suite, c'est encore moins drôle. Microsoft précise que les images des messages d'origine reviendront normalement une fois le correctif déployé, ce qui est plutôt rassurant. Sauf que pour les réponses ou les transferts faits pendant la période bugée, certaines images peuvent disparaître définitivement, parce qu'elles ne se seront tout simplement pas attachées au nouveau message.

Ce qui veut dire que tout un fil de discussion sur un projet visuel risque de perdre des morceaux en chemin sans qu'on s'en rende compte tout de suite.

Aucune date n'est annoncée pour le déploiement du correctif définitif. C'est typiquement le genre de bug qui aurait dû être attrapé en interne avant publication, sur une fonctionnalité aussi basique que l'affichage d'une image.

Et c'est aussi un rappel utile que Classic Outlook (la version installée historiquement sur Windows, par opposition au New Outlook web) reste largement utilisée en entreprise et que ses bugs touchent vraiment beaucoup de monde.

Au passage, si vous hésitez entre attendre le correctif et passer sur le nouveau Outlook ou un client tiers, ça peut être l'occasion de jeter un œil ailleurs.

Source : The Register

J'sais pas si vous avez vu, mais sur les Motorola Razr 2026, l'app maison Smart Feed intercepte le lancement de l'application Amazon pour y glisser en soumsoum un petit code d'affiliation. Comme ça, à chaque fois que vous tapez sur l'icône Amazon, votre clic se met à rapporter une commission à un compte tiers. Vous ne payez pas un centime de plus rassurez-vous, c'est le principe de l'affiliation, mais il me semble que c'est pas très réglo de ne pas le dire. En plus je pense que ça va à l'encontre des CGU d'Amazon... Breeeef, y'a rien qui va dans cette histoire.

Le truc se déclenche donc uniquement quand vous ouvrez Amazon le menu des applications, et pas depuis un raccourci sur l'écran d'accueil. A ce moment là, pendant une fraction de seconde, Chrome clignote à l'écran, et votre téléphone passe par un site nommé kira-abboud.com, pour ensuite utiliser un lien qui repart vers l'app Amazon avec le code d'affiliation sramz-kff-008-20 comme si de rien n'était. Comme ça Amazon, pense que vous arrivez de ce lien affilié.

C'est tellement rapide que la plupart des gens ne verront jamais rien....

Sauf que kira-abboud.com renvoie vers une influenceuse mode, @kirasfashionfinds présente sur Instagram, et qui n'a aucun lien apparent avec Motorola. Pire, le code d'affiliation collé à votre session ne correspond même pas à ceux qu'elle a déjà publiés. Et voilà comment on se retrouve avec un téléphone vendu par une grosse marque qui détourne vos clics vers un compte tiers, sans la moindre explication.

Côté technique, les logs réseau pointent vers devicenative.com. C'est une régie qui place de la pub sur les smartphones via un SDK intégré aux launchers Android, avec une intégration Motorola documentée. En clair, le mécanisme qui pourrit votre app Amazon pointe vers un kit publicitaire préinstallé d'usine.

Reste à savoir maintenant si c'est un choix assumé de Motorola ou un SDK pub qui part en vrille, voire un hack... et pour l'instant, personne ne le sait.

Google a balancé l'info via son équipe cyberdéfense, le GTIG (Google Threat Intelligence Group). Des cybercriminels ont utilisé une IA générative pour dénicher et écrire un code d'attaque exploitant une faille inconnue (ce qu'on appelle un zero-day, une vulnérabilité que l'éditeur du logiciel n'a pas encore corrigée).

Et ils s'apprêtaient à lancer une vague d'attaques massives. C'est, d'après Google, la première fois qu'on observe ça dans la vraie vie, pas en labo.

La faille concernait un outil d'administration de serveur open-source très utilisé, dont Google ne donne pas le nom (le temps que tout le monde installe le correctif).

Le bug permettait de contourner la double authentification, le fameux code à 6 chiffres ou la notification sur le téléphone qui sécurise vos comptes. En pratique, il fallait quand même un identifiant et un mot de passe valides au départ, donc ce n'est pas une attaque magique en un clic. Mais une fois ce sas franchi, la 2FA tombait toute seule.

Ce qui a mis la puce à l'oreille des chercheurs, c'est l'allure du script Python utilisé pour exploiter la faille. Trop bien écrit, trop documenté, trop scolaire en fait.

Il était bourré de commentaires pédagogiques (le genre qu'on retrouve dans un tuto pour débutant), il affichait un menu d'aide impeccable, et surtout un score de dangerosité CVSS complètement inventé. Cette dernière trouvaille, c'est l'indice qui ne trompe pas, seul un modèle de langage peut halluciner un chiffre officiel avec autant d'aplomb.

John Hultquist, le chef analyste du GTIG, explique que les IA génératives sont vraiment douées pour repérer ce genre de faille logique de haut niveau, là où les outils d'audit classique (les "fuzzers" qui bombardent un logiciel de données aléatoires pour le faire planter) passent à côté.

Google précise au passage que ce n'est pas Gemini, son propre modèle d'IA, qui a été utilisé. Lequel alors ? Mystère, l'équipe de Mountain View ne le dit pas. On imagine que les criminels n'ont pas demandé poliment l'autorisation à un éditeur d'IA. Affaire à suivre.

Le rapport donne d'autres pépites. Le groupe nord-coréen APT45 utiliserait l'IA pour tester des milliers d'exploits en masse. Des opérateurs chinois liés à l'État expérimenteraient l'IA pour chasser les vulnérabilités.

Des backdoors (des portes dérobées cachées) sur Android interrogent directement Gemini pour piloter les téléphones infectés. Et côté désinformation, des opérations russes intègrent du faux audio généré par IA dans de vraies images d'actualités. Bref, ça bouge de partout.

Bonne nouvelle quand même, la campagne d'attaque massive a été désamorcée. Google a coordonné un correctif discret avec l'éditeur avant que les criminels puissent appuyer sur le bouton. Cette fois.

Bref, l'IA fabrique maintenant des armes prêtes à l'emploi pour les criminels, et personne ne sait quel modèle a fait le boulot. Rien de rassurant donc.

Source : The Hacker News

60% des mots de passe hashés en MD5 peuvent être cassés en moins d'une heure... C'est ce que dit en tout cas une étude de Kaspersky publiée cette semaine qui se base sur +231 millions de mots de passe qu'on peut trouver sur le dark web et tirés de fuites ayant eu lieu entre 2023 et 2026. D'après leurs tests, 48% sont craqués en moins d'une minute et 60% en moins d'une heure. C'est pas très rassurant, surtout si votre base tourne encore au MD5.

Ce qui a changé ces dernières années, c'est surtout la puissance des GPU modernes qui n'a cessé d'augmenter. Par exemple, une RTX 5090 monte à 220 milliards de hash MD5 par seconde ce qui représente une augmentation de +34% par rapport à la RTX 4090 ! Du coup, louer un GPU cloud pour lancer une attaque par dictionnaire revient à quelques dizaines de centimes à quelques dollars de l'heure. C'est rentable hein ?

L'étude souligne aussi que 53% des mots de passe du corpus se terminent par des chiffres. Et là, du point de vue des règles hashcat, c'est du pain bénit car les crackers adorent la prévisibilité. Alors attention si vous administrez un service web avec une gestion de comptes utilisateur car les attaques modernes (dictionnaire + règles hashcat) règlent aujourd'hui son compte à une bonne partie du corpus et cela en moins d'une minute. Par contre, les mots de passe longs avec symboles variés résistent encore puisque c'est exponentiel ! Vaut mieux une phrase de passe avec plein de mots et facile à retenir du genre running-douche-afford-laborer-art-amber-deftly-acetone-lego-reoccupy qu'un mot de passe court et complexe comme 3d2^vO$RZ1.

Bref, MD5 pour les mots de passe c'est mort donc si vous avez encore ça dans vos bases, migrez moi tout ce bordel rapidement ! La migration maintenant, ça se fait vers Argon2id en priorité... Je balance pas ça au pif, hein, c'est le standard recommandé par OWASP et le NIST, et c'est memory-hard, donc les GPU ne peuvent pas juste brute-forcer des milliards de hashs par seconde comme avec MD5.

Après si votre stack est ancienne et qu'Argon2id n'est pas dispo, bcrypt reste une option solide. Dans tous les cas, évitez SHA-1, SHA-256 ou SHA-512 sans algorithme adaptatif car ils sont rapides par conception, donc tout aussi crackables que MD5.

Source

Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.

L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.

Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!

La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.

Alors comment ça marche ?

Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.

Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.

Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.

Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.

Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.

Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.

Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.

En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.

Tester avec Lima sur macOS

Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :

# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :

Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.

Alors que faire ?

Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.

Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...

En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.

Source : https://github.com/V4bel/dirtyfrag

Y'a des génies du crime, et puis y'a Peter Stokes, alias Bouquet, 19 ans, presque toutes ses dents, double nationalité américano-estonienne, et surtout membre de Scattered Spider, le collectif qui a déjà plumé MGM et Caesars.

Le mec a tellement bien réussi son coup qu'il est parti se payer des vacances à Tokyo, sauf que pour fêter ça, en bon teubé, il a posté sur Snapchat des selfies de sa grosse tête avec un tout nouveau bijou : un collier en diamants HACK THE PLANET. Comme dans le film de 1995 mais en plus bling bling !

Hé bien grâce à ça, le FBI a fini par le coffrer lors de son escale d'Helsinki.

Bouquet (oui, j'ai pas précisé mais c'est son pseudo) opérait donc dans le groupe Scattered Spider, ce collectif d'ados anglophones qui ne s'embête pas avec des failles zero-day parce que de toute façon, ils ne sauraient pas les utiliser.

À la place, ils ont leur propre méthode super technique vous allez voir... ils appellent le support IT de la cible et embobinent un pauvre mec pour qu'il reset le 2FA d'un admin.

Et voilà comment notre cher Bouquet a pu sortir 100 Go de données d'un revendeur de produits de luxe (la plainte désigne sobrement la "Company F", mais ça pue Harrods d'après la presse anglaise) en seulement quelques heures, réclamé 8 millions de rançon, et causé plus de 2 millions de dégâts.

Du coup, plainte fédérale à Chicago, 6 chefs (wire fraud, conspiracy, computer intrusion comme ils disent là-bas avec l'accent cowboy), + extradition vers les USA en cours. C'est le bouquet final pour lui ! (Oui, jeu de mots, roh roh roh).

Tyler Buchanan, 24 ans, autre membre du club, a de son côté déjà plaidé coupable d'avoir empoché 8 millions en crypto via du SMS phishing. Faut dire qu'en 2024, le groupe envoyait fièrement des messages genre "Fuck off, FBI" aux agents fédéraux qui enquêtaient sur eux.

Très rebelles nos kikoulool ! Enfin, comme vous le savez, qui fait le malin tombe dans le ravin, et qui fait le mariole avec un collier finit avec des bracelets ^^. (J'ai pas trouvé mieux, déso... lol)

Bref, Bouquet vient à lui seul d'écrire le chapitre 1 du manuel "Comment ne PAS être un cybercriminel à succès" et dont la règle n°1 est : "Si t'es recherché par le FBI, ne montre pas ton butin sur Snapchat"

Source

Énorme retournement de situation. ShinyHunters, le groupe qui avait piraté Rockstar via Anodot mi-avril et exigé une rançon, a fini par balancer ses données sur internet quand l'éditeur a refusé de payer. Le but était de faire mal financièrement à Take-Two, sauf que les chiffres révélés étaient si impressionnants que l'effet a été l'exact opposé. En effet, l'action Take-Two est passée d'environ 202 dollars à presque 208 dollars en une matinée, soit une capitalisation boursière qui a pris à peu près un milliard de dollars dans la foulée. C'est fou !

Ce que les hackers ont mis en ligne, c'est notamment que GTA Online génère plus d'un million de dollars par jour , soit autour de 500 millions par an. Et tout cela, 13 ans après le lancement sur 5 plateformes différentes, simplement grâce aux Shark Cards (les cartes prépayées du jeu). Pour un éditeur qui s'apprête à sortir son GTA 6 en novembre prochain, faut dire que ce genre de stats montre qu'ils ont les reins hyper solides, ce qui rassure les investisseurs.

Bref, au lieu de sanctionner Take-Two pour la fuite de données et la faille Anodot, Wall Street y a simplement vu la confirmation de ce que tout le monde soupçonnait : la machine à cash de Rockstar tourne à plein régime, et un éventuel GTA 6 au même niveau de monétisation, même partielle, ferait exploser les compteurs !!

Rockstar a également publié une déclaration courte et carrée pour dire que la violation n'aurait pas d'impact sur le studio ou le dev de GTA 6. Rien de plus...

C'est donc un retournement de situation assez fou côté où des hackers, en cherchant à frapper l'éditeur au portefeuille, lui ont en fait permis de gonfler sa capitalisation d'un milliard. Difficile de faire pire en termes de coup raté ^^. A moins que les gens de ShinyHunters aient fait un peu de délit d'initié en amont avant de leaker les données... allez savoir ??

Reste à voir si la SEC ou les autorités européennes voudront enquêter sur cette fuite, sachant qu'au passage des données salariés et de joueurs ont aussi été exposées. Quoiqu'il en soit, côté marché, c'est plié et le cours de l'action est resté bien haut !

Source

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

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

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

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

Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.

Un processeur de 1989

L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.

Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.

La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.

Du ménage dans le code

Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.

Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.

Et le 32 bits, alors ?

Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.

Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.

Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.

Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.

En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !

Source : Phoronix

60 Mo de source maps (ces fichiers qui permettent de remonter du code minifié à l'original) ont été oubliés dans un paquet npm. Et voilà comment Anthropic a involontairement balancé en public le code source complet de Claude Code, son outil à 2.5 milliards de dollars de revenus annuels.

Alors qu'est-ce qui s'est passé exactement ?

Hé bien hier, la version 2.1.88 du package @anthropic-ai/claude-code sur le registre npm embarquait un fichier .map de 59.8 Mo. Un truc normalement réservé au debug interne, sauf que ce fichier .map contenait les pointeurs vers les 1 900 fichiers TypeScript originaux, en clair. Chaofan Shou, un développeur chez Solayer Labs, a alors repéré la boulette et l'a partagée sur X. Le temps qu'Anthropic réagisse, le code était déjà mirroré partout sur GitHub, avec 41 500+ forks en quelques heures. Autant dire que le dentifrice ne rentrera pas dans le tube !

Pour ma part, j'avais un petit dépôt à moi assez ancien avec quelques trucs relatifs à Claude Code, qui n'avait rien à voir avec tout ça, qui s'est même retrouvé striké... Ils ratissent large avec leur DMCA donc.

Et là, c'est la fête pour les curieux comme moi parce que les entrailles de l'outil révèlent pas mal de surprises. Côté architecture, on découvre environ 40 outils internes avec gestion de permissions, un moteur de requêtes de 46 000 lignes de TypeScript, un système multi-agents capable de spawner des essaims de sous-tâches en parallèle, et un pont de communication entre le terminal et votre éditeur VS Code ou JetBrains. Le tout tourne sur Bun (pas Node.js ^^) avec Ink pour l'interface terminal. Par contre, pas de tests unitaires visibles dans le dump.

Côté mémoire, c'est plutôt bien pensé puisqu'au lieu de tout stocker bêtement dans la fenêtre de contexte du modèle, l'outil utilise un fichier texte MEMORY.md ultra-léger (genre 150 caractères par entrée) qui sert d'index de pointeurs. Les vraies données, elles, sont distribuées dans des fichiers thématiques chargés à la demande, et les transcripts bruts ne sont jamais relus entièrement, mais juste fouillés à la recherche d'identifiants précis. L'agent traite en fait sa propre mémoire comme un "hint" ce qui le force à vérifier toujours le vrai code avant d'agir. En gros, il a une mémoire sceptique, et pour moi c'est clairement le truc le plus intéressant du dump.

Y'a aussi un truc qui s'appelle KAIROS (mentionné 150 fois dans le code) qui est un genre de mode daemon autonome. En fait, pendant que vous allez chercher votre café, l'agent tourne en arrière-plan et fait ce qu'ils appellent autoDream : il consolide sa mémoire dans des fichiers JSON, vire les contradictions et transforme les observations vagues en données structurées. Comme ça, quand vous revenez devant votre écran, le contexte est nettoyé.

Et puis le code balance aussi la roadmap interne d'Anthropic (bon courage au service comm ^^). On y trouve les noms de code des modèles... Capybara pour un variant de Claude 4.6, Fennec pour Opus 4.6, et un mystérieux Numbat qui n'est pas encore sorti. D'ailleurs, les commentaires internes révèlent que Capybara v8 a un taux de fausses affirmations qui tourne autour de 30%, ce qui est une grosse régression par rapport aux 17% de la v4. Y'a même un "Undercover Mode" qui permet à l'agent de contribuer à des repos publics sans révéler d'infos internes (c'est sympa pour les projets open source).

Anthropic a confirmé la fuite : "C'était un problème de packaging lié à une erreur humaine, pas une faille de sécurité. Aucune donnée client n'a été exposée." Mouais, attention quand même, parce que le code est déjà partout et n'en repartira pas. Et même si aucun secret client n'a fuité, exposer l'architecture complète d'un agent IA à 2.5 milliards de revenus, c'est pas rien non plus.

Bon, et maintenant qu'est-ce qu'on peut en faire ? Bah pas mal de choses en fait.

Par exemple, le système de mémoire auto-correcteur est un pattern directement réutilisable pour vos propres agents IA. L'architecture "index léger + fichiers à la demande" résout élégamment le problème de la pollution de contexte qui fait halluciner les LLM sur les longues sessions. Les +40 outils internes permettent aussi de comprendre comment structurer un système de permissions granulaires dans un agent autonome . Et le concept KAIROS/autoDream, la consolidation mémoire pendant l'idle, c'est une idée qu'aucun outil open source n'implémente encore. Autant dire que les alternatives open source à Claude Code ou Codex vont monter en gamme dans les jours qui viennent. Et le code est déjà nettoyé, réécris en Rust et mis sur GitHub si vous voulez fouiller. Bon, pas sûr que le pattern autoDream soit simple à reimplémenter, mais le système de mémoire oui.

Je trouve ça assez marrant que le code proprio d'une boite qui a aspiré tout l'open source du monde voire plus, sans autorisation, pour le revendre sous la forme de temps machine / tokens, devienne lui aussi en quelque sorte "open source" sans qu'on leur demande leur avis ^^. La vie est bien faite.

Maintenant, pour les développeurs qui publient sur npm, la leçon est limpide : Vérifiez votre .npmignore et votre champ files dans package.json. Ou plutôt, lancez la commande npm pack --dry-run dans votre terminal avant chaque publish. Ça prend 2 secondes et ça vous montre exactement ce qui sera inclus dans le paquet. Ça aurait évité 60 Mo de secrets industriels qui partent en public.

Bref, un .npmignore bien configuré, ça coûte 0 euro. Alors qu'une fuite de propriété intellectuelle évaluée à 2.5 milliards... un peu plus !

Source

Le fichier national qui recense toutes les armes détenues en France vient de se faire trouer en version XXL !

En effet, un affreux pirate a réussi à exfiltrer les données liées à la possession de plus de 62 000 armes, et parmi elles, les noms, prénoms, dates de naissance, adresses email et surtout les adresses postales de leurs propriétaires. Mais ce n'est pas tout puisque le fichier contiendrait également le détail complet de chaque arme (modèle, calibre, numéro de série, classement) ainsi que l'historique des transactions (ventes, cessions, réparations, destructions).

Donc on a maintenant dans la nature un joli tableur Excel avec en colonne A le numéro de série de votre Beretta, et en colonne B votre adresse.

J'vois vraiment pas ce qui pourrait mal tourner... 🤡

Alors pour ceux qui débarquent, le SIA (Système d'Information sur les Armes) c'est LA base de données du ministère de l'Intérieur dans laquelle tous les détenteurs d'armes doivent obligatoirement s'enregistrer. Que vous soyez chasseur avec votre Browning, tireur sportif avec votre Glock ou que vous ayez hérité du vieux Manufrance de papy, vous êtes dedans !!

Le ministère a d'ailleurs confirmé l'intrusion dans un courrier envoyé aux personnes concernées (environ 41 000 détenteurs selon les dernières estimations).

En fait, le cybercriminel a compromis les identifiants d'un armurier situé dans le département 84 (c'est le Vaucluse pour les nuls en géo) et a accédé à son Livre de Police Numérique (LPN), le registre dématérialisé qui liste toutes les transactions d'armes du professionnel et qui est directement interconnecté avec le SIA.

Les identifiants de l'armurier auraient pu être récupérés via du phishing, un logiciel espion ou même le vol d'un ordinateur... bref, les classiques, et cerise sur le gâteau, le pirate affirme même avoir été interrompu en pleine exfiltration, ce qui veut dire qu'il aurait pu aspirer encore plus de données s'il n'avait pas été coupé dans son élan.

Le ministère se veut rassurant (lol) en précisant que "le système d'information sur les armes n'a pas été atteint" directement. Mouais... techniquement c'est vrai, c'est le compte pro de l'armurier qui a sauté et pas le SIA en lui-même. Mais en vrai le résultat est le même pour les gens dont l'adresse postale se balade maintenant sur un forum du dark web.

Côté butin, le pirate revendique pas moins d'un listing de 62 511 armes se composant de 46% de carabines, 29% de fusils de chasse, 11% de fusils à pompe et 8% d'armes de poing, le tout allant de la catégorie B (soumise à autorisation) à la catégorie C (sur déclaration).

L'Union Française des amateurs d'Armes (UFA) tempère en rappelant que la base contient plusieurs millions d'armes, et que ces chiffres "tendent à faire penser que la fuite ne concerne pas l'ensemble du système". Heureusement les gars ! Après 41 000 détenteurs avec leurs adresses et le numéro de série de leurs joujoux dans la nature, c'est quand même pas rien non plus.

Et surtout c'est pas la première fois. C'est même la troisième fuite liée au milieu des armes en 6 mois. En octobre 2025, la Fédération Française de Tir (FFTir) s'était déjà fait trouer, puis en janvier 2026 c'était au tour de la Fédération Nationale des Chasseurs (FNC), et maintenant le SIA. Le trio gagnant !!

Les conséquences avaient d'ailleurs été très concrètes après la fuite FFTir puisque la préfecture de police avait alerté sur des repérages et prises de renseignement suspects signalés aux forces de l'ordre, avec des cambrioleurs qui débarquaient chez des tireurs sportifs pour récupérer leurs armes.

Le ministère a déposé plainte et notifié la CNIL et recommande de changer régulièrement de mot de passe et ne jamais communiquer ses identifiants. Merciiiii on n'y avait pas pensé ! Mais le plus beau c'est la mesure d'urgence annoncée en réaction car à partir du 1er avril 2026 (oui, demain), tous les professionnels devront activer la double authentification pour accéder à leur compte SIA. Oui, y'en n'avait pas... un simple identifiant + mot de passe suffisait pour accéder à une base qui gère les données de millions de détenteurs d'armes en France. Ça laisse rêveur.

Après, si vous êtes inscrit au SIA et que vous n'avez pas reçu le courrier du ministère, ça ne veut pas forcément dire que vous n'êtes pas touché alors dans le doute, méfiez-vous de tout appel ou visite prétendument officielle vous demandant de remettre ou montrer vos armes car la police, la gendarmerie et les douanes ne viendront jamais chez vous récupérer vos armes suite à une fuite de données. Donc si quelqu'un sonne à votre porte avec ce prétexte, c'est forcément une arnaque (ou pire...) comme ça s'est passé après la fuite FFTir.

Bref, entre le pistage permanent de nos données en ligne et toutes ces bases gouvernementales qui fuient comme des passoires , j'imagine que la prochaine étape, ça sera le vol et la diffusion du fichier des codes nucléaires mis à dispo sur un forum de script kiddies...

Source