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

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

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

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

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

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

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

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

Source : Califio

L'ANTS vient de se faire hacker... 19 millions de fiches dans la nature, récupérées via une faille IDOR (Insecure Direct Object Reference, pour les intimes). Pour ceux qui connaissent pas le terme, IDOR c'est l'exercice qu'on donne aux étudiants le deuxième jour d'un cours de cybersécurité !

En clair, l'attaquant envoyait une requête sur l'API en remplaçant l'identifiant de son profil par un autre. Et hop, le serveur lui renvoyait le dossier d'un citoyen français en face, sans jamais vérifier qu'il avait le droit de le consulter. Aucun contrôle d'autorisation sérieux, aucun rate-limiting, et visiblement aucune alerte quand une IP aspire 19 millions de fiches. Que dalle !

Le gars qui a découvert le truc s'appelle Seblatombe, il tient le blog FrenchBreaches et il a balancé l'info ce 20 avril. Les données fuitées, ce sont vos noms, prénoms, dates de naissance, adresses postales, emails, numéros de téléphone, identifiants ANTS et numéros d'accréditation pro. Par contre, les mots de passe et les données bancaires n'ont pas filé, et c'est bien le seul truc qui sauve ce dossier du naufrage complet.

Quoiqu'il en soit, ce n'est pas un accident isolé puisque qu'en mars 2024, France Travail se fait éventrer avec 36,8 millions de victimes. Avant ça, en janvier 2024, Viamedis et Almerys lâchent 33 millions d'assurés sociaux. En novembre 2024, Pajemploi expose 1,2 million de dossiers. Et plus récemment en décembre 2025, la CAF perd 8,6 millions de comptes.

Et maintenant l'ANTS, avec 19 millions de plus.

Faites le cumul les amis. Près de 100 millions de lignes fuitées depuis début 2024, avec évidemment des doublons puisqu'un même citoyen est fiché sur plusieurs services. Pour un pays de 68 millions d'habitants, c'est un joli record je trouve ! On devrait avoir une médaille !

Perso, ce qui me fait halluciner, c'est le communiqué officiel de l'ANTS. Leur conseil aux citoyens c'est, je cite, que vous "n'avez aucune démarche à accomplir". LOL ! France Travail, au moins, avait pris la peine de prévenir les victimes une par une et de publier un plan de remédiation, parce qu'ils s'étaient fait visiblement taper sur les doigts par la CNIL. Avec l'ANTS, c'est à vous de gérer le bordel qu'ils ont créé.

Alors concrètement, qu'est-ce que vous pouvez faire ? Déjà, allez vérifier si votre email traîne déjà dans la nature sur haveibeenpwned.com. Ensuite, changez le mot de passe de votre compte ANTS et activez la 2FA partout où elle est dispo.

Attention aussi aux mails ou SMS qui mentionnent votre nom et votre date de naissance, c'est le jackpot des arnaqueurs pour ressembler à un vrai service. Et surveillez vos comptes bancaires parce qu'avec nom + adresse + date de naissance + téléphone, une demande de crédit frauduleuse passe comme une lettre à la poste.

D'ailleurs, j'avais déjà fait un bilan des hacks français en 2025 qui résumait l'ambiance. Visiblement rien n'a changé. Les mêmes failles basiques, les mêmes audits inexistants, les mêmes communiqués minimalistes. L'État a transformé vos données personnelles en open bar pour cybercriminels, et le seul vrai plan de remédiation qu'on nous propose c'est de croiser les doigts.

Bref, une IDOR sur une agence qui gère les données de 19 millions de Français, franchement, c'est selon moi pas une erreur mais clairement une faute grave.

Source

En Indonésie, avant de vendre un jeu vidéo, les éditeurs doivent le soumettre à un organisme de classification (l'IGRS) pour obtenir une note d'âge, un peu comme le PEGI en Europe.

Pour obtenir leurs notes, les éditeurs envoient des vidéos de gameplay, des infos sur le contenu du jeu, et leurs coordonnées professionnelles. Le tout est stocké sur un serveur géré par le gouvernement indonésien.

Sauf que voilà, ce serveur était mal configuré. Un utilisateur Reddit, Me_Finity, a découvert qu'en tapant les bonnes adresses web, il pouvait accéder à la totalité des fichiers déposés par les éditeurs, sans mot de passe, sans vérification, sans rien du tout.

Il a récupéré environ 1 000 adresses email de développeurs (dont des gros studios) et surtout des vidéos de jeux pas toujours annoncés : 007 First Light, Echoes of Aincrad (le futur Sword Art Online de Bandai Namco), Castlevania Belmont's Curse, et le remake d'Assassin's Creed Black Flag.

En clair, les éditeurs avaient envoyé ces vidéos en toute confiance pour une simple formalité administrative, et n'importe qui pouvait les consulter depuis l'extérieur. Le système n'avait en fait aucune protection d'accès.

Le ministère indonésien de la Communication a lancé une enquête le 17 avril et coupé l'accès au système en attendant. Les développeurs concernés n'ont visiblement pas été prévenus avant, et plusieurs ont découvert la fuite en même temps que tout le monde.

Pour les éditeurs, c'est un double problème. D'abord les vidéos de jeux secrets qui se retrouvent sur Internet.

Et puis les adresses email pro exposées, qui peuvent servir à envoyer des tentatives de piratage ciblées à des gens qui travaillent sur des projets confidentiels.

Bref, un site gouvernemental mal protégé qui se transforme en plus grosse fuite jeu vidéo de l'année, rien de très étonnant.

Source : The Register

200 000 serveurs. C'est le nombre de machines potentiellement exposées à l'exécution de commandes système arbitraires via une faille de conception dans le SDK MCP d'Anthropic, d'après les chercheurs d'OX Security.

L'interface STDIO du protocole permet de créer des sous-processus sans contrôle, ce qui ouvre la porte à n'importe quelle commande OS sur la machine hôte.

Le problème touche tous les langages supportés par le SDK : Python, TypeScript, Java, Rust. Et les packages concernés totalisent plus de 150 millions de téléchargements. Les chercheurs ont documenté quatre classes de vulnérabilité. D'abord de l'injection de commandes non authentifiée, testée sur LangFlow (toutes les versions) et GPT Researcher

Ensuite des contournements de sécurité sur Upsonic et Flowise. Et puis de l'injection de prompt zero-click dans des IDE comme Windsurf, Cursor, Gemini-CLI et GitHub Copilot. Et enfin du "marketplace poisoning" : 9 marketplaces MCP sur 11 testées ont accepté un serveur malveillant de démonstration sans broncher.

10 CVE de niveau élevé ou critique ont été émis. OX Security a mené plus de 30 processus de divulgation responsable depuis novembre 2025, avant de rendre les résultats publics en avril.

La réponse d'Anthropic est celle qui fait grincer des dents. La boîte considère que le comportement est "attendu" et a refusé de modifier l'architecture du SDK. Elle a publié des recommandations de sécurité mises à jour, mais selon les chercheurs, "ça n'a rien corrigé". En clair, Anthropic estime que la sécurité de l'interface STDIO est du ressort de l'utilisateur qui déploie, pas du protocole lui-même.

C'est quand même un positionnement gênant, MCP est devenu un standard de facto pour connecter des modèles IA à des outils externes, et des milliers d'entreprises et de développeurs l'ont adopté.

Si le SDK officiel laisse passer de l'exécution de code arbitraire par design, et que la réponse officielle est "c'est voulu, sécurisez vous-mêmes", la responsabilité est déplacée vers l'aval sans filet.

Bref, si vous déployez du MCP en prod, les recommandations d'OX Security valent le détour. Anthropic ne corrigera pas à votre place.

Source : The Register

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

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

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

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

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

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

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

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

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

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

Source : The Register

Une attaque par la chaîne d'approvisionnement a frappé WordPress début avril. Un individu a racheté une trentaine de plugins via la marketplace Flippa, y a injecté du code malveillant et a attendu huit mois avant de l'activer. WordPress a fermé les 31 plugins concernés le 7 avril, mais la mise à jour officielle ne suffit pas à nettoyer les sites touchés.

L'attaque est redoutable par sa simplicité. Un individu, identifié sous le prénom "Kris", a racheté pour plusieurs centaines de milliers d'euros un catalogue d'une trentaine de plugins WordPress sur Flippa, une marketplace de vente de sites et d'extensions. Ces plugins appartenaient à la société Essential Plugin / WP Online Support. Ils étaient actifs, mis à jour, et installés sur des milliers de sites.

En achetant le catalogue, l'acheteur a récupéré l'accès au dépôt officiel WordPress.org et a pu pousser des mises à jour directement aux utilisateurs. Le code malveillant a été injecté dès août 2025, mais il est resté dormant pendant huit mois. L'activation a eu lieu les 5 et 6 avril 2026.

Côté technique, l'attaque est assez vicieuse. Le module injecté (wpos-analytics) utilise une désérialisation PHP pour communiquer avec un serveur de commande. Et là, le point intéressant : au lieu d'utiliser un domaine classique pour piloter la backdoor, le malware résout l'adresse de son serveur C2 via un smart contract Ethereum, en interrogeant des points d'accès RPC publics. Résultat, couper un nom de domaine ne sert à rien. L'attaquant peut mettre à jour le smart contract à tout moment pour pointer vers un nouveau serveur.

Le payload injecte du code dans le fichier wp-config.php (environ 6 Ko) et crée un fichier wp-comments-posts.php, un nom assez proche des fichiers légitimes pour passer inaperçu. Le tout sert à afficher du spam SEO (liens, redirections, fausses pages) uniquement à Googlebot, ce qui rend l'attaque invisible pour le propriétaire du site.

WordPress.org a fermé les 31 plugins touchés le 7 avril et a poussé une mise à jour forcée le lendemain. Sauf que cette mise à jour ne nettoie pas le fichier wp-config.php, qui est le vrai point de persistance de la backdoor. Si vous avez l'un de ces plugins installé (Countdown Timer Ultimate, Popup Anything on Click, Post Grid and Filter Ultimate, WP Slick Slider, Album and Image Gallery Plus Lightbox, Responsive WP FAQ, entre autres), il faut aller vérifier votre wp-config.php manuellement et chercher un bloc de code d'environ 6 Ko qui n'a rien à y faire. Le fichier wp-comments-posts.php à la racine du site doit aussi être supprimé s'il est présent.

La vraie leçon ici, c'est que la confiance dans un plugin WordPress repose sur son historique, et qu'un changement de propriétaire peut tout remettre en question du jour au lendemain. WordPress.org ne vérifie pas les changements de mains sur les comptes développeurs, et n'a aucun mécanisme d'alerte quand un catalogue entier passe à un nouvel acheteur. Tant que ce trou existe, ce genre d'attaque peut se reproduire. Et le fait que la mise à jour officielle ne nettoie même pas les sites infectés, c'est quand même un problème.

Source : The Next Web

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

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

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

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

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

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

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

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

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

Source : The Register

Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.

La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.

Quatre failles, dont une critique

Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.

La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.

Des fichiers supprimés et des téléchargements détournés

La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.

Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.

Qui doit mettre à jour

Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.

La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.

C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.

Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.

Source : Phoronix

Anthropic vient de lâcher une bombe !

Le labo derrière Claude a dévoilé le Projet Glasswing , une initiative de cybersécurité qui embarque un nouveau modèle, Claude Mythos, tellement efficace pour trouver des failles qu'ils ont décidé de ne pas le rendre public. En gros, l'IA est devenue meilleure que la plupart des humains pour dénicher des vulnérabilités zero-day... et ça va faire mal ^^.

Concrètement, Mythos a trouvé des milliers de zero-days dans tous les OS et navigateurs majeurs ces dernières semaines. Et pas des failles mineures, hein ! Une vulnérabilité dans OpenBSD qui traînait depuis 27 ans, un bug dans FFmpeg vieux de 16 ans qui avait survécu à 5 millions d'itérations de tests automatisés... et des exploits chaînés dans le noyau Linux (3, 4, parfois 5 vulnérabilités enchaînées de manière autonome) qui permettent une escalade de privilèges complète. Comme le dit un chercheur dans la vidéo de présentation : "J'ai trouvé plus de bugs ces dernières semaines que pendant tout le reste de ma carrière combinée".

49 jours, les amis, c'est la durée de vie d'un Mac avant que son réseau TCP ne s'effondre dans un silence assourdissant. Il suffit d'un overflow d'entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d'ouvrir la moindre connexion. Le ping marche toujours, parce qu'ICMP se fout du TCP, mais pour le reste... c'est reboot obligatoire ou rien.

Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou même Ventura tourne depuis plus de 7 semaines sans redémarrage, c'est le moment d'y remédier car le bug touche toutes les versions.

C'est l'équipe de Photon qui a révélé le problème. Celui-ci est apparu sur une flotte de Macs dédiée à la télémétrie iMessage. Pile 49,7 jours après le dernier redémarrage, plusieurs machines ont lâché en même temps. Plus de nouvelles connexions réseau, mais le ping répondait toujours.

En fouillant le code du noyau XNU d'Apple (qui est open source, faut le rappeler), ils sont tombé sur une variable tcp_now, qui est un compteur 32 bits qui s'incrémente chaque milliseconde. En gros, imaginez un compteur kilométrique qui arrivé au max (environ 4,3 milliards), repasse à zéro.

Sauf que le code contient un garde fou censé empêcher l'horloge de reculer du genre "si la nouvelle valeur est plus petite que l'ancienne, on ne met pas à jour". Ça a l'air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de zéro) est forcément plus petite que l'ancienne (proche du max), du coup le garde fou bloque tout et l'horloge TCP se fige.

Et ensuite, ça part en cascade. Les connexions fermées restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d'être nettoyées par tcp_gc() mais avec l'horloge gelée, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps réel avec des connexions mortes qui s'empilent, et finissent par bouffer les 16 384 ports éphémères (range 49152-65535 sur macOS) restant... Et au bout de quelques heures, plus rien ne passe !

Photon a laissé tourner deux machines après l'overflow pour voir. Neuf heures plus tard, l'une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d'attente de connexions mortes.

Si ça vous rappelle quelque chose, c'est normal car j'sais pas si vous vous souvenais mais Windows 95 plantait au bout du même délai pour la même raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait également un souci similaire au bout de 51 jours sur ses switches réseau, sans oublier le bug de l'an 2038 sous Unix, qui est la version signée du même phénomène. 30 ans séparent certains de ces bugs qui pourtant appartiennent à la même catégorie !

Après flippez pas car des devs avec des Macs à plus de 600 jours d'uptime disent n'avoir jamais eu le souci. À vrai dire, le bug ne se déclencherait que si votre Mac n'a aucun trafic TCP pile au moment de l'overflow. Si votre machine cause au réseau en permanence (et c'est le cas de 99% des Macs), l'horloge passe le cap sans broncher.

Les machines les plus exposées sont en fait les serveurs CI/CD sous macOS, les Mac mini en ferme de build Jenkins ou GitHub Actions, les Mac Pro dédiés au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n'est pas vraiment concerné (le compteur tcp_now ne tourne pas pendant la veille, donc le délai de 49 jours ne concerne que le temps d'activité réel).

Maintenant pour vérifier votre compte à rebours personnel, ouvrez un Terminal et collez y ceci :

boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Temps restant avant overflow : $((remain/3600))h $((remain%3600/60))m"

CUPS, le système d'impression utilisé par macOS et la plupart des distributions Linux, est touché par deux nouvelles vulnérabilités. Elles ont été trouvées par des agents d'intelligence artificielle, et permettent une exécution de code à distance.

Aucun correctif officiel n'est disponible pour le moment, et les preuves de concept sont déjà publiques. Les environnements professionnels sont les premiers concernés.

Quand l'IA fait le boulot des chercheurs en sécurité

C'est un ingénieur sécurité de SpaceX, Asim Manizada, qui a publié les détails de ces deux failles. Le plus surprenant, c'est qu'il ne les a pas trouvées tout seul. Il a utilisé des agents IA pour analyser le code de CUPS et débusquer les problèmes.

Son travail s'inspire des recherches de Simone Margaritelli, qui avait déjà montré en 2024 comment enchaîner plusieurs failles CUPS pour exécuter du code à distance sur des machines Linux.

Les deux vulnérabilités portent les références CVE-2026-34980 et CVE-2026-34990. Elles touchent CUPS 2.4.16 et peuvent être combinées pour un résultat assez redoutable.

Deux failles qui se complètent

La première faille permet à un attaquant d'envoyer une tâche d'impression sur une file PostScript partagée, sans aucune authentification.

CUPS accepte par défaut les requêtes anonymes sur les files partagées, et un mécanisme d'échappement de caractères permet d'injecter du code qui sera exécuté en tant qu'utilisateur "lp". En pratique, un attaquant peut forcer le serveur à lancer un programme de son choix.

La seconde faille concerne l'authentification du démon cupsd. Un utilisateur local sans privilège peut tromper le service pour qu'il s'authentifie auprès d'un faux serveur IPP contrôlé par l'attaquant.

Le jeton récupéré permet alors d'écraser n'importe quel fichier avec les droits root. Combinées, les deux failles donnent à un attaquant distant et non authentifié la possibilité d' écraser des fichiers système en tant que root.

Pas de patch, mais des correctifs dans les tuyaux

Pour le moment, aucune mise à jour officielle de CUPS n'a été publiée. Michael Sweet, le créateur et mainteneur du projet, a mis en ligne des correctifs sur GitHub, mais il n'y a pas encore de version patchée à télécharger.

Manizada prévient que ces failles seront faciles à reproduire, vu que les preuves de concept sont publiques et que les modèles de langage actuels peuvent transformer un rapport technique en exploit fonctionnel en quelques minutes.

Côté impact, CUPS est le système d'impression par défaut de macOS et de la quasi-totalité des distributions Linux. Pour être vulnérable, il faut que le serveur CUPS soit accessible sur le réseau avec une file d'impression partagée configurée, ce qui est courant dans les environnements professionnels.

C'est quand même un drôle de signal. D'un côté, l'IA montre qu'elle sait trouver des failles de sécurité plus vite que les humains. De l'autre, les mainteneurs open source galèrent toujours autant pour sortir les correctifs à temps. Manizada lui-même le dit : les modèles de langage peuvent convertir un simple rapport technique en code d'attaque prêt à l'emploi.

Du coup, entre la divulgation d'une faille et le premier exploit, on parle de quelques heures, pas de quelques semaines. Si vous gérez des imprimantes en réseau, le plus prudent reste de couper le partage des files CUPS en attendant le patch, ou au moins de restreindre l'accès réseau au service. Pas très pratique, mais c'est le prix à payer quand le système d'impression a vingt ans de code derrière lui.

Source : The Register

Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.

Enfin !

Ce module s'appelle hid-omg-detect et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.

D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.

Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers USBGuard pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !

Mais alors pourquoi lancer ça maintenant ?

Hé bien parce que les outils d'attaque USB sont devenus légion ! Les câbles O.MG (créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois, des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB ... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.

Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme USBRip (un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.

On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les attaques par périphériques USB piégés . Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !

Bref, va falloir garder un œil là-dessus.

Source

Ce week-end, pendant qu'on se gavait d'oeufs de Pâques au Cadmium, un chercheur en sécu a balancé un zero-day Windows dans la nature... et tout ça d'après ce que j'ai compris, à cause de Microsoft qui l'a vraiment poussé à bout. L'exploit s'appelle BlueHammer et il permet à quiconque ayant un accès local sur une machine Windows 11 25H2 de passer SYSTEM. Et vous vous en doutez y'a toujours pas de patch.

Il s'agit d'une d'une escalade de privilèges locale (LPE) qui exploite une race condition de type TOCTOU (time-of-check to time-of-use), combinée avec une confusion de chemins dans le processus de mise à jour des signatures de Windows Defender. Je sais, il est trop tôt pour ces conneries mais disons que c'est le bug classique où un programme vérifie un truc, puis l'utilise, mais entre les deux quelqu'un a changé le truc en question.

En gros, l'exploit profite d'une fenêtre de temps entre le moment où Defender vérifie un fichier et celui où il l'utilise pour glisser un lien symbolique qui redirige vers la ruche SAM, le fichier C:\Windows\System32\config\SAM (là où Windows stocke les identifiants locaux). Et là, après ça devient open bar sur les hash de mots de passe de tous les comptes locaux.

Le chercheur derrière tout ça opère sous les pseudos Chaotic Eclipse et Nightmare-Eclipse et le 3 avril 2026, il a publié le code source complet sur GitHub , signé PGP, avec ce message assez salé : " I was not bluffing Microsoft, and I'm doing it again. "

Son reproche ? D'abord le MSRC (Microsoft Security Response Center) qui lui a demandé une vidéo de démonstration pour valider son rapport, et ensuite une réponse sur ce bug Windows Defender qui ne l'a visiblement pas satisfait : "I'm just really wondering what was the math behind their decision"

Will Dormann, analyste principal chez Tharros (ex-Analygence) et référence dans le milieu, a confirmé que l'exploit fonctionne, même s'il précise que l'exploitation n'est pas triviale. Une fois les privilèges obtenus, l'attaquant a les clés du royaume et peut lancer un shell avec les privilèges SYSTEM comme si c'était chez lui... Donc pas trivial, certes mais bien réel. D'ailleurs, c'est pas la première fois que Windows se fait éplucher par des chercheurs qui trouvent sans difficultés des failles d'escalade de privilèges en série.

Source : Will Dormann

Après, sous le capot, c'est quand même bien foutu. Un développeur (0xjustBen) a réimplémenté le PoC de manière modulaire et ça montre bien la mécanique : un module télécharge une vraie mise à jour Defender, un autre surveille les Volume Shadow Copies, un troisième enregistre un callback via l'API Cloud Files.

Source : Will Dormann

Et le cœur du truc joue la race condition avec un swap de lien symbolique pour lire la ruche SAM.

Notez quand même que le PoC original contient des bugs (le chercheur l'admet lui-même dans le README) et ne fonctionne pas sur Windows Server... ce qui ne veut pas dire que c'est inoffensif, attention. Et la réimplémentation de 0xjustBen, elle, n'a fonctionné que sur Windows 11 25H2, les versions 22H2, 23H2 et 24H2 n'étant pas affectées. Pas de CVE attribuée non plus pour l'instant, ce qui veut dire que Microsoft n'a même pas encore catalogué officiellement le problème.

Côté protection, c'est pas simple vu qu'il n'y a pas de correctif officiel mais comme l'attaque nécessite un accès local à la machine, ça limite pas mal les scénarios. Faut déjà être sur le poste Windows, que ce soit via un malware, du social engineering ou un accès physique. Après on sait bien qu'en entreprise, un poste partagé ou un stagiaire un peu curieux, c'est pas rare...

Premier réflexe donc : allez vérifier votre version de Windows (Paramètres > Système > À propos, ou winver dans Exécuter). Si vous n'êtes pas sur 25H2, vous n'êtes pas concerné. Sinon, vérifiez que vos comptes locaux ont des mots de passe costauds (pas "admin123"), désactivez les comptes inutilisés et gardez un œil sur les processus qui tournent avec des privilèges élevés. Côté entreprise, les solutions EDR devraient pouvoir détecter le comportement suspect (création de service temporaire, accès SAM inhabituel).

Bref, je pense que Microsoft finira bien par patcher... un jour.

Source

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