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

La bibliothèque JavaScript Axios, téléchargée plus de 100 millions de fois par semaine, a été compromise. Un attaquant a détourné le compte du mainteneur principal pour y glisser un malware multiplateforme qui vise aussi bien macOS que Windows et Linux.

Un compte piraté, deux versions vérolées

Tout est parti du compte npm de jasonsaayman, le mainteneur principal d'Axios. L'attaquant a réussi à prendre le contrôle du compte, a changé l'adresse mail vers un ProtonMail anonyme, et a publié deux versions malveillantes : axios 1.14.1 et axios 0.30.4.

Les deux ont été mises en ligne en l'espace de 39 minutes, et pas via le processus habituel. Au lieu de passer par GitHub Actions, le pipeline d'intégration continue du projet, les paquets ont été poussés directement avec la ligne de commande npm. Un détail qui aurait pu alerter plus tôt, mais qui est passé entre les mailles du filet pendant deux à trois heures avant que npm ne retire les versions concernées.

Un malware bien préparé, avec auto-destruction

Le plus vicieux dans l'affaire, c'est la méthode. Plutôt que de modifier directement le code d'Axios, l'attaquant a ajouté une dépendance fantôme appelée plain-crypto-js. Elle n'est jamais importée dans le code source, son seul rôle est d'exécuter un script d'installation qui fonctionne comme un programme d'installation de malware. 

Ce qui veut dire que dès que vous faites un npm install, le script contacte un serveur de commande en moins de deux secondes et télécharge un programme malveillant adapté à votre système : un daemon déguisé sur macOS, un script PowerShell sur Windows, une porte dérobée en Python sur Linux. Et une fois le malware déployé, le script se supprime, remplace son propre fichier de configuration par une version propre, et fait comme si de rien n'était. Même un npm list affiche alors un numéro de version différent pour brouiller les pistes.

Une attaque attribuée à la Corée du Nord

StepSecurity et Socket.dev ont été les premiers à repérer la compromission. Selon Ashish Kurmi, CTO de StepSecurity, ce n'est pas du tout une attaque opportuniste. La dépendance malveillante avait été préparée 18 heures à l'avance, trois programmes malveillants différents étaient prêts pour trois systèmes d'exploitation, et les deux branches de publication ont été touchées en moins de 40 minutes.

Elastic a de son côté relevé que le binaire macOS présente des similitudes avec WAVESHAPER, une porte dérobée en C++ déjà documentée par Mandiant et attribué à un acteur nord-coréen identifié sous le nom UNC1069. Pour les chercheurs en sécurité, le message est clair : si vous avez installé axios 1.14.1 ou axios 0.30.4, considérez votre machine comme compromise. Il faut supprimer la dépendance, faire tourner les identifiants, et dans certains cas, réinstaller la machine.

Franchement, c'est le genre d'attaque qui fait froid dans le dos. Axios, c'est une brique de base pour à peu près tous les projets JavaScript qui font des appels réseau. Et là, en deux heures, un attaquant a réussi à transformer cette brique en porte d'entrée pour un cheval de Troie, y compris sur Mac.

Le plus déroutant, c'est que le système de publication npm permet encore de pousser un paquet manuellement sans que personne ne bronche. Bon par contre, il faut reconnaître que StepSecurity et Socket.dev ont fait du bon boulot en détectant le problème aussi vite.

Sans eux, la fenêtre d'exposition aurait pu être bien plus large, c'est faramineux quand on y pense. Et quand on sait que la piste nord-coréenne revient de plus en plus souvent dans ce genre d'opérations, on se dit que la sécurité de la chaîne logicielle mérite qu'on s'y intéresse de près.

Source : The Register

Une nouvelle méthode d'attaque cible les IA de développement comme Copilot. En publiant de la documentation empoisonnée, des hackers trompent les modèles pour qu'ils recommandent des bibliothèques malveillantes. Cette menace invisible pour la sécurité est indétectable par les outils classiques.

Le concept est d'une simplicité désarmante. Plus besoin d'injecter du code malicieux dans un dépôt GitHub ou de trouver une faille zero-day complexe. Il suffit désormais de publier de la documentation technique faussée sur des forums, des wikis ou des fichiers README publics. Ces textes, une fois ingérés par les grands modèles de langage (LLM), deviennent une source de vérité pour l'IA qui assiste les développeurs au quotidien.

Le mécanisme de l'injection indirecte

Le problème est en fait dans la confiance aveugle que les modèles accordent aux données d'entraînement. En décrivant une solution technique qui utilise un paquet spécifique — mais malveillant — l'attaquant s'assure que l'IA proposera ce nom lors d'une requête de génération de code. C'est ce qu'on appelle l'injection de prompt indirecte. Le développeur, pensant gagner du temps, valide la suggestion et installe un composant compromis sans vérification préalable.

Le typosquatting passe au niveau supérieur

Cette technique facilite grandement le typosquatting. Auparavant, un attaquant devait espérer qu'un humain fasse une faute de frappe en saisissant une commande. Aujourd'hui, c'est l'IA qui commet l'erreur pour lui, influencée par des références empoisonnées trouvées sur le web. Comme l'IA présente la solution avec une assurance pédagogique, le sens critique de l'utilisateur baisse d'un cran. Le malware n'est plus dans la documentation, il arrive dans la machine au moment où le développeur exécute la suggestion générée.

Un défi pour la cybersécurité logicielle

La difficulté majeure est que cette attaque est purement textuelle. Les outils de scan de vulnérabilités cherchent du code dangereux, pas des explications trompeuses en langage naturel. Tant que les modèles d'IA ne sauront pas distinguer une documentation légitime d'une tentative de manipulation sémantique, la chaîne d'approvisionnement logicielle restera vulnérable à cette forme de gaslighting numérique. La sécurité repose désormais sur la véracité de l'information ingérée par les machines.

On atteint ici les limites de l'automatisation du développement. Faire confiance à un LLM pour choisir ses dépendances est devenu un risque de sécurité majeur. Cette faille montre que le maillon faible n'est plus seulement l'humain qui tape du code, mais l'outil qui lui souffle les réponses. On risque de voir apparaître des systèmes de vérification de réputation de documentation.

Source : The Register

SynthID, le filigrane invisible que Google injecte dans chaque image Gemini, c'était censé être incassable. Sauf qu'un dev a eu l'idée toute bête de générer des images noires et blanches avec Gemini, puis de regarder ce qui restait dans le domaine fréquentiel. Et là, surprise... le watermark est apparu en clair avec toutes ses fréquences porteuses !

Le projet reverse-SynthID documente le truc de A à Z où on comprend en gros, que le marquage IA de Google fonctionne en injectant de l'énergie à des fréquences bien précises dans le spectre de l'image via une transformation de Fourier . Le chercheur a identifié 6 fréquences porteuses principales, toutes avec une cohérence de phase supérieure à 99,9% et la blague, c'est que ce pattern est fixe. Donc pas de message unique par image, pas de clé qui change... c'est juste la même empreinte spectrale sur toutes les images sorties du modèle Gemini.

Spectre FFT du watermark SynthID - les pics lumineux correspondent aux fréquences porteuses identifiées

Du coup, une fois que vous avez profilé cette empreinte avec une cinquantaine d'images PNG de référence (25 noires, 25 blanches, générées via l'API Gemini), vous pouvez faire deux trucs. D'abord, détecter le filigrane avec 90% de précision, sans avoir le moindre accès au code source de Google. Et ensuite le retirer en soustrayant les composantes spectrales identifiées, fréquence par fréquence, tout en préservant la qualité de l'image à plus de 40 dB PSNR. Visuellement identique à l'original !

Et c'est là que la différence avec UnMarker (dont je vous avais parlé) saute aux yeux car ce dernier "secoue" l'image en aveugle pour casser le watermark. Alors que Reverse-SynthID, c'est plutôt scruté à la loupe et hyper ciblé. Résultat, y'a clairement moins de dégradation et un drop de confiance du détecteur.

Les fréquences porteuses reconstruites - la structure diagonale du watermark SynthID

Par contre, je l'ai implémenté en Rust et j'ai essayé de voir si ça marchait vraiment sur mes propres images générée avec Gemini. Hé bien non, car le bypass ne fait PAS chuter la confiance du détecteur de 100 à 0, mais juste de quelques pourcents.

Le watermark est atténué, mais pas effacé. Ce n'est donc pas un outil clé en main pour faire disparaître tous les filigranes SynthID en un clic. Mais le fait qu'une seule personne, avec du Python et du traitement de signal classique (FFT, filtres notch, soustraction spectrale), ait pu reverse-engineerer un système que Google présente comme LA solution anti-deepfakes...

Ça confirme ce que les chercheurs de l'Université de Waterloo avaient déjà démontré : le watermarking d'images IA, c'est pété by design.

D'ailleurs, Google le sait très bien et ils pourraient changer le pattern demain et tout serait à refaire, mais ça confirme surtout que le principe même du watermarking spectral a une date de péremption. Après, ça arrange tout le monde d'avoir un truc à montrer quand les gouvernements demandent "et contre les deepfakes, vous faites quoi ?"

Et si c'est la petite étoile visible en bas à droite des images Gemini qui vous gêne (pas le watermark spectral invisible, juste le marqueur visuel), j'ai développé un outil pour mes Patreons qui s'en occupe.

Bref, tout est sur le repo si le reverse-engineering de watermarks IA, ça vous branche !

Un groupe de pirates a compromis Trivy, un scanner de vulnérabilités open source très utilisé dans les pipelines de développement. Résultat : plus de 1 000 environnements SaaS infectés par un malware qui vole des clés API, des identifiants cloud et des tokens GitHub.

Un scanner de sécurité devenu vecteur d'attaque

Trivy est un outil open source maintenu par Aqua Security. Il sert à détecter des failles, des mauvaises configurations et des secrets exposés dans du code, et il est intégré dans les chaînes de déploiement continu (CI/CD) d'un très grand nombre d'entreprises. Le groupe TeamPCP a réussi à compromettre la version 0.69.4 de Trivy en exploitant une mauvaise configuration dans le composant GitHub Action du projet.

En février, ils ont volé un token d'accès privilégié, et ce token n'a jamais été correctement révoqué. En mars, les attaquants l'ont utilisé pour injecter du code malveillant directement dans le projet, en poussant des images Docker et des versions GitHub vérolées vers les utilisateurs.

Le résultat : 75 des 76 tags de trivy-action ont été remplacés par des versions malveillantes.

La contamination s'étend

L'attaque ne s'est pas arrêtée à Trivy. Le même groupe a aussi compromis liteLLM, une bibliothèque Python qui sert d'interface pour les modèles de langage et qui est présente dans 36 % des environnements cloud.

Ils ont aussi touché KICK (un outil d'analyse statique de Checkmarx) et déployé CanisterWorm, un ver qui se propage via des paquets npm vérolés. Le malware installé est un infostealer qui extrait les clés API, les identifiants de bases de données, les tokens GitHub et toute information sensible accessible dans l'environnement de build.

Mandiant, la branche cybersécurité de Google, estime que plus de 1 000 environnements SaaS sont actuellement compromis, et que ce chiffre pourrait grimper à 10 000. TeamPCP travaillerait avec le groupe Lapsus$, connu pour ses attaques contre Microsoft, Nvidia et Uber.

Des révélations à la conférence RSA

Les détails de l'attaque ont été rendus publics lors de la conférence RSA. Le chercheur en sécurité Paul McCarty a été le premier à tirer la sonnette d'alarme, suivi par les équipes de Socket, Wiz et Aikido.dev. Aqua Security a vu ses 44 dépôts GitHub internes défacés, avec une exposition du code source et des configurations CI/CD.

L'affaire montre à quel point les outils de sécurité open source, quand ils sont mal protégés, peuvent devenir le point d'entrée idéal pour une attaque à grande échelle.

C'est quand même un comble : un scanner de vulnérabilités qui devient lui-même le vecteur d'une attaque. Le fait qu'un simple token non révoqué ait suffi pour compromettre toute la chaîne montre que la sécurité des projets open source reste un vrai sujet. Et quand on sait que liteLLM est présent dans plus d'un tiers des environnements cloud, on mesure l'ampleur du problème...

Source : The Register

2 chercheurs en sécurité, Yaron Dinkin et Eyal Kraft, viennent de publier les résultats d'une expérience qui devrait donner des sueurs froides à pas mal de monde... Ils ont découvert 521 vulnérabilités dans les pilotes du noyau Windows, dont une bonne centaine exploitables pour de l'escalade de privilèges. Et tout ça ne leur a coûté que 600 dollars !

Mais comment ont-ils fait ? Eh bien ils se sont construit un pipeline en 5 étapes. D'abord, il a fallu récupérer 1654 pilotes uniques depuis le catalogue Microsoft Update ainsi que depuis les sites des constructeurs.

Ensuite, ils ont lancé un prétraitement automatique pour classer les cibles par surface d'attaque. Pour faire simple, dans Windows, quand un logiciel veut causer à un pilote du noyau, il lui envoie des commandes appelées IOCTL (Input/Output Control)... c'est un peu la sonnette d'entrée entre le monde utilisateur et le monde noyau. Leur pipeline analysait donc la complexité des fonctions qui répondent à ces commandes (les "handlers IOCTL"). Plus un handler est complexe, plus il y a de chances qu'une erreur s'y planque.

Et ils cherchaient en priorité les pilotes qui utilisent un mode de transfert de données appelé METHOD_NEITHER, c'est-à-dire le mode "démerde-toi". Car contrairement aux autres modes où Windows joue les intermédiaires et vérifie un minimum ce qui transite, ici le pilote reçoit directement les pointeurs bruts depuis l'espace utilisateur, sans aucun filet de sécurité du noyau. C'est ensuite au développeur du pilote de tout vérifier lui-même… et spoiler : beaucoup ne le font pas correctement ! Bref, c'est le genre de truc qui sent la vuln à plein nez.

Ensuite pour la recherche de vulnérabilité, c'est-à-dire vraiment le cœur de leur système, ils ont mis en place un conseil de 3 agents LLM avec chacun un rôle bien défini. Un agent décompile d'abord le binaire et renomme les fonctions, ensuite un autre identifie la surface d'attaque, et enfin le troisième audite chaque fonction pour trouver des corruptions mémoire. Le tout via OpenRouter , en mixant les modèles pour optimiser le ratio vulnérabilités par token. Coût moyen par cible : 3 dollars.

Et les résultats obtenus sont assez crazy loco car sur 202 binaires analysés, ils ont trouvé 521 vulns au total dont 45% de bugs de lecture/écriture mémoire arbitraire. Et 70% de ces vulnérabilités sont classées High ou Critical.

Mais évidemment y'a du faux positif (environ 60%), donc ils ont dû faire une review manuelle de chacun de ces bugs. Mais même après le tri ça laisse plus de 100 bugs réellement exploitables pour de l'escalade de privilèges sur Windows 11 ! Et les vendeurs concernés, c'est pas des petits joueurs : AMD, Intel, NVIDIA, Dell, Lenovo, IBM, Fujitsu...

D'ailleurs, le cas du driver AMD Crash Defender (amdfendr.sys) est parlant. Le device est accessible en écriture par n'importe quel utilisateur, expose des IOCTLs sans validation de taille correcte et permet de la corruption heap. Avec un peu de pool grooming, on arrive donc à de l'exécution de code kernel. Et quand on sait que ce driver tourne sur les instances AWS EC2 Windows avec processeurs AMD, on comprend vite que la surface d'attaque s'étend largement jusqu'au cloud.

(En parlant de reverse engineering assisté par IA, perso en ce moment, je suis en train de faire joujou avec Claude Code et Ghidra pour un projet dont je vous parlerai peut-être plus tard si j'y arrive, et franchement ça marche troooop bien c'est fou ! Les chercheurs de l'étude notent d'ailleurs qu'aujourd'hui, ils utiliseraient probablement "juste Claude Code avec des skills custom" plutôt que leur pipeline maison. C'est dire si l'outil d'Anthropic est fou !

Après le plus flippant dans cette histoire, comme d'habitude c'est pas les bugs. Non, ce sont les réactions des constructeurs car sur 15 vulnérabilités confirmées et rapportées à 8 vendeurs, toutes avec un score CVSS (gravité de la faille, sur 10) supérieur à 7, un seul a patché ! Il s'agit de Fujitsu, avec la CVE-2025-65001 . Les autres ont rejeté les rapports ou baissé les priorités malgré des vidéos de proof-of-concept montrant par exemple un BSOD depuis un compte utilisateur standard !

Le problème c'est que certains de ces produits hardware sont en fin de vie. Donc y'a plus de support. Mais ils ne révoquent pas les certificats de signature du driver. Du coup, ces pilotes restent utilisables pour des attaques BYOVD (Bring Your Own Vulnerable Driver), où un attaquant chargerait volontairement un driver signé mais vérolé pour compromettre le noyau.

Si vous bossez en sécurité, les chercheurs ont publié une liste de 234 hashes en double-SHA256 pour vérifier si vos machines contiennent des drivers affectés. Pour checker vos drivers, c'est simple :

sha256sum driver.sys | awk '{print $1}' | tr -d '\n' | sha256sum

Google, iVerify et Lookout viennent de mettre au jour un kit d'exploitation baptisé DarkSword, capable de prendre le contrôle total d'un iPhone en enchaînant six failles iOS dont trois zero-day. Espions russes, vendeurs de surveillance turcs et hackers saoudiens s'en sont servis. Apple a corrigé le tir avec iOS 26.3, mais jusqu'à 270 millions d'appareils restent exposés.

Six failles, trois zero-day et un iPhone grand ouvert

Pour tout vous dire, DarkSword, avec son nom qui fait peur, n'est pas un petit malware de plus qui pointe le bout de son nez. C'est une chaîne d'exploitation complète écrite en JS, qui cible tous les iPhone qui tournent sous iOS, de la version 18.4 à la 18.7.

Le principe : vous tombez sur une page web piégée dans Safari, une iFrame charge du code malveillant, et c'est parti.

Ensuite, il contourne les protections du bac à sable via le processus GPU, escalade les privilèges jusqu'au noyau, et finit par injecter un module dans le daemon mediaplaybackd. Six vulnérabilités au total, dont trois étaient des failles zero-day au moment de leur exploitation : CVE-2026-20700, CVE-2025-43529 et CVE-2025-14174.

Et les données aspirées ne sont pas anecdotiques : e-mails, fichiers iCloud, contacts, SMS, historique Safari, mots de passe, photos, données de localisation, et même les messages Telegram et WhatsApp.

Les portefeuilles crypto aussi sont visés. Le tout en quelques secondes à peine, avec nettoyage des traces après exfiltration. Du travail soigné, d'après les chercheurs, même si le code n'est curieusement pas du tout obfusqué.

Espions russes, vendeurs de surveillance et sites ukrainiens piégés

Trois groupes distincts ont utilisé DarkSword depuis novembre 2025. Le premier, UNC6353, est un groupe d'espionnage présumé russe qui a ciblé des utilisateurs ukrainiens via des sites web compromis. Le deuxième, UNC6748, a utilisé un faux domaine Snapchat pour piéger des cibles en Arabie saoudite.

Et le troisième n'est autre que PARS Defense, un vendeur turc de solutions de surveillance commerciale. Chacun déploie sa propre variante de malware : GHOSTBLADE, GHOSTKNIFE ou GHOSTSABER selon le cas.

DarkSword est d'ailleurs le deuxième kit d'exploit iOS découvert en un mois, après Coruna. Les deux partagent une partie de leur infrastructure, mais sont développés par des équipes différentes.

Selon iVerify, jusqu'à 270 millions d'iPhone seraient potentiellement vulnérables, et Lookout estime que 15 % des appareils iOS en circulation tournent encore sur des versions antérieures à iOS 26.

Mettez à jour, et vite

Apple a corrigé l'ensemble des failles avec iOS 26.3, sorti plus tôt ce mois-ci. La version la plus récente est iOS 26.3.1. Si vous n'avez pas encore fait la mise à jour, c'est le moment.

Pour les profils les plus exposés — journalistes, militants, chercheurs en sécurité — Apple recommande aussi d'activer le mode Isolement, qui limite les surfaces d'attaque en désactivant certaines fonctionnalités de Safari et des services de messagerie.

Deux kits d'exploit iOS découvert en l'espace d'un mois, avec des acteurs aussi variés que des espions russes et des boîtes de surveillance turques, ça fait quand même beaucoup. On savait que l'iPhone n'était pas invulnérable, mais là on parle de chaînes complètes qui fonctionnent sur des versions récentes d'iOS, pas sur de vieux iPhone 6 oubliés dans un tiroir.

Bon, au moins, Apple a réagi et les correctifs sont là. Mais entre le moment où ces failles ont été exploitées, fin 2025, et leur correction complète, il s'est passé plusieurs mois. Franchement, si vous repoussez les mises à jour iOS depuis des semaines, c'est peut-être le bon moment d'appuyer sur le bouton.

La société Aikido Security a découvert une campagne de malware baptisée Glassworm qui utilise des caractères Unicode invisibles pour dissimuler du code malveillant.

Plus de 150 dépôts GitHub, des paquets npm et des extensions VS Code sont touchés, et le malware utilise la blockchain Solana comme serveur de commande. L'objectif : voler les identifiants de portefeuilles crypto.

Des caractères invisibles qui cachent du code

Le principe est assez fourbe. Les attaquants utilisent des caractères Unicode dits PUA (Private Use Area), qui ne s'affichent pas du tout à l'écran, mais qui contiennent quand même des valeurs exploitables.

Dit plus simplement, chaque caractère invisible correspond à un point de code que le décodeur extrait, reconstruit en payload, puis exécute via eval(). Le code malveillant est là, sous vos yeux, mais vous ne le voyez pas.

Aikido Security a découvert que cette campagne avait eu lieu entre le 3 et le 9 mars derniers. Plus de 150 dépôts GitHub ont été compromis, mais aussi des paquets npm comme @aifabrix/miso-client et @iflow-mcp/watercrawl-watercrawl-mcp.

Si on regarde du côté de VS Code, l'extension quartz-markdown-editor et 72 extensions sur Open VSX ont été touchées. Les attaquants ont aussi utilisé des LLM pour générer des commits de couverture parfaitement crédibles, et passer ainsi sous les radars des reviewers.

La blockchain Solana impliquée

Ce qui rend Glassworm encore plus fourbe, c'est son infrastructure. Au lieu d'utiliser un serveur classique facile à bloquer, le malware récupère ses instructions de commande sur la blockchain Solana. Ce qui veut dire qu'il n'y a pas de serveur central à couper : les instructions sont inscrites dans la blockchain, accessibles à tous et quasi impossibles à supprimer.

L'objectif final est le vol de données liées aux portefeuilles crypto. Le malware cible 49 extensions de navigateur, dont MetaMask, Coinbase Wallet et Phantom. Il récupère les identifiants stockés localement et les exfiltre vers les serveurs des attaquants.

Côté attaquants, c'est du beau travail. Cacher du code dans des caractères que personne ne voit, utiliser une blockchain comme canal de commande et se servir d'IA pour maquiller les commits, c'est bien ficelé.

Le problème, c'est que ça expose un angle mort assez gênant dans la confiance qu'on accorde à l'open source : on installe des paquets et des extensions sans forcément lire chaque ligne de code, et quand le code malveillant est carrément invisible, ça devient compliqué à détecter.

Sources : Aikido.dev , Socket.dev

Apple vient de publier iOS 16.7.15 et iOS 15.8.7 pour les anciens iPhone et iPad. Ces mises à jour corrigent des failles activement exploitées par Coruna, un kit d'espionnage qui combine 23 vulnérabilités pour compromettre un appareil simplement en chargeant une page web, je vous en parlais ici. Si vous avez encore un iPhone 6s, 7, 8 ou X, la mise à jour est urgente.

D'où vient Coruna ?

Google et iVerify ont rendu public le kit Coruna le 3 mars. Il regroupe 23 failles en cinq chaînes d'exploitation et cible les iPhone sous iOS 13 à iOS 17.2.1. L'outil aurait été conçu par une filiale de L3Harris Technologies, un sous-traitant de défense américain, et vendu à des agences gouvernementales alliées des États-Unis.

Sauf que voilà, le kit a fini par circuler bien au-delà de ce cercle. Un groupe d'espionnage russe l'a utilisé en juillet 2025 contre des cibles ukrainiennes, et un acteur chinois s'en est servi fin 2025 via de faux sites de cryptomonnaies et de paris en ligne. Plus de 50 domaines de distribution ont été identifiés.

Quels sont les appareils concernés ?

Les mises à jour publiées par Apple couvrent deux générations d'anciens appareils. iOS 15.8.7 concerne les iPhone 6s, iPhone 7, iPhone SE première génération, l'iPad Air 2, l'iPad mini 4 et l'iPod touch septième génération. iOS 16.7.15 vise les iPhone 8, 8 Plus et iPhone X, ainsi que l'iPad cinquième génération et les premiers iPad Pro.

Les quatre CVE corrigées touchent le noyau et le moteur WebKit. Le kit exploite ces failles sans aucune interaction de l'utilisateur : il suffit de charger une page web piégée pour que l'appareil soit compromis.

Des portefeuilles crypto ciblés

Une fois l'appareil compromis, le malware PlasmaLoader s'attaque aux portefeuilles de cryptomonnaies comme MetaMask, Exodus ou Bitget Wallet. Google a qualifié Coruna de première exploitation de masse connue contre iOS.

Le kit détecte le modèle d'iPhone et la version d'iOS avant de choisir la bonne chaîne d'exploitation. Il évite aussi de s'exécuter si le mode Isolement est activé ou si la navigation est en mode privé.

Apple fait quand même bien le job en patchant des appareils qui ont jusqu'à dix ans, et c'est plutôt rassurant !

Source : The Hacker News

Un agent IA autonome a percé les défenses de Lilli, la plateforme d'intelligence artificielle interne de McKinsey, c'est arrivé en à peine deux heures. Au programme : 46,5 millions de messages en clair, 728 000 fichiers clients et un accès en écriture à l'ensemble de la base de données. Le tout sans aucun identifiant.

Une injection SQL en 2026

C'est la startup de sécurité CodeWall qui a mené l'attaque, dans le cadre d'un test de pénétration. Son agent IA a commencé par scanner la documentation API de Lilli, qui était exposée publiquement. Sur les 200 points d'accès répertoriés, 22 ne demandaient aucune authentification.

L'un d'eux, qui servait à enregistrer les requêtes de recherche des utilisateurs, concaténait les noms de champs JSON directement dans les requêtes SQL sans aucun filtrage. Une injection SQL classique, la faille la plus documentée du web depuis vingt ans.

Les scanners de sécurité classiques comme OWASP ZAP étaient passés à côté, parce que les valeurs des paramètres, elles, étaient bien protégées. Mais pas les noms de champs.

46,5 millions de messages et des prompts modifiables

Il a fallu seulement une quinzaine d'itérations à l'aveugle sur les messages d'erreur de la base, pour cartographier toute sa structure interne. Résultat : 46,5 millions de conversations en clair couvrant la stratégie, les fusions-acquisitions et les engagements clients de McKinsey, mais aussi 728 000 fichiers (192 000 PDF, 93 000 tableurs, 93 000 présentations), 57 000 comptes utilisateurs, 384 000 assistants IA et 3,68 millions de fragments de documents RAG avec les chemins de stockage S3.

Le pire, c'est que les 95 prompts système qui contrôlent le comportement de Lilli étaient accessibles en écriture. Une simple requête SQL UPDATE suffisait pour empoisonner les réponses du chatbot à l'ensemble des 40 000 consultants qui l'utilisent, sans laisser de trace.

McKinsey a corrigé en un jour

CodeWall a divulgué la faille le 1er mars, et McKinsey a réagi vite : tous les points d'accès non authentifiés ont été fermés, l'environnement de développement mis hors ligne et la documentation API retirée, le tout en une journée.

Histoire de rassurer tout le monde, le célèbre cabinet de conseil promet qu'aucune donnée client n'a été consultée par des personnes non autorisées. Sauf que l'adoption de Lilli dans l'entreprise est massive, puisque plus de 70% des employés de McKinsey l'utilisent au quotidien, avec quand même plus de 500 000 requêtes par mois, et une faille en place depuis... 2023 !

Quoi qu'il en soit, une injection SQL sur une plateforme qui tourne depuis deux ans et demi chez un cabinet qui vend du conseil en transformation numérique à, à peu près, la Terre entière, c'est quand même plus que cocasse.

Source : The Register

Mark Russinovich, CTO de Microsoft Azure, a donné à Claude Opus 4.6 un programme qu'il avait écrit en assembleur 6502 pour Apple II en mai 1986. L'IA d'Anthropic y a trouvé des vulnérabilités. Une découverte possible grâce à Claude Code Security, un outil qui a déjà débusqué plus de 500 failles dans des projets open source.

Du code Apple II passé au crible

Le programme en question s'appelle Enhancer. C'est un utilitaire écrit en langage machine 6502 qui ajoutait à l'Applesoft BASIC la possibilité d'utiliser des variables ou des expressions comme destination pour les commandes GOTO, GOSUB et RESTORE.

Claude Opus 4.6 a identifié un comportement silencieux incorrect : quand une ligne de destination n'était pas trouvée, le programme plaçait le pointeur sur la ligne suivante ou au-delà de la fin du programme, au lieu de signaler une erreur. L'IA a même suggéré le correctif : vérifier le carry flag (positionné quand une ligne n'est pas trouvée) et rediriger vers un gestionnaire d'erreurs.

L'anecdote a surtout valeur de démonstration. Russinovich l'a partagée pour montrer que les modèles d'IA sont désormais capables de décompiler du code embarqué d’un autre âge et d'y repérer des failles, ce qui pose un problème quand on sait que des milliards de microcontrôleurs tournent dans le monde avec du code qui n'a jamais été audité.

Plus de 500 failles dans des projets open source

Cette histoire autour de l'Apple II est amusante, mais le vrai sujet est ailleurs. Anthropic a utilisé Claude Opus 4.6 pour scanner des bases de code open source en production et a trouvé plus de 500 vulnérabilités qui avaient échappé à des années de revue par des experts humains.

Parmi les projets touchés : GhostScript (traitement PostScript et PDF), OpenSC (utilitaires pour cartes à puce), CGIF (traitement d'images GIF) et le noyau Linux. Certaines de ces failles étaient là depuis des décennies, malgré des millions d'heures de fuzzing accumulées sur ces projets.

Côté Firefox, on vous en a parlé : 22 CVE dont 14 haute gravité, trouvées en deux semaines seulement.

On vous en a déjà parlé, Anthropic a lancé le 20 février Claude Code Security, un outil intégré à Claude Code sur le web, pour l'instant en accès limité. Le principe : l'IA scanne un dépôt de code, identifie les vulnérabilités, et propose des correctifs ciblés pour validation humaine.

Contrairement aux outils d'analyse statique classiques qui fonctionnent par pattern matching, Claude lit et raisonne sur le code comme le ferait un chercheur en sécurité, en traçant les flux de données et en comprenant comment les composants interagissent. Rien n'est appliqué sans validation humaine. L'outil est accessible aux clients Enterprise et Team, et les mainteneurs de projets open source peuvent demander un accès gratuit.

Tout ça pour dire que l'image du CTO d'Azure qui ressort son vieux code Apple II et se retrouve avec un rapport de failles, c'est quand même franchement rigolo, mais aussi intéressant. Mais le fond du sujet est plus sérieux : des milliards d'appareils embarqués tournent avec du code ancien que personne n'a jamais audité, et l'IA est désormais capable de les passer au peigne fin. Anthropic a quand même prévenu que cet écart entre la capacité à trouver les failles et celle de les exploiter ne durera probablement pas éternellement. On l’espère.

Source : The Register

Gaël Musquet, mon copain hacker, me parlait déjà de tracking TPMS en 2020. Du coup, quand je vois des chercheurs publier un document de recherche en 2026 pour "découvrir" qu'on peut pister une voiture via ses capteurs de pneus, bon, comment dire... je suis pas tombé de ma chaise.

Mais faut reconnaître que l'étude en question va quand même plus loin qu'une discussion entre 2 stands au FIC. En effet, une équipe d'IMDEA Networks et d'armasuisse (le labo de défense suisse, rien que ça) a posé 5 récepteurs SDR dans une ville pendant 10 semaines. Coût du matos, environ 100 dollars par capteur, qui est en gros un Raspberry Pi 4 avec un dongle RTL-SDR à 25 balles. Et grâce à cela, ils ont capté plus de 6 MILLIONS de messages, provenant de plus de 20 000 véhicules !

un Raspberry Pi 4 avec un dongle RTL-SDR - Source

Car oui, vous ne le savez peut-être pas, mais les capteurs de pression des pneus (TPMS pour les intimes) émettent régulièrement dès que le véhicule roule, sur 433 MHz en Europe. Et ces signaux contiennent un identifiant unique... qui bien sûr est en clair ^^. Pas de chiffrement, pas d'authentification, QUE DALLE. Donc avec un logiciel open source comme rtl_433 , ça devient vite facile de capter tout ça à plusieurs dizaines de mètres à la ronde.

En croisant les identifiants captés par plusieurs récepteurs, les chercheurs ont pu reconstituer les trajets des véhicules, identifier leurs horaires de travail, détecter les jours de télétravail et même estimer les variations de charge du véhicule (et potentiellement déduire la présence de passagers, même si c'est encore approximatif). Le tout sans caméra, sans GPS, et sans accès au réseau du véhicule !

Il suffirait de trouver l'identifiant d'une voiture précise pour déclencher par exemple automatiquement un lâcher de confettis en papier parfaitement inoffensifs à son passage, si vous voyez ce que je veux dire.

Alors attention, tous les véhicules ne sont pas logés à la même enseigne. Les TPMS dits "directs" (dTPMS), qu'on trouve souvent chez Toyota, Peugeot, Citroën, Hyundai ou Mercedes, émettent ces fameux signaux radio captables. Alors que les systèmes "indirects" (iTPMS), utilisés par la plupart des modèles Volkswagen, Audi ou Skoda, se basent sur les capteurs ABS et n'émettent rien par radio. Bref, si vous roulez en Golf de base, y'a de bonnes chances que vous soyez tranquilles sur ce coup-là même si certaines versions sportives ou haut de gamme (Golf R, GTI selon les marchés) peuvent embarquer du dTPMS.

Et le pire dans tout ça c'est que la réglementation UN R155 sur la cybersécurité automobile n'impose pas explicitement le chiffrement des TPMS. En gros, les constructeurs ne sont pas forcés de sécuriser ces transmissions. Pirelli et Bosch bossent bien sur un "Cyber Tyre" en Bluetooth Low Energy, mais c'est réservé au haut de gamme et c'est pas demain que ça arrivera sur votre Clio.

Donc côté protection, soyons honnêtes, y'a pas grand-chose à faire côté utilisateur. Vous ne pouvez pas désactiver vos TPMS (c'est obligatoire depuis 2014 pour les voitures neuves en Europe), et les capteurs ne proposent aucune option de chiffrement. Sauf si vous roulez en véhicule vintage d'avant 2014, c'est open bar. Une des parades serait que les constructeurs implémentent un système de rotation d'identifiants, un peu comme le fait déjà le Bluetooth avec les adresses MAC aléatoires, mais pour l'instant on en est loin.

Pour ceux qui veulent creuser le sujet, j'avais fait une rencontre avec Gaël Musquet il y a quelques années, où il expliquait déjà comment reprendre le contrôle de nos véhicules connectés. Et si vous voulez comprendre comment on hacke une voiture de manière plus générale, c'est un rabbit hole sans fond !

Bref, la prochaine fois que vous gonflez vos pneus... dites-leur bonjour de ma part.

Source

Bon, vous connaissez la théorie du travailleur nomade... vous vous posez dans un café avec votre laptop, vous chopez du WiFi gratuit, et vous vous dites que l'isolation client du routeur vous protègera des autres branquignols connectés au même réseau.

Hé ben non ! Car des chercheurs viennent de démontrer que cette protection, c'était du vent... Oui oui, tous les routeurs qu'ils ont testés se sont fait contourner en 2 secondes.

Mais avant, pour ceux qui se demandent ce que c'est, l'isolation client c'est une option que les admins réseau activent sur les bornes WiFi pour empêcher les appareils connectés de communiquer entre eux. En gros, votre laptop ne peut pas voir celui du voisin. Enfin... ça c'est en théorie.

Parce qu'en fait, le truc c'est que cette fonctionnalité n'est même pas définie dans le standard WiFi (IEEE 802.11) ce qui oblige chaque fabricant à faire sa propre tambouille dans son coin, et du coup ça fuit de partout.

L'équipe derrière cette trouvaille, c'est des chercheurs de l'UC Riverside et de KU Leuven, dont Mathy Vanhoef, le même gars qui avait déjà mis le WPA2 à genoux avec KRACK en 2017. Pas un amateur, quoi. Et leur outil, baptisé AirSnitch, vient d'être présenté à la conférence NDSS 2026 .

Ils ont ainsi trouvé 3 méthodes différentes pour contourner la protection d'isolation. La première abuse de la clé de groupe (GTK), normalement réservée au broadcast, pour envoyer du trafic directement à un appareil ciblé. Le pire, c'est que macOS, iOS et Android acceptent ce trafic sans broncher (merci les gars !).

La seconde fait rebondir les paquets via la passerelle, et la troisième vole carrément l'adresse MAC de la victime sur un autre point d'accès pour intercepter son trafic.

Brrrrrr.... 11 routeurs testés, du Netgear R8000 au Cisco Catalyst 9130 en passant par TP-Link, ASUS, Ubiquiti et même OpenWrt 24.10. Et ils sont TOUS vulnérables, sans exception ! Et que vous soyez en WPA2 ou en WPA3, réseau perso ou entreprise, c'est pareil. Donc autant vous dire que ça pue !

Ils ont même réussi à effectuer un Man-in-the-Middle complet (interception de tout le trafic entre vous et Internet) en 2 secondes chrono. La "victime" qui regardait YouTube n'a même pas remarqué de lag et c'est comme ça qu'ils ont pu intercepter tout son trafic, ni vu ni connu.

Alors du coup, on fait quoi ? Hé bien si vous gérez un réseau, oubliez l'isolation client toute seule et passez aux VLANs avec un VLAN par client. Oui c'est lourdingue à mettre en place, mais c'est le prix à payer pour avoir une sécurité solide. Certains constructeurs bossent aussi sur des clés de groupe individuelles par client, ce qui règlerait le problème à la source.

Côté utilisateur, la solution est plus simple... VPN !! Attention, ça ne marche que si le VPN est activé AVANT de vous connecter au réseau, pas après. HTTPS vous protège déjà pour le contenu des sites, mais selon Google, 6 à 20% des pages ne sont toujours pas en HTTPS... et même quand elles le sont, l'attaquant voit quand même où vous surfez et peut tenter du DNS spoofing. Donc sur n'importe quel réseau WiFi public , partez du principe que quelqu'un peut voir votre trafic, parce que visiblement c'est le cas.

Le code source d' AirSnitch est dispo sur GitHub si vous voulez tester votre propre config mais notez que ça nécessitera une carte WiFi compatible avec le mode monitor comme les Alfa (lien affilié), donc pas celle de votre laptop de base.

Bref, la prochaine fois que le WiFi de l'hôtel vous demande d'accepter les CGU en échange d'un accès "sécurisé"... ben gardez votre VPN allumé, hein.

Source

Les clés API Google que vous collez dans votre JavaScript pour afficher une carte Maps... hé bien elles ne sont plus si inoffensives. Car depuis que Gemini est entré dans la danse, ces mêmes clés donnent maintenant accès à vos fichiers privés et surtout à votre facture IA.

Et personne ne nous a prévenu...

En gros, Google utilise un format de clé unique, les fameuses AIza..., aussi bien pour Maps et Firebase (public, collé dans le HTML, tout le monde s'en fout) que pour Gemini (privé, accès aux fichiers, facturation). Le problème c'est que quand vous activez l'API Gemini sur un projet Google Cloud, TOUTES les clés existantes de ce projet héritent automatiquement de l'accès Gemini. Sans warning, sans notification, sans rien... Ouin !

Les chercheurs de TruffleSecurity ont ainsi trouvé presque 3000 clés API Google valides dans le dataset Common Crawl de novembre 2025. Des clés qui trainent dans du code JavaScript, des pages HTML, des repos GitHub publics... et qui fonctionnent sur l'endpoint Gemini. Il suffit d'un simple curl avec une clé Maps récupérée sur un site web, et hop, vous accédez à l'API Gemini du propriétaire. Fichiers privés, contenu en cache, facturation sur son compte.

Et parmi les victimes, on trouve des institutions financières, des boîtes de cybersécurité, et... Google eux-mêmes (oui oui, vraiment).

Le 21 novembre 2025, TruffleSecurity signale donc le problème et la réponse de Google le 25 novembre c'est : "intended behavior" (comportement normal)... Sauf que le 2 décembre, Google a reclassifié ça en bug, puis le 13 janvier 2026, ça passe finalement en Tier 1. On est donc passé du "c'est normal les frérots" à "ah oui quand même, oupsi oups", en 7 semaines.

Maintenant, pour ceux qui se demandent si leurs clés API Google sont concernées, direction console.cloud.google.com , section "APIs & Services" puis "Identifiants".

Si vous voyez l'API " Generative Language " de Gemini API activée sur un projet avec des clés non restreintes... attention, c'est le moment de faire le ménage. Ajoutez des restrictions IP ou HTTP referrer, et surtout, utilisez des comptes de service plutôt que des clés API pour tout ce qui touche à Gemini (sauf si vous aimez les surprises sur votre facture ^^).

Le truc tordu, c'est que la doc Firebase dit noir sur blanc que les clés API ne sont pas des secrets. Google Maps vous dit carrément de les coller dans votre HTML. Et maintenant, ces mêmes clés donnent accès à une IA qui peut lire vos fichiers. Du CWE-1188 pur et dur ! Et c'est pas la première fois que Google se fait taper sur les doigts pour ce genre de souci avec Gemini .

Du coup, Google a annoncé des nouvelles mesures, du scoped defaults, du blocage de clés fuités, des notifications proactives...etc. Reste donc à voir si ça arrivera avant que les presque 3000 clés exposées soient exploitées par des gens moins bien intentionnés.

Bref, dix ans à dire que c'est public, et hop, aujourd'hui c'est devenu top secret. Bien joué Google !!

Source

Vous avez un serveur, un NAS, quelques services qui tournent chez vous ou au boulot, et vous vous demandez si tout ça est bien sécurisé ? Alors plutôt que d'attendre qu'un petit malin vous le fasse savoir de manière désagréable, autant prendre les devants avec un scanner de vulnérabilités.

Attention : si vous scannez le réseau de votre boulot, demandez toujours une autorisation écrite avant car scanner sans permission, c'est illégal et ça peut vous coûter cher. Et ne comptez pas sur moi pour vous apporter des oranges en prison.

OpenVAS (Open Vulnerability Assessment Scanner), c'est l'un des scanners open source les plus connus, maintenu par Greenbone. Une fois en place sur votre réseau, il scanne vos services exposés et vous balance un rapport avec ce qui craint : Ports ouverts, services mal configurés, failles connues, certificats expirés... De quoi repérer une bonne partie de ce qu'un attaquant pourrait exploiter.

L'interface principale d'OpenVAS

Ce qui est cool, c'est que vous restez en mode défensif. C'est pas un outil de pentest offensif ou de hacking pur et dur mais juste un audit de votre propre infra pour savoir où vous en êtes. Et ça tourne avec un feed de vulnérabilités (le Greenbone Community Feed) qui est régulièrement mis à jour, ce qui permet de détecter les failles récentes.

Pour l'installer, une des méthodes c'est de passer par Docker. Greenbone fournit une stack complète avec docker-compose. Après vous cherchez plutôt à analyser spécifiquement vos images de conteneurs, Grype pourrait aussi vous intéresser .

Pour OpenVAS, vous créez un répertoire, vous téléchargez leur fichier de config (jetez toujours un œil dedans avant de l'exécuter, c'est une bonne pratique), et hop :

mkdir -p ~/greenbone-community-container
cd ~/greenbone-community-container
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml
docker compose pull
docker compose up -d

L'assistant de configuration initiale

Après ça, vous accédez à l'interface web via http://localhost:9392.

Et pour le login, attention, car sur les versions récentes du conteneur communautaire, le mot de passe admin est généré aléatoirement au premier démarrage. Il faut donc aller voir les logs pour le récupérer (docker compose logs -f). Si ça ne marche pas, tentez le classique admin/admin, mais changez-le direct.

La première synchro des feeds peut prendre un moment, le temps que la base de vulnérabilités se télécharge. Vous avez le temps d'aller vous faire un café, c'est pas instantané.

Niveau config machine, la documentation recommande au moins 2 CPU et 4 Go de RAM pour que ça tourne, mais pour scanner un réseau un peu costaud, doublez ça (4 CPU / 8 Go) pour être à l'aise. Et une fois connecté, direction la section scans pour créer une cible avec votre IP ou plage d'adresses. Ensuite vous pouvez lancer un scan avec le profil de votre choix :

Le mode "Discovery" se contente de lister les services et ports ouverts tandis que le mode "Full and Fast" lance une batterie complète de tests de vulnérabilités. Il est conçu pour être "safe" (ne pas planter les services), mais le risque zéro n'existe pas en réseau donc évitez de scanner votre prod en pleine journée sans prévenir.

Les résultats arrivent sous forme de rapport avec un score de criticité comme ça vous avez le détail de ce qui pose problème et souvent des pistes pour corriger. Genre si vous avez un service SSH avec une config un peu lâche ou un serveur web trop bavard, le rapport vous le dira.

Par contre, c'est vrai que l'interface est assez austère comparée à des solutions commerciales comme Nessus mais c'est gratuit, c'est open source, et ça fait le taf pour un audit interne. La version Community a quand même quelques limitations (feed communautaire vs feed entreprise, support, etc.), mais pour surveiller son infra perso ou sa PME, c'est déjà très puissant.

Du coup, si vous voulez savoir ce qui traîne sur votre réseau avant que quelqu'un d'autre le découvre, OpenVAS est un excellent point de départ. Et c'est toujours mieux de découvrir ses failles soi-même que de les lire dans un mail de rançon... enfin, je pense ^^.

A découvrir ici !

Si vous utilisez Notepad++, faut que vous sachiez qu'il s'est passé un truc moche. Entre juin et décembre 2025, les serveurs de mise à jour de votre éditeur de texte préféré ont été piratés par Lotus Blossom, un groupe de hackers chinois actifs depuis 2009 et spécialisés dans l'espionnage gouvernemental. Ouin 🥲.

En gros, les attaquants ont réussi à compromettre l'infrastructure de l'ancien hébergeur du projet pour détourner le trafic de mise à jour. Certains utilisateurs se retrouvaient redirigés vers des serveurs malveillants qui leur servaient des binaires vérolés au lieu des vraies mises à jour. Et le chercheur en sécurité Kevin Beaumont confirme que trois organisations ayant des intérêts en Asie de l'Est ont subi des intrusions via cette méthode... avec des hackers qui naviguaient VRAIMENT sur les PC des victimes en temps réel.

Le pire ? Les hackers ont gardé un accès aux services internes jusqu'au 2 décembre, même après la correction de la faille initiale en septembre. Ils exploitaient une vulnérabilité dans le script getDownloadUrl.php et les faiblesses de WinGUP, l'outil de mise à jour. Les anciennes versions utilisaient même un certificat auto-signé dispo sur GitHub... autant dire que c'était open bar.

Rapid7 a publié une analyse technique du malware déployé via cette attaque. Baptisé "Chrysalis", c'est une backdoor complète avec shell interactif, exfiltration de fichiers, création de processus à distance... le package complet de l'espion. Le truc vicieux, c'est que le serveur de commande utilisait une URL qui imitait l'API de DeepSeek pour passer sous les radars.

Beaumont alerte aussi sur le fait que les moteurs de recherche sont bourrés de pubs qui poussent des versions vérolées de Notepad++. Sans compter des extensions malveillantes qui circulent. Bref, c'est la fête.

Bon, pour vous protéger, mettez à jour Notepad++ vers la version 8.9.1 minimum (et pas 8.8.9 comme annoncé initialement, ils ont renforcé les protections depuis). Si vous avez un doute, désinstallez tout et retéléchargez directement depuis notepad-plus-plus.org. Changez vos mots de passe si vous utilisiez cet outil pendant la période critique, et les admins réseau, bloquez l'accès Internet de gup.exe dans votre pare-feu. Hop, c'est réglé. Si vous cherchez des alternatives le temps que ça se tasse, y'a Notepads ou NotepadNext qui font du super boulot, et les indicateurs de compromission sont dans le rapport de Rapid7 .

Bref, restez vigilants !

Source & Source

C'est un délire ça ! Je crois que je viens de lire le truc le plus improbable de l'année. Sérieux, vous vous souvenez de Command & Conquer : Generals ? Mais siiii, ce RTS de légende sorti en 2003 bien après C&C et Red Alert !! Hé bien accrochez-vous, car même s'il est techniquement mort depuis la fermeture de GameSpy en 2014, il fait encore parler de lui.

Et pas pour de bonnes raisons. Argh !

Une équipe de chercheurs de chez Atredis Partners s'est penchée sur le code source du jeu, libéré par Electronic Arts début 2025. Au début, j'ai pensé qu'ils avaient juste trouver quelques bugs mineurs, mais en fait, ils ont découvert une série de failles de sécurité totalement dingues qui permettent à n'importe qui de prendre le contrôle de votre PC via le jeu. Carrément...

En réalité le jeu utilise une architecture P2P (peer to peer, qu'on devrait renommer pour l'occasion Pire Trop Pire ^^) qui fait que chaque joueur est connecté directement aux autres. Les chercheurs ont alors mis au point un "ver" baptisé General Graboids qui exploite ces failles pour se propager d'un joueur à l'autre. Concrètement, il utilise une vulnérabilité dans la fonction NetPacket::readFileMessage pour provoquer un bon vieux stack overflow.

Et bim bam boum, une fois en place, l'attaquant peut faire ce qu'il veut. Le ver droppe une DLL malicieuse (genre dbghelp.dll) directement dans le dossier du jeu et l'exécute. Vous êtes en pleine partie et hop, un script force votre base à tout vendre ("Sell Everything"). Puis c'est Game Over et après ça devient la fête du slip avec exécution de commandes système, installation de malwares...etc Y'a qu'à demander, tout est possible.

Ça fait flipper, non ?

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/command-conquer-generals-faille-malware-ver/command-conquer-generals-faille-malware-ver-1.mp4">lien vers la vidéo</a>.

Vous pensiez que votre PC était blindé avec toutes vos protections activées ? Et bien ça c'était avant que des chercheurs de Riot Games (oui, les mêmes mecs derrière League of Legends et Valorant) ne découvrent une bonne grosse faille UEFI qui touche les cartes mères des quatre plus gros fabricants du marché, à savoir ASUS, Gigabyte, MSI et ASRock.

La faille se décline en plusieurs CVE selon les constructeurs (CVE-2025-11901 pour ASUS, CVE-2025-14302 pour Gigabyte, CVE-2025-14303 pour MSI, CVE-2025-14304 pour ASRock) et concerne les protections DMA au démarrage. En gros, le firmware UEFI prétend activer l' IOMMU (un mécanisme matériel d'isolation mémoire destiné à bloquer les attaques DMA), sauf que dans les faits, il ne le configure pas correctement. Votre système pense être protégé alors qu'il ne l'est pas du tout... Bref ça craint !

Du coup, un attaquant qui branche un périphérique PCIe malveillant sur votre machine (notamment via Thunderbolt ou USB4, qui exposent du PCIe) peut lire ou modifier la mémoire système avant même que Windows ou Linux ne démarre. Donc bien avant que vos protections système n'aient eu le temps de se mettre en place quoi... Et comme l'attaque se déroule avant le chargement de l'OS, les antivirus et outils de sécurité logiciels classiques n'ont pas encore démarré et ne peuvent donc pas intervenir. Seule une mise à jour du firmware UEFI peut corriger le problème.

Côté chipsets touchés, accrochez-vous parce que la liste est longue. Chez Gigabyte, les bulletins de sécurité mentionnent notamment des cartes basées sur les séries Intel Z890, W880, Q870, B860, H810, Z790, B760, Z690, Q670, B660, H610, W790, et côté AMD des X870E, X870, B850, B840, X670, B650, A620, A620A et TRX50.

Chez ASUS, les chipsets concernés incluent les séries B460, B560, B660, B760, H410, H510, H610, H470, Z590, Z690, Z790, W480 et W680.

Et de son côté, ASRock indique que ses cartes mères Intel des séries 500, 600, 700 et 800 sont également affectées. Bref, si vous avez une carte mère relativement récente, il y a de bonnes chances qu'elle soit dans le lot, même si cela dépend du modèle précis et de la version de firmware installée.

Bien sûr, comme souvent avec ce type de faille, son exploitation nécessite un accès physique à la machine, puisqu'il faut connecter un périphérique PCIe capable de mener une attaque DMA (par exemple un dongle Thunderbolt ou une carte PCIe spécialement conçue).

Ce n'est donc pas le genre d'attaque qui se propage via Internet, mais c'est quand même problématique, notamment dans les entreprises qui ont des postes de travail accessibles au public, dans les bibliothèques, ou tout autre environnement partagé. Sans parler de quelqu'un qui aurait un accès temporaire à votre machine genre un réparateur, un collègue malveillant, votre ex un peu trop curieux(se)… Ou encore le marché de l'occasion, où personne ne sait vraiment ce qui a pu être branché sur la carte mère avant.

Petite anecdote au passage, les chercheurs de Riot Games sont tombés sur cette faille parce que Valorant refusait de se lancer sur certains systèmes. Leur anti-cheat Vanguard vérifie que les protections DMA sont bien actives au démarrage, et il a détecté que sur certaines machines, ce n'était pas le cas. De fil en aiguille, ils ont creusé et fini par identifier ce problème côté firmware UEFI.

Bref, les quatre constructeurs ont publié (ou sont en train de publier) des mises à jour de firmware pour corriger le problème. Attention toutefois, chez Gigabyte, le correctif pour TRX50 est prévu pour le premier trimestre 2026, et chez ASRock, les BIOS pour les séries 600/700/800 sont disponibles mais ceux de la série 500 sont encore en cours de développement.

Donc allez faire un tour sur le site support de votre fabricant, vérifiez si votre modèle est concerné, et installez le patch si c'est le cas.

Source

Vous avez peut-être une caméra Tapo C200 qui tourne chez vous pour surveiller le chat, le bébé ou l'entrée. C'est mon cas et j'adore cette caméra mais j'ai une mauvaise nouvelle à vous annoncer... Le chercheur en sécurité Simone Margaritelli (alias evilsocket) vient de passer 150 jours à la disséquer et le résultat n'est pas glorieux pour TP-Link.

Alors déjà, commençons par le plus gros WTF qu'il a découvert... la clé privée HTTPS de la caméra, ce truc censé être ultra-secret qui permet de chiffrer les communications. Et bien elle est hardcodée dans le firmware. C'est donc la même clé pour TOUTES les caméras du même modèle. Du coup, n'importe qui peut faire un Man-in-the-Middle et intercepter ce que vous voyez sur votre caméra. Ah on se met bien déjà là, hein ? ^^

Et attendez, ça ne s'arrête pas là puisque Margaritelli a trouvé un bucket S3 chez Amazon, totalement ouvert au public, qui contient TOUS les firmwares de TOUS les produits TP-Link. C'est open bar, sans authentification, Noël avant l'heure pour les chercheurs en sécu... et les hackers.

En fouillant le firmware avec Ghidra et Claude (oui, l'IA a aidé au reverse engineering), le chercheur a découvert quatre failles critiques. La première, c'est un buffer overflow dans le parser SOAP XML utilisé par le protocole ONVIF. En gros, si vous envoyez un message trop long, la caméra plante. Pas besoin d'être authentifié pour ça, une requête HTTP suffit.

La deuxième faille est du même genre mais dans le header Content-Length. Envoyez 4294967295 (le max d'un entier 32 bits) et boum, integer overflow. Et la troisième, c'est la cerise sur le gâteau puisque l'endpoint connectAp reste accessible sans authentification même après le setup initial. Du coup, un attaquant peut forcer votre caméra à se connecter à son propre réseau WiFi malveillant et intercepter tout le flux vidéo. Vous ne vous y attendiez pas à celle-là, si ?

Et la quatrième faille, oubliée nulle part ailleurs c'est l'API scanApList qui balance la liste de tous les réseaux WiFi autour de la caméra, sans auth. Avec les BSSID récupérés et un outil comme apple_bssid_locator, on peut géolocaliser physiquement la caméra à quelques mètres près. Sur les 25 000 caméras exposées sur le net, ça fait froid dans le dos.

Le plus frustrant dans cette histoire, c'est que Margaritelli a signalé tout ça en juillet 2025 et TP-Link a demandé des rallonges de délai, encore et encore, durant plus de 150 jours. Et au final, les failles ont été corrigées mais pas de patch sur les pages publiques des CVE. Ah et petit détail rigolo, comme TP-Link est sa propre autorité de numérotation CVE, ils s'auto-évaluent sur leurs propres failles. Donc y'a pas de conflit d'intérêt du tout... ahem ahem...

Le chercheur estime qu'environ 25 000 de ces caméras sont exposées directement sur Internet donc si comme moi, vous en avez une, vérifiez que le firmware est bien à jour et surtout, ne l'exposez JAMAIS directement sur le net. Mettez-la derrière un VPN ou un réseau isolé.

Je trouve ça cool que Margaritelli ait utilisé de l'IA pour accélérer la phase de reverse engineering. Avec Claude Opus et Sonnet avec GhidraMCP, il a pu analyser le code assembleur et c'est comme ça que l'IA a identifié rapidement les fonctions vulnérables et expliqué le fonctionnement du code. Bref, l'IA comme outil de hacking, c'est assez ouf...

Voilà, donc si vous avez du matos TP-Link chez vous, gardez un œil sur les mises à jour et réfléchissez à deux fois avant de l'exposer sur le net. Et si vous aimez la lecture, l'analyse complète est dispo sur le blog d'evilsocket .

Beau boulot !