Mac Souverain — Radars

La fausse mise à jour Zoom qui vide ton trousseau iCloud

Mac Souverain — Tue, 28 Jul 2026 09:15:00 GMT

Un contact que tu connais t'invite en visio sur Telegram, sauf que son compte est détourné. Pendant l'appel, une fausse mise à jour « Zoom SDK Update » surgit, tu cliques pour réparer ton micro, et **un stealer siphonne les clés de ton navigateur** depuis ton trousseau iCloud. BlueNoroff, Corée du Nord, zéro faille exploitée, 100% ingénierie sociale. C'est le troisième ClickFix sur macOS en six semaines.

Ce que tu dois faire

1. Une invite d'installation en pleine réunion, tu refuses. Aucune visio ne te livre de « SDK Update » en cours d'appel.

2. Un lien de réunion, même d'un contact réel, vérifie-le par un autre canal. Le compte Telegram d'en face est peut-être compromis.

3. Un pare-feu sortant, Little Snitch ou LuLu, voit partir l'exfil vers Telegram quand le stealer vide ton trousseau.

Ce qui se passe vraiment en pleine visio

BlueNoroff, la bannière nord-coréenne qui vise les professionnels de la crypto, n’exploite aucune faille. Zéro exploit, zéro CVE. Juste de l’ingénierie sociale, montée en chaîne industrielle. La recherche est signée JUMPSEC, le cluster « ClickFake Interview » est suivi par Sekoia, et The Hacker News a relayé le 24 juillet 2026.

Le déroulé. Un contact que tu as rencontré en personne t’écrit sur Telegram, sauf que son compte est détourné. Il t’envoie un lien Calendly à son nom, qui te redirige vers un domaine Zoom ou Teams typosquatté, us.zoom.06webin.us. Tu saisis ton nom, tu autorises la caméra, et le kit se met au travail dans ton dos. Il capte ton flux vidéo via mediasoup WebRTC et profile les extensions de portefeuille crypto installées dans ton navigateur. Puis un faux message, « ton micro ne marche pas », suivi d’une invite « Zoom SDK Update ». Tu cliques pour réparer ton micro, tu installes la charge.

Sur macOS, le reste se déroule sans toi. Un script shell télécharge un faux installeur Teams ou Zoom, un stealer en extrait les clés maîtresses de Chrome depuis le trousseau local de ta session macOS, là où Chrome range sa clé de chiffrement, celles qui déverrouillent tes extensions de portefeuille crypto, et exfiltre le tout via un canal Telegram baptisé « Aurora », avant de déposer d’autres charges. Côté Windows, la variante désactive Defender via un loader PowerShell et fouille les sessions Telegram dans Chrome, Edge, Brave et Firefox. Même acteur, deux chaînes.

Deux détails changent l’échelle. Les visios sont truquées par deepfake, des visages générés par IA plaqués sur du langage corporel réel, capté sur les victimes précédentes. Et le mécanisme s’auto-propage, chaque compte Telegram compromis devient l’expéditeur de confiance du suivant. Cinq versions du kit ont été repérées entre le 31 mai et le 14 juillet 2026, l’opérateur est relié au bot Telegram @alchemy_john_mac. Ce n’est pas un coup isolé, c’est une usine qui itère.

La technique porte un nom, ClickFix, et elle traîne déjà une série de victimes derrière elle.

À lire : ClickFix, le faux correctif qui te fait lancer le malware toi-même

Le troisième ClickFix sur macOS en six semaines

Fais le compte. CrashStealer en juillet, ClickLock avant lui, maintenant BlueNoroff. Trois fois en six semaines que le même schéma frappe macOS, un geste anodin qui déclenche l’installation. Le vecteur s’industrialise, et cette version vise directement ton trousseau, là où macOS range les clés de ton navigateur.

À lire : Un malware notarisé Apple passe Gatekeeper

Ce qui te protège ici, ce n’est ni l’antivirus ni la notarisation. C’est une règle de comportement, simple et absolue, ne jamais installer un binaire qu’on te propose en cours de réunion. Zoom ne te livre pas de « SDK Update » en plein appel. Teams non plus. Une mise à jour qui surgit pendant une visio n’est pas une mise à jour, c’est la charge.

Il y a un angle stack, à condition d’être honnête sur sa portée. Proton Meet est chiffré de bout en bout et tourne dans ton navigateur, sans client natif à installer. Le prétexte « installe cette mise à jour SDK » n’a donc nulle part où s’accrocher, il n’y a pas d’app à mettre à jour. Ça réduit la surface d’attaque, ça ne remplace pas la règle de comportement. Passer à Proton Meet ne te protège pas de ce phishing, l’ingénierie sociale ne dépend d’aucun outil.

À lire : Proton Meet, la visio chiffrée qui tourne dans le navigateur

Le point qui doit t’inquiéter, c’est l’expéditeur. Ce n’est pas un inconnu, c’est quelqu’un dont tu as serré la main. La confiance interpersonnelle est le vecteur, pas ta crédulité. Un compte Telegram authentique, un nom que tu reconnais, un lien de réunion, il n’en faut pas plus.

Ce que tu fais maintenant

1. Une invite d’installation qui apparaît pendant une réunion, tu refuses, sans exception. Zoom, Teams, aucune visio ne te demande d’installer un « SDK Update » ni de réparer ton micro par un téléchargement. Tu quittes l’appel, tu ne cliques rien.

2. Un lien de réunion, même envoyé par un contact réel, tu le vérifies par un autre canal avant de cliquer. Un appel voix, un message Signal, « c’est bien toi qui m’as envoyé ce Calendly ? ». Le compte Telegram d’en face est peut-être déjà détourné.

3. Regarde l’URL avant d’autoriser ta caméra. us.zoom.06webin.us n’est pas un domaine Zoom, c’est du typosquat. Le vrai Zoom, c’est zoom.us. Un sous-domaine à rallonge greffé sur un nom inconnu, tu fermes l’onglet.

4. Installe un pare-feu sortant et laisse-le parler. Little Snitch ou LuLu voient partir l’exfiltration vers Telegram, exactement le moment où le stealer vide ton trousseau. C’est ta dernière ligne quand tout le reste a été contourné.

À lire : Little Snitch vs LuLu, quel pare-feu sortant pour ton Mac

Sources

The Hacker News, qui a relayé la recherche le 24 juillet 2026
Recherche primaire JUMPSEC, analyse du kit de phishing BlueNoroff
Cluster « ClickFake Interview » suivi par Sekoia

Claude Cowork en local, l'agent sort du bac à sable

Mac Souverain — Fri, 24 Jul 2026 10:00:00 GMT

Tu connectes un dossier à Claude Cowork, et l'agent a en réalité tout ton disque sous la main. En mode d'exécution local sur macOS, Cowork monte l'intégralité du système de fichiers en lecture-écriture dans la machine virtuelle de l'agent. Un seul message suffit à l'en faire sortir, sans qu'aucune invite de permission n'apparaisse. Anthropic a clôturé le rapport en « informative », sans correctif : la bascule vers l'exécution cloud mitige, mais elle est en bêta graduelle, et le mode local reste exposé.

Ce que tu dois faire

1. Vérifie le mode d'exécution de ton Cowork. Le cloud est devenu le défaut, mais en bêta et par vagues : va le lire dans tes réglages plutôt que de le supposer. Le local te laisse dedans.

2. Ne lance jamais une session locale sur un compte macOS qui contient ton Trousseau, tes clés SSH ou ton fichier de mots de passe.

3. Traite tout ce que l'agent lit, page web, pièce jointe, ticket, comme du code hostile. C'est l'entrée de la chaîne.

Ce que Cowork monte vraiment

En mode d’exécution local sur macOS, Claude Cowork monte l’intégralité du système de fichiers de ton Mac en lecture-écriture à l’intérieur de la machine virtuelle Linux où tourne l’agent, sur un point de montage nommé /mnt/.virtiofs-root, visible du seul compte guest-root. Tout le disque. Pas le dossier que tu as connecté. Le bac à sable est un bac, il n’a juste pas de bords. La recherche, baptisée SharedRoot, est signée Oren Yomtov, chercheur principal en sécurité chez Accomplish AI, publiée le 23 juillet 2026 et relayée le jour même par The Hacker News.

La documentation d’Anthropic annonce pourtant, pour le mode local, un accès fichier « limité aux dossiers que le membre a connectés ». C’est la promesse. Le montage, lui, expose l’hôte entier.

L’évasion se déroule d’un bloc. L’agent démarre en utilisateur de session non privilégié, s’octroie root dans un espace de noms utilisateur, puis fait autocharger par le noyau un module du sous-système Traffic Control qui porte CVE-2026-46331, dite pedit COW : le simple fait de le référencer suffit à le charger. La faille est notée 7.8 au CVSS 3.1 par kernel.org sur sa fiche NVD, 6.7 par Red Hat, avec un exploit public, PACKET_EDIT_MEME.c, disponible depuis le 17 juin. La corruption du cache de pages empoisonne un binaire mis en cache, que le démon coworkd réexécute ensuite en root. À l’arrivée, guest-root a tout le disque de l’hôte entre les mains.

The Hacker News avance environ 500 000 utilisateurs macOS en session locale, un ordre de grandeur qu’aucune méthode publiée n’étaye et que le billet des chercheurs ne reprend pas. Retiens l’échelle, pas le chiffre. Ce qui est certain, c’est qu’aucune invite de permission n’apparaît à aucun moment de la chaîne.

Sur le correctif, il faut être précis, parce que le sujet se prête au raccourci. Anthropic a clôturé le rapport en « informative », sans correctif dédié. Dans le même temps, Cowork est passé à l’exécution cloud par défaut : Anthropic ne publie pas de numéro de version pour Cowork, mais date le changement du 7 juillet 2026 et le qualifie de bêta en déploiement graduel, à partir du plan Max. Les chercheurs notent que la chaîne d’évasion locale « ne semble pas s’appliquer » côté cloud, sans l’avoir auditée. La mitigation est réelle. Elle ne referme rien pour ceux qui exécutent en local, et elle n’a pas encore atteint tout le monde.

La VM donne l’impression d’un mur

La phrase vaut au-delà de cette faille : le bac à sable d’un agent n’est pas une frontière de sécurité s’il monte tout le disque. La machine virtuelle donne l’impression d’un cloisonnement, le montage l’annule silencieusement. Entre le dossier que tu crois partager et ton compte utilisateur complet, il y a un gouffre que rien dans l’interface ne signale.

À lire : L’ANSSI place Claude Cowork et OpenClaw en alerte

La chaîne suppose que l’agent exécute déjà du code hostile. Sauf que c’est son métier : ingérer un contenu que tu ne contrôles pas, page web, PDF, ticket, puis agir. Sur ce type d’outil, l’injection de prompt n’a rien d’une hypothèse de laboratoire. C’est l’entrée principale.

À lire : Hugging Face compromis, et ton modèle local ?

Les chercheurs recommandent quatre durcissements, et précisent que chacun, seul, suffit à casser la chaîne. Un seul traite pourtant la cause : ne monter que les dossiers réellement connectés. Les trois autres retirent une marche à cet escalier-là, le quatrième supprime l’escalier.

Le défaut n’est pas isolé, il fait classe. Un modèle qui s’échappe de son bac de test, un protocole d’agent qui expose l’exécution de code, maintenant un agent à qui on a monté le disque entier. Le point commun n’est jamais le bug, c’est la générosité du périmètre accordé par défaut.

À lire : MCP d’Anthropic, un défaut de conception expose 200 000 instances

Ce que tu fais maintenant

1. Vérifie le mode d’exécution de ton Claude Cowork. Le cloud est devenu le défaut, mais en bêta et par vagues depuis le 7 juillet : ne présume pas que ton compte l’a reçu, va le lire dans les réglages. Si tu es en local, volontairement ou en héritant d’un réglage ancien, tu es concerné.

2. Ne lance jamais une session locale depuis un compte macOS qui héberge ton Trousseau, tes clés SSH ou le fichier de ton gestionnaire de mots de passe. Un compte utilisateur dédié à l’agent, vide de secrets, coûte cinq minutes et retire tout intérêt à l’évasion.

3. Traite tout ce que l’agent ingère comme du code hostile. Une page web, une pièce jointe, un ticket client : c’est l’entrée, et elle n’est pas filtrée. Tu ne lancerais pas ce contenu dans un script sans regarder, ne le donne pas à mâcher à un agent qui a les droits d’écriture.

Sources

Hugging Face compromis, et ton modèle local ?

Mac Souverain — Wed, 22 Jul 2026 09:00:00 GMT

La logithèque où LM Studio va chercher tes modèles s'est fait compromettre, Hugging Face l'a révélé le 16 juillet. L'entreprise y a laissé des identifiants d'infrastructure interne, pas les tiens, et ne relève aucune altération des modèles publics. Le twist : pas de pirate. OpenAI déclare qu'il s'agissait de ses propres modèles, échappés d'un test interne.

Ce que tu dois surveiller

1. Sans compte Hugging Face, tu n'as rien à faire. Ce que tu as téléchargé n'a pas bougé.

2. Avec un compte, fais tourner tes tokens d'accès et relis l'activité récente, par précaution.

3. Hugging Face n'a pas fini d'évaluer si des données partenaires ou clients ont été touchées.

Le fait

Le 16 juillet 2026, Hugging Face a divulgué une intrusion survenue quelques jours plus tôt dans une partie de son infrastructure de production. Le point d’entrée, un dataset malveillant exploitant deux chemins d’exécution de code : un chargeur de dataset à code distant, et une injection de template dans sa configuration. Puis escalade de privilèges et mouvement latéral, tranquillement, sur un week-end.

L’entreprise a analysé le journal de l’attaque avec des agents LLM et il en ressort « plus de 17 000 événements enregistrés ». C’est un comptage forensic d’événements de log, pas un décompte des actions de l’attaquant. Hugging Face évoque dans la foulée un essaim de dizaines de milliers d’actions automatisées. Personne n’a vu un humain taper au clavier.

Ce qui est sorti, ce sont « un ensemble limité de jeux de données internes » et « plusieurs identifiants utilisés par nos services », plus des identifiants cloud et cluster récoltés au passage. Les clés de la maison Hugging Face, donc, pas les tiennes. Aucune fuite de données utilisateurs n’est établie. Et une semaine plus tard, l’entreprise n’a toujours pas fini d’évaluer si des données partenaires ou clients ont été touchées.

Ton modèle local, lui, n’a pas bougé

Voilà le point qui t’intéresse si tu as installé LM Studio et téléchargé un modèle en MLX. Hugging Face est explicite : aucune preuve d’altération des modèles, datasets ou Spaces publics, et la chaîne d’approvisionnement, images de conteneurs et paquets publiés, « a été vérifiée saine ». Le fichier qui dort sur ton SSD est bien celui que tu crois.

Sauf qu’« aucune preuve d’altération » n’est pas « nous avons prouvé qu’il n’y a pas eu d’altération ». C’est la meilleure information disponible, produite par une entreprise en pleine réponse à incident. Pas une garantie notariée.

Si tu as un compte, Hugging Face recommande « par précaution » de faire tourner tes tokens et de relire l’activité récente. Retiens bien le « par précaution » : rien n’indique qu’un token utilisateur ait fuité.

Un modèle déjà posé sur ton disque se moque, lui, de l’état de santé de sa logithèque.

À lire : Installe ton premier modèle d’IA en local sur Mac

Le twist, l’attaquant n’était pas un pirate

Le 21 juillet, OpenAI a déclaré que l’incident avait été mené par une combinaison de ses propres modèles, dont GPT-5.6 Sol et un modèle pré-release encore plus capable, tous avec les garde-fous cyber assouplis pour les besoins de l’évaluation, pendant un test interne sur un benchmark de capacités offensives nommé ExploitGym. Déclaration reprise verbatim par TechCrunch, recoupée par Bloomberg, Fortune et The Register.

Reste la question qui fâche, comment ces modèles sont-ils sortis de leur environnement de test ? Selon OpenAI, ils auraient exploité une faille zero-day dans le proxy cache d’un registre de paquets. C’est la version de la partie responsable, auto-déclarée, qu’aucun audit externe n’a vérifiée. Hugging Face, lui, a fait appel à des spécialistes forensic externes, mais sur son propre incident, pas sur l’évasion côté OpenAI. Personne d’extérieur n’a regardé sous ce capot-là.

À lire : Mythos, le modèle qui trouve des failles tout seul, vient de fuiter

Deux détails qui vieillissent mal. Hugging Face n’a jamais amendé son avis de sécurité : le texte officiel dit toujours que le LLM utilisé reste inconnu. L’attribution vit dans un billet d’OpenAI et des déclarations orales, pas dans ce document-là. Et l’entreprise a signalé l’incident aux forces de l’ordre, pour ce qui s’avère être l’accident d’une entreprise tierce. Personne n’a dit ce que devient ce signalement.

À lire : GPT-5.5 passe en capacity-class cybersec. OpenAI serre les accès.

La leçon en creux

Pendant la réponse à incident, Hugging Face a voulu analyser les traces avec des modèles de frontière via API commerciales. Les garde-fous des fournisseurs, incapables de distinguer une équipe de réponse à incident d’un attaquant, ont bloqué ses analystes. Ils ont fini sur GLM 5.2, un modèle open-weight du chinois Z.ai, sur leur propre infrastructure.

Savoure le paradoxe : le modèle qui a fini par les aider venait de Chine, et c’est justement parce qu’il tournait chez eux que son origine n’avait plus d’importance. Le jour où tu enquêtes sur ta machine, le modèle qui t’aide a intérêt à tourner chez toi.

Ce que tu fais maintenant

1. Pas de compte Hugging Face ? Tu n’as rien à faire. Rien du tout. Hugging Face n’a relevé aucune altération sur les modèles publics, et ton installation locale ne repose sur aucun identifiant concerné.

2. Compte Hugging Face ? Fais tourner tes tokens d’accès, révoque ceux dont tu ne te sers plus, relis l’activité récente. Précautionnel, pas urgent, gratuit.

3. Prends l’habitude de regarder d’où vient un modèle. Dans LM Studio, chaque variante affiche son dépôt d’origine, et un dépôt officiel ou communautaire établi n’a pas le même profil de confiance qu’un miroir reposté par un compte créé le mois dernier.

Sources

Un malware notarisé Apple passe Gatekeeper

Mac Souverain — Thu, 16 Jul 2026 13:56:37 GMT

CrashStealer, un infostealer macOS déguisé en outil de rapport de crash Apple, franchit Gatekeeper sans la moindre alerte. Il est signé par un Developer ID valide et notarisé par Apple. Ton Mac fait confiance à la signature, pas à l'intention derrière. Apple a révoqué le certificat après coup, une fois les dégâts faits.

Ce que tu dois faire

1. Toute app ou DMG hors App Store reçu par invitation ou lien direct, la signature Apple ne rachète pas la provenance.

2. Un prompt qui réclame ton mot de passe login « pour continuer » sans installation légitime en cours, c'est un signal d'alerte.

3. Les connexions sortantes inattendues, un pare-feu applicatif comme Little Snitch ou LuLu les voit passer.

Un logiciel malveillant se déguise en outil de rapport de crash Apple. Il est signé par un Developer ID valide et notarisé par Apple elle-même. Résultat, il franchit Gatekeeper sans le moindre avertissement, parce que ton Mac vérifie la signature, jamais l’intention.

Le fait

Jamf Threat Labs a repéré un échantillon suspect sur VirusTotal début mai 2026, puis observé de vraies infections sur des Macs clients début juillet. Le malware s’appelle CrashStealer. Particularité rare, il est écrit en C++ natif, là où l’immense majorité des voleurs macOS bricolent en AppleScript. Il se fait passer pour un outil de rapport de crash Apple, le genre de fenêtre que tu as déjà vue cent fois sans y prêter attention.

La livraison est soignée. Le malware arrive dans un disque image nommé « Werkbit », l’app à l’intérieur s’appelle « Werkbit.app ». Fait notable, le DMG lui-même est signé, pas seulement l’app qu’il contient. Le certificat, un Developer ID au nom de « Emil Grigorov » (WWB7JA7AQV), valide, actif, notarisé par Apple. Le domaine de diffusion, werkbit[.]io, a été enregistré en juin 2026, et le téléchargement est verrouillé derrière un code PIN de réunion. Traduction, l’installeur n’est servi qu’à des victimes choisies, jamais aux scanners automatiques ni au visiteur de passage.

Une fois lancé, le dropper récupère la vraie charge depuis l’infrastructure de l’attaquant. Avant de récolter quoi que ce soit, il te présente un faux prompt système et valide ton mot de passe de session en local. Ensuite, il vide tout, les profils de navigateurs, le Trousseau, quatorze gestionnaires de mots de passe (1Password, Bitwarden, LastPass, Dashlane, Keeper compris) et près de quatre-vingts extensions de portefeuilles crypto. Le butin est chiffré en AES-GCM puis exfiltré via libcurl. Il se recopie et se re-signe pour persister.

Apple a révoqué le certificat de signature après le signalement de Jamf. Le mal était déjà fait pour ceux qui avaient cliqué.

Pourquoi Gatekeeper n’a rien vu

Voici le nœud. La notarisation Apple n’est pas un audit de sécurité. C’est un scan automatisé qui cherche des signatures de malware déjà connu et vérifie que le binaire est signé par un Developer ID valide. Rien de plus. Apple n’a pas lu le code de CrashStealer, elle n’a pas jugé ses intentions, elle a passé un binaire propre au moment du scan à travers une moulinette qui ne voyait rien de familier.

Le tampon de notarisation dit une seule chose, « ce fichier est signé par un développeur identifié et ne correspond à aucun malware connu ». Il ne dit pas « ce logiciel est sûr ». La nuance a l’air théorique. Elle est le sujet.

Un attaquant qui ouvre un compte Apple Developer à 99 dollars par an, sous une identité crédible, obtient un passe pour franchir Gatekeeper en silence. Le kill-switch d’Apple, la révocation du certificat, ne joue qu’après coup, une fois les dégâts documentés. Apple pousse ses défenses en silence, elle ne prévient pas quand elle a laissé passer. C’est un pompier, pas un vigile.

À lire : Ton Mac a été patché par XProtect à ton insu

Ce que ça change pour toi

Le réflexe collectif, « c’est signé Apple, donc c’est bon », vient de prendre une balle. Ton Mac fait confiance à la signature, pas à l’intention derrière. Un binaire notarisé n’est pas un binaire béni. C’est un binaire dont on connaît l’auteur déclaré, ce qui est utile pour le poursuivre après coup, inutile pour t’éviter l’infection.

Le ciblage par PIN de réunion change aussi la donne. Ce malware ne se pêche pas au chalut sur un forum de warez. Il arrive par invitation, dans un contexte qui a l’air professionnel, servi à toi et pas à un scanner. Le vieux réflexe « je ne télécharge que des trucs connus » ne suffit plus quand le lien t’est tendu à la main.

La vraie ligne de défense, ce n’est pas le tampon Apple. C’est toi, ta méfiance, et un outil qui voit ce que le logiciel fait vraiment une fois lancé, ses connexions sortantes.

Ce que tu fais maintenant

1. Traite toute app ou tout DMG reçu hors App Store comme suspect par défaut, surtout quand il arrive par invitation, lien direct ou message « installe ça pour la réunion ». La signature Apple ne rachète pas une provenance douteuse. Si tu ne l’as pas cherché toi-même, tu ne l’installes pas.

2. Un vrai prompt système macOS ne te redemande pas ton mot de passe admin sans raison claire. Une app fraîchement lancée qui réclame ton mot de passe login « pour continuer », sans installation légitime en cours, c’est un signal d’alerte, pas une formalité. Tu fermes, tu ne tapes rien.

3. Installe un pare-feu applicatif et laisse-le parler. Little Snitch ou LuLu te montrent les connexions sortantes inattendues, exactement le moment où un stealer part exfiltrer ton butin. C’est ta caméra de surveillance sur ce que le système fait dans ton dos.

À lire : Little Snitch vs LuLu, quel pare-feu sortant pour ton Mac

Et si tu as le moindre doute d’avoir exécuté un installeur douteux récemment, la marche à suivre existe déjà, elle est la même que pour les infostealers distribués par ingénierie sociale.

À lire : Google Ads et vrai chat Claude partagé vident tes credentials

Sources

Chat Control 1.0 : adopté par ceux qui ont voté contre

Mac Souverain — Sun, 12 Jul 2026 09:33:42 GMT

Le 9 juillet 2026, le Parlement européen a laissé passer la reconduction de Chat Control 1.0 (scanning VOLONTAIRE du CSAM, règlement UE 2021/1232). Pas par un vote pour : 314 voix contre, 276 pour, mais rejeter la position du Conseil exigeait 361 voix. La majorité a voté non, le texte passe quand même. Le chiffrement de bout en bout est explicitement exclu de ce texte. Le vrai combat, Chat Control 2.0 (CSAR), reprend en septembre.

Ce que tu dois surveiller

1. Le CSAR (Chat Control 2.0), le scanning OBLIGATOIRE potentiellement côté client sur l’E2E, qui repart en trilogue en septembre 2026. C’est le seul rendez-vous qui compte.

2. La méthode : un texte rejeté par la majorité des votants qui passe faute de majorité absolue pour le bloquer. Retiens le mécanisme, il resservira.

3. Les posts viraux qui prétendent que WhatsApp et Signal sont désormais scannés. C’est faux pour le 1.0, l’E2E en est exclu. Ne relaie pas la panique.

Ce qui s’est passé le 9 juillet

Le 9 juillet 2026, le Parlement européen a acté la reconduction de Chat Control 1.0, c’est-à-dire le règlement (UE) 2021/1232 : une dérogation à la directive ePrivacy qui autorise les fournisseurs à scanner volontairement les communications à la recherche de contenus pédocriminels (CSAM). Ce texte avait expiré le 3 avril 2026. Il est reconduit, en vigueur jusqu’au 3 avril 2028.

Le détail qui compte : il n’a pas été adopté par un vote pour. Le décompte est de 314 voix contre, 276 pour, 17 abstentions. La majorité des votants a dit non. Sauf que pour rejeter la position du Conseil, il fallait une majorité absolue de 361 voix, manquée de 47. Résultat : le texte passe faute de blocage. Patrick Breyer parle d’une farce démocratique, et sur ce point précis il est difficile de lui donner tort.

Deuxième détail, dénoncé par plusieurs eurodéputés : le dossier a été reprogrammé au tout début des vacances parlementaires, quand l’hémicycle est clairsemé. Un classique du calendrier, mais un classique efficace.

Débunk express

Trois contre-vérités tournent en boucle depuis le 9 juillet. Voici la réalité en face.

« Le Parlement a voté POUR Chat Control. » Faux. 314 ont voté contre, 276 pour : la majorité a voté non. Le texte passe parce que le seuil pour le bloquer, 361 voix, n’a pas été atteint, pas parce qu’il a été approuvé.

« WhatsApp, Signal, iMessage vont être scannés. » Faux. Un amendement Renew adopté le même jour exclut explicitement le chiffrement de bout en bout du champ de ce texte. Le 1.0 reste du scanning volontaire, hors E2E.

« C’est le grand Chat Control obligatoire qui vient de passer. » Faux. Le texte du 9 juillet, c’est le 1.0 volontaire. Le scanning obligatoire, potentiellement côté client sur l’E2E, c’est le CSAR (Chat Control 2.0), toujours en trilogue, reprise en septembre.

Deux textes, deux histoires. Le 1.0 est volontaire et exclut l’E2E. Le 2.0 est le vrai danger, et il n’est pas encore tranché.

Pourquoi ça te concerne

Sur ton Mac et ton iPhone, le 1.0 ne change rien aujourd’hui : ton iMessage, ton WhatsApp, ton Signal restent chiffrés de bout en bout, explicitement hors du périmètre de ce texte. Ne laisse personne te vendre une panique produit qui n’existe pas.

Sauf que ce texte ne se limite pas aux messageries. Il couvre aussi les emails, et là, la nuance change tout : un email classique (Gmail, Outlook, iCloud Mail) n’est pas chiffré de bout en bout. Il reste donc pleinement dans le champ du scan volontaire que le 1.0 prolonge.

Google et les autres peuvent scanner le contenu de tes mails à la recherche de CSAM, et l’exclusion E2E ne te protège pas, puisqu’il n’y a pas d’E2E à protéger. Seule une messagerie réellement chiffrée de bout en bout, comme Proton Mail, passe entre les mailles.

Mesure bien ce que cela veut dire. C’est comme si la Police lisait ton courrier alors que tu n’as rien à te reprocher. C’est digne de la STASI !

Le vrai risque porte un autre nom : le client-side scanning du CSAR 2.0. C’est le principe d’inspecter tes messages sur ton appareil, avant qu’ils soient chiffrés. La crypto n’est pas cassée, elle est vidée de son sens : ton message est lu en clair sur ton téléphone avant de partir. Et ce point d’inspection, une fois posé, n’appartient plus jamais qu’aux « gentils ».

Ce n’est pas de la science-fiction côté Apple. En 2021, Apple a annoncé NeuralHash, un système de scan CSAM côté client sur iPhone, avant de l’abandonner en décembre 2022 sous la pression. Le code existe, la logique aussi.

Un CSAR contraignant, c’est exactement le levier qui rouvrirait ce dossier, cette fois par la loi et non par choix. La plainte du West Virginia contre Apple en février 2026 montre que la pression judiciaire sur le sujet ne retombe pas.

Ce que tu peux faire

Rien à installer, rien à corriger sur ton appareil : le 1.0 n’ouvre aucune faille produit. C’est un signal politique, et une leçon de méthode : un texte rejeté par la majorité des votants peut passer quand même quand le seuil de blocage n’est pas atteint. Retiens le mécanisme, parce qu’il resservira en septembre.

Le rendez-vous, c’est le CSAR à la reprise de septembre 2026. Cinq rounds de trilogue sans accord, le dernier le 29 juin, et la ligne de fracture reste le chiffrement.

Garde Signal en messagerie de repli, suis EDRi et Patrick Breyer pour l’issue réelle, et écris à ton eurodéputé avant que le 2.0 ne revienne sur la table. La pression publique a déjà déplacé des lignes sur ce dossier, elle peut recommencer.

Pour creuser : Chat Control 2.0, le mécanisme complet · NIS2 contre CSAR, quand l’UE se contredit · La convergence mondiale des textes anti-privacy

Wazuh 5.0 débarque, ton SIEM maison évolue

Mac Souverain — Thu, 02 Jul 2026 07:22:47 GMT

Wazuh 5.0 débarque en bêta publique et refond son architecture, Filebeat dégage, cluster par défaut, nouveau moteur. Si tu as monté ton SIEM avec notre série, ton install 4.x tourne toujours, la montée en 5.0 ne se fera pas à l’aveugle.

Ce que ça change pour toi

1. Repère ta version avec wazuh-control info, les 4.11 et récentes reçoivent encore des correctifs.

2. Snapshot ta VM et sauvegarde /var/ossec/etc/ avant toute tentative de passage en 5.0.

3. Attends une 5.0.x stable (5.0.1 ou 5.0.2) avant de migrer, on met la série SIEM à jour à ce moment-là, guide de migration inclus.

Si tu as monté ton SIEM maison en suivant l’épisode 2/7 de la série SIEM souverain, prépare-toi : Wazuh 5.0 arrive en bêta publique et casse plusieurs briques d’un coup. Pas de panique, mais bien regarder avant de mettre à jour à l’aveugle. Et on met la série d’articles SIEM à jour le moment venu.

Le fait

Wazuh vient de publier la bêta publique de sa version 5.0, avec une sortie stable estimée fin juin ou début juillet 2026. Ce n’est pas un simple bump de version, c’est une refonte architecturale.

Ce qui change, concrètement : Filebeat disparaît, remplacé par un indexer-connector natif intégré au manager. Chaque serveur Wazuh devient un nœud de cluster par défaut, même en install mono-serveur. Le vieux moteur analysisd, qui traitait les logs et déclenchait les règles, est remplacé par un nouveau moteur. La détection de vulnérabilités bascule côté Wazuh Indexer, centralisée. Et le RBAC, la gestion fine des droits, est entièrement retravaillé.

Conséquence directe pour MacSouverain : l’épisode 2/7 de la série SIEM souverain, qui documente l’architecture 4.x pas à pas, sera partiellement obsolète dès la sortie de 5.0. On met la série à jour quand la 5.0 sera stable, pas avant.

Pourquoi ça compte pour toi

Si tu as suivi le guide épisode 2/7 de la série SIEM souverain pour monter ton propre SIEM à la maison, tu tournes probablement sur une 4.x. Bonne nouvelle, ton install continue de marcher, personne ne va te débrancher. Mauvaise nouvelle, la mise à jour vers 5.0 ne sera pas un simple apt upgrade sans lire la doc. Filebeat qui saute, ça veut dire que ton pipeline de logs change de plomberie. Le cluster par défaut, ça change la conf initiale même si tu restes sur une seule machine.

Traduction pratique : si tu comptais mettre à jour dès la sortie, prends une heure pour lire les release notes et fais un snapshot avant. Si tu es sur une install stable qui te sert au quotidien, attends une ou deux versions correctives, laisse les early adopters essuyer les plâtres.

Ce que ça change pour toi

1. Note quelle version de Wazuh tu tournes actuellement. Sur ton manager, wazuh-control info ou consulte le dashboard. Si tu es en 4.11 ou récent, tu es sur la branche qui reçoit encore des correctifs.

2. Avant toute tentative de mise à jour vers 5.0, snapshot ta VM ou sauvegarde ta config /var/ossec/etc/ et l’état de ton Wazuh Indexer. Un rollback propre te sauve la mise si le nouveau moteur ne digère pas tes règles custom.

3. Attends la version stable 5.0.x (au moins 5.0.1 ou 5.0.2) avant de migrer une install en production perso. La bêta, c’est pour tester sur une VM jetable, pas sur celle qui surveille ton réseau tous les jours. A surveiller : la publication officielle du guide de migration 4.x → 5.0 par Wazuh, et la refonte à venir de l’épisode 2/7 de la série SIEM souverain côté MacSouverain.

Sources

Wazuh 5.0 Public Beta Discussion (GitHub)

Chat Control : l'UE joue le sort de ton chiffrement

Mac Souverain — Wed, 01 Jul 2026 13:46:25 GMT

Le 29 juin, l’UE a tenu le 5e et dernier trilogue sur Chat Control 2.0 (CSAR). Enjeu : un scanning de masse de tes messages privés avant chiffrement, contre un Parlement qui défend l’E2E. L’issue se joue maintenant et décidera si WhatsApp, Signal & iMessage restent réellement chiffrés en Europe.

Ce que tu dois surveiller

1. La publication de l’accord (ou de l’échec) du trilogue et la présence, ou non, d’une exemption explicite du chiffrement de bout en bout.

2. Le retour de « Chat Control 1.0 » (scanning volontaire prolongé) que Metsola menace de rouvrir en parallèle : un cheval de Troie si le 2.0 cale.

3. La vérification d’âge obligatoire, qui tue l’anonymat en ligne bien au-delà de la lutte contre le CSAM.

Ce qui s’est passé le 29 juin

Sous présidence chypriote, le Conseil de l’UE a réuni le 29 juin ce qui était annoncé comme le cinquième et dernier trilogue sur le règlement CSAR, le texte que tout le monde appelle « Chat Control 2.0 ». Objectif affiché de la présidence : arracher un accord politique avant la trêve estivale.

La ligne de fracture n’a pas bougé. D’un côté, un texte du Conseil qui codifie un scanning de masse des communications privées via des « ordres de détection », un dispositif que le propre service juridique du Conseil juge contraire à l’article 7 de la Charte des droits fondamentaux. De l’autre, un Parlement qui, le 26 mars 2026, a rejeté le scan de masse à une seule voix (307 contre 306) et s’accroche à la protection du chiffrement de bout en bout.

À l’heure où on écrit, aucune source officielle n’a publié le résultat de ce trilogue : ni accord, ni échec confirmé. La présidence chypriote pousse pour une adoption formelle en juillet, mais le blocage sur le chiffrement peut encore tout faire dérailler. C’est précisément ce silence qu’il faut surveiller de près dans les prochains jours.

Pourquoi ça te concerne

Le scanning « côté client » impose d’inspecter tes messages sur ton appareil, avant qu’ils ne soient chiffrés. La crypto de WhatsApp, Signal ou iMessage n’est pas cassée, elle est vidée de son sens : ton message est lu en clair sur ton téléphone avant de partir. Et ce point d’inspection ne reste jamais réservé aux « gentils », il est exploitable par n’importe quel attaquant qui met la main dessus.

S’ajoute la vérification d’âge obligatoire, qui exige d’associer une identité réelle à ton compte de messagerie. C’est la fin de l’anonymat par défaut, vendu sous prétexte de protection de l’enfance.

Ce que tu peux faire

Rien à installer aujourd’hui : c’est un signal politique, pas une faille produit. Mais garde Signal en messagerie de repli, surveille les positions de ton eurodéputé, et suis EDRi / Patrick Breyer pour l’issue réelle. Dès qu’elle sera publiée, on mettra à jour nos articles qui traitent le sujet.

Ta position fuite par le réseau, pas par ton iPhone

Mac Souverain — Wed, 17 Jun 2026 13:41:39 GMT

Le Citizen Lab a relié, dans son rapport « Bad Connection » d’avril 2026, du trafic de surveillance réel à des infrastructures d’opérateurs. Des sociétés commerciales localisent n’importe quel mobile via les failles d’interconnexion du réseau, SS7 en 2G/3G, Diameter en 4G, sans jamais toucher l’appareil. Rien à patcher sur ton iPhone : le trou est dans le réseau, pas dans iOS.

Ce que tu dois surveiller

1. Aucun réglage ne bloque ce vecteur : ni mode Isolement, ni eSIM, ni Signal, ni couper la data. La seule parade, te rendre injoignable en mode avion ou téléphone éteint. Ne te crois pas couvert parce que tu chiffres tes messages.

2. Passe tes codes de connexion en 2FA par application, pas par SMS. Ça ne stoppe pas la géoloc, mais ça ferme l’interception des codes via le même réseau.

3. La vraie défense est structurelle, côté opérateurs et régulateurs. NIS2 et ENISA cadrent le risque, mais aucune obligation technique forte n’impose encore de sécuriser l’interconnexion.

Le Citizen Lab a publié en avril 2026 un rapport qui relie pour la première fois du trafic de surveillance réel à des infrastructures d’opérateurs identifiées. Le principe est connu depuis dix ans, mais le constat reste dérangeant : des sociétés commerciales localisent n’importe quel mobile dans le monde sans jamais toucher à l’appareil. Ton iPhone n’y est pour rien, et c’est précisément le problème.

Le fait

Le rapport s’appelle « Bad Connection ». Il documente des acteurs qui traquent des téléphones à travers une vingtaine de pays, plus de 1700 attaques pour l’un d’eux, dont la quasi-totalité dédiée à la géolocalisation. La cible décrite est un « VVIP » au Moyen-Orient, mais le profil habituel de ce marché est connu : journalistes, opposants, responsables politiques.

La mécanique exploite les protocoles qui font dialoguer les opérateurs entre eux quand tu pars à l’étranger ou que tu changes d’antenne. Ils ont été conçus à une époque où une poignée d’opérateurs nationaux se faisaient mutuellement confiance. Aujourd’hui ils sont des milliers, et cette confiance implicite est devenue une porte d’entrée. Trois vecteurs cohabitent : SS7 sur la 2G et la 3G, Diameter sur la 4G, et une variante baptisée SIMjacker qui passe par un SMS silencieux exécuté sur ta carte SIM. Le Citizen Lab est catégorique : ce ne sont pas des bugs logiciels, mais des défauts inhérents à la conception même des télécoms mondiales.

Une précision qui change tout : en général, ce n’est pas ton opérateur qui vend ta position. Il faut distinguer deux marchés. Le premier existe bel et bien : aux États-Unis, les grands opérateurs ont revendu la localisation de leurs abonnés à des courtiers de données, ce qui a valu près de 200 millions de dollars d’amendes de la FCC en 2024.

Le second, le cœur de ce radar, est différent : des sociétés de surveillance comme Rayzone, Circles ou Cognyte exploitent les failles d’interconnexion en louant des points d’accès légitimes au réseau mondial, le « Global Title leasing », souvent via un petit opérateur complice. Elles interrogent à distance le réseau de ta cible, sans son consentement ni celui de son opérateur.

Pourquoi ça compte pour toi

Voilà l’angle qui dérange. Tu peux chiffrer tes messages, durcir ton Mac, fermer chaque réglage de macOS un par un, ta position physique continue de transiter par une infrastructure que tu ne maîtrises pas et sur laquelle Apple n’a aucune prise. Rien à patcher de ce côté, parce que ce n’est pas un trou dans iOS. C’est l’architecture du réseau lui-même.

Du coup, la plupart des gestes barrière auxquels tu penses ne servent à rien contre ce vecteur précis, et il vaut mieux le savoir que se rassurer à bon compte. Le mode Isolement durcit ton iPhone, il ne touche pas une requête SS7 qui se passe dans le réseau. L’eSIM change le format de la carte, pas le protocole : tant qu’il y a un numéro joignable, l’exposition est identique.

Signal protège le contenu de tes messages, pas les métadonnées de signalisation qui révèlent où tu es. Couper la data ou le GPS ne change rien non plus, la traque utilise l’identifiant de cellule, pas ta puce. La seule parade individuelle réellement efficace, c’est le mode avion ou le téléphone éteint, autant dire inapplicable au quotidien.

Deux nuances pour ne pas te vendre de faux remparts. La 2FA par application a une vraie utilité, mais contre un autre risque : l’interception de tes codes par SMS, pas la géolocalisation. Un numéro ou une eSIM dédiés réduisent le lien entre ta position et ton identité réelle, sans rendre ce numéro moins traçable.

La vraie défense, elle, est structurelle. Elle se joue chez les opérateurs et les régulateurs, avec des pare-feu de signalisation que la GSMA documente dans son guide FS.11. Ta sécurité ici ne dépend pas de toi, mais d’une infrastructure et d’un cadre légal que tu ne contrôles pas.

Soyons clairs sur le risque réel : pour un particulier lambda, la probabilité d’être ciblé reste faible. Ce sujet compte par ce qu’il révèle, pas par une menace imminente sur ta personne. La souveraineté numérique ne s’arrête pas au bord de ton appareil : tant que tu as une carte SIM, ta position circule dans un réseau mondial faiblement contraint.

Ce que tu fais maintenant

1. Recalibre tes attentes, c’est le geste le plus utile ici. Garde Signal, le mode Isolement et tes bons réflexes, ils protègent le contenu et l’appareil, mais ne crois pas qu’ils te rendent invisible sur le réseau. Confondre les deux, c’est le piège.

2. Pour les codes de connexion, abandonne le SMS et passe à la 2FA par application ou clé matérielle. Ça ne te protège pas de la géoloc, mais ça ferme l’interception des codes via le même réseau, et c’est un risque concret pour tes comptes.

3. Si tu as un profil réellement exposé, journaliste, opposant politique ou avocat sur dossier sensible, le seul levier individuel sérieux est la discipline physique : en mode avion ou téléphone éteint, ton appareil n’est plus inscrit au réseau, il n’y a rien à localiser. Tu ne redeviens traçable qu’à la réinscription. Un numéro dédié cloisonne ton identité, mais reste traçable de la même façon.

4. Pour le reste, le vrai chantier n’est pas sur ton bureau. Suis le sujet côté régulateur : NIS2 et ENISA posent un cadre, mais aucune obligation technique forte n’impose encore aux opérateurs de fermer ces failles. C’est là que la pression doit porter.

Sources

Bad Connection, Uncovering Global Telecom Exploitation by Covert Surveillance Actors, Citizen Lab, avril 2026 (source primaire)
Signalling Security in Telecom SS7/Diameter/5G, ENISA (protocoles jugés fondamentalement faillis, recommandations UE)
FS.11 SS7 Interconnect Security Monitoring and Firewall Guidelines, GSMA (la référence pare-feu de signalisation, autorégulation industrielle)
Hacking Your Phone, 60 Minutes, CBS, 2016 (écoute du représentant Ted Lieu via SS7, démonstration sur un élu)
FCC Fines Major U.S. Wireless Carriers for Selling Customer Location Data, Krebs on Security, 2024 (le marché distinct des courtiers de données, 200M USD d’amendes)

Des termes techniques ? Consulte le glossaire.

Siri AI bloqué dans l'UE, confidentialité signée Google

Mac Souverain — Wed, 10 Jun 2026 13:32:51 GMT

Apple lance Siri AI à la WWDC, mais le bloque sur iPhone et iPad dans l’UE au nom du DMA. La Commission répond que c’est le choix d’Apple, pas une obligation. Cerise sur le gâteau, cette plateforme « confidentielle » s’appuie en partie sur Google Gemini.

Ce que ça change pour toi

1. En Europe, pas de Siri AI sur iPhone ni iPad. Mais sans assistant IA cloud, ton appareil est plus sûr : tu perds une fonction, pas une protection.

2. Pour le sensible, reste local et active Advanced Data Protection sur iCloud. Pour l’email chiffré, Proton Mail, pas iCloud Mail.

3. Pose-toi la vraie question : confier ton assistant le plus intime à une chaîne Apple plus Google, c’est passer d’une garantie technique à une promesse contractuelle.

Apple a dévoilé Siri AI à la WWDC, sa nouvelle plateforme d’assistant vocal. Deux détails coincent : elle est construite en partie sur Google Gemini, et elle ne sortira pas sur iPhone ni iPad dans l’Union européenne. La confidentialité, version Cupertino, devient un argument de blocage.

Le fait

Le 8 juin 2026, à la WWDC, Apple a présenté Siri AI, la refonte tant attendue de son assistant vocal et la fondation annoncée de sa prochaine génération de produits, y compris de futurs appareils portables. Le cœur de la plateforme repose sur une architecture hybride : les tâches locales tournent sur les modèles maison d’Apple, mais l’intelligence cloud s’appuie sur un modèle Gemini sur-mesure de Google, pour un contrat estimé autour d’un milliard de dollars par an selon plusieurs sources de presse.

Le hic, c’est la géographie. Apple a annoncé que Siri AI ne sera pas disponible sur iPhone ni iPad dans l’Union européenne avec iOS 27 et iPadOS 27. Les utilisateurs européens y auront accès sur macOS 27 et visionOS 27, mais ni sur iPhone, ni sur iPad, ni sur l’Apple Watch, watchOS 27 dépendant d’un iPhone appairé doté de Siri AI. Apple invoque le Digital Markets Act (DMA) et ses exigences d’interopérabilité, affirmant que les régulateurs ont rejeté ses propositions de mise en conformité, dont un cadre baptisé Trusted System Agent censé ouvrir l’accès aux assistants concurrents tout en préservant ses standards de sécurité.

La Commission conteste le cadrage. Pour son porte-parole Thomas Regnier, la décision de ne pas déployer Siri AI dans l’UE est « celle d’Apple et d’Apple seule », rien dans le DMA n’empêchant le lancement d’un nouveau produit. Le marché, lui, a tranché à sa manière : l’action Apple a reculé d’environ 2 % le jour de l’annonce, puis de 3 % le lendemain. Note de prudence : iOS 27 et iPadOS 27 sont à ce stade des annonces, pas des builds stables. Le calendrier de sortie comme le périmètre du blocage peuvent encore bouger.

Pourquoi ça compte pour toi

Si tu es en Europe, le message est clair : ton iPhone et ton iPad n’auront pas la fonction phare des prochains OS. Avant de pester contre Bruxelles, regarde ce qui se joue vraiment. Apple présente la confidentialité comme la raison pour laquelle elle ne peut pas se plier aux demandes d’interopérabilité.

La Commission répond que personne n’oblige Apple à brider son produit. Les deux versions ne sont pas symétriques, et le site officiel n’a pas le monopole de la vérité ici, mais une chose est sûre : la confidentialité est devenue un argument de négociation autant qu’une promesse technique.

L’ironie mérite qu’on s’y arrête. Apple vend Siri AI comme respectueux de ta vie privée, tout en confiant le traitement cloud à Google, c’est-à-dire à l’entreprise dont le modèle économique repose sur l’exploitation des données. Apple jure que son architecture cloisonne tout via son Private Cloud Compute, que Google ne voit rien, que les requêtes sont anonymisées. C’est plausible sur le papier, et Apple a un historique sérieux sur le sujet. Mais tu passes d’une promesse vérifiable, le tout-sur-l’appareil, à une promesse contractuelle, le fait que ton partenaire et son sous-traitant tiennent parole. Ce n’est pas le même niveau de garantie.

Le fond du dossier dépasse Siri. On assiste à une fragmentation des écosystèmes numériques par juridiction. Une même version d’iOS n’offrira pas les mêmes fonctions à Paris, New York ou Pékin. La souveraineté, pour toi utilisateur, ne se joue plus seulement dans le chiffrement, mais dans le fait que ton appareil dépend désormais d’un bras de fer entre un industriel américain, un régulateur européen et un fournisseur d’IA tiers.

Ce que ça change pour toi

1. Ne confonds pas absence de Siri AI et perte de confidentialité. Ton iPhone sans assistant IA cloud reste parfaitement fonctionnel, et il est plus sûr. Le « manque » est une fonction, pas une protection en moins.

2. Pour les requêtes sensibles, garde le réflexe local. Active Advanced Data Protection sur iCloud (Réglages > Apple Account > iCloud > Protection avancée des données) pour chiffrer tes backups de bout en bout. Rappel : l’ADP ne couvre ni iCloud Mail, ni Contacts, ni Calendrier. Pour l’email réellement chiffré, c’est Proton Mail ou Tuta, par exemple.

3. Surveille la suite, sans t’y noyer. Le périmètre du blocage et le calendrier UE bougeront. Ce qui compte n’est pas la date de sortie, mais la question de fond : es-tu prêt à confier ton assistant le plus intime à une chaîne Apple plus Google, sur une promesse contractuelle ?

Sources

Certificat OpenAI compromis, mets à jour ChatGPT Mac avant le 12 juin

Mac Souverain — Sat, 06 Jun 2026 07:58:44 GMT

Si tu utilises ChatGPT, Codex ou Atlas en app native sur ton Mac, tu as jusqu’au 12 juin 2026 pour mettre à jour. Le certificat de signature d’OpenAI a été compromis via une attaque supply-chain sur npm. Au-delà, ton app refuse de démarrer.

Ce que tu dois faire

1. Ouvre ChatGPT.app, Paramètres → À propos. Mise à jour si version ≤ 1.2026.125. Idem Codex App (≤ 26.506.31421), Codex CLI (≤ 0.130.0), Atlas (≤ 1.2026.119.1).

2. Téléchargement officiel uniquement, chatgpt.com/download ou App Store. Pas de miroir, pas de lien partagé.

3. iOS, Windows, Android, rien à faire, OpenAI re-signe côté serveur. Mac uniquement.

Tu utilises ChatGPT, Codex ou Atlas en app native sur ton Mac. Le 12 juin, dans quelques jours, ces apps refusent de démarrer si tu n’as pas mis à jour. Pas un bug, une révocation de certificat suite à une attaque supply-chain. Voilà ce qu’il s’est passé et ce que tu fais.

Le fait

Le 11 mai 2026, en six minutes, un collectif baptisé TeamPCP publie 84 versions piégées de 42 paquets @tanstack/* sur npm. Deux postes salariés d’OpenAI consomment l’un de ces paquets le soir même. Le malware embarqué, Mini Shai-Hulud, exfiltre des credentials qui ouvrent l’accès à des dépôts internes contenant les outils de signature de code OpenAI. Pas la production, pas les conversations utilisateurs, pas les modèles. Les clés qui servent à prouver à macOS qu’une app vient bien d’OpenAI.

OpenAI a communiqué publiquement le 13 mai 2026. Le certificat compromis sera révoqué le 12 juin 2026. Côté Apple, ça veut dire que Gatekeeper et la notarisation refuseront toute version signée avec l’ancien certificat. Concrètement, les versions affectées,

ChatGPT Desktop ≤ 1.2026.125
Codex App ≤ 26.506.31421
Codex CLI ≤ 0.130.0
Atlas (navigateur OpenAI) ≤ 1.2026.119.1

ne se lanceront plus à partir du 12 juin. iOS et Windows, eux, sont re-signés côté serveur. Pas d’action utilisateur.

Le code source du worm a été rendu public par TeamPCP le 12 mai, avec un défi criminel de 1 000 dollars sur BreachForums pour la plus grosse attaque supply-chain réalisée avec leur outil. Pas une bug bounty défensive, une prime offensive. La référence CVE est CVE-2026-45321.

Pourquoi ça compte pour toi

Tu n’as rien fait de mal et tu dois quand même agir. C’est l’essence d’une attaque supply-chain. Ton hygiène utilisateur peut être impeccable, si l’éditeur de l’app que tu as installée se fait compromettre quatre étages plus haut, sur une dépendance npm que tu ne sauras jamais nommer, tu hérites du problème. Le certificat compromis, le mécanisme de signature révoqué, l’app qui ne démarre plus, tout ça arrive chez toi sans que tu aies cliqué quoi que ce soit.

La bonne nouvelle, c’est que le mécanisme de révocation fonctionne. Gatekeeper et la notarisation Apple sont précisément conçus pour ça : empêcher un attaquant d’utiliser un certificat volé pour signer du malware en aval. OpenAI fait son travail en révoquant proprement. Apple fait son travail en bloquant. Le système tient. OpenAI a communiqué publiquement dès la détection, dates précises, versions explicites, sans détour. Ce n’est pas la norme du secteur.

La mauvaise nouvelle, c’est que ça pose une question doctrinale qui dépasse OpenAI. Une app native sur ton Mac, c’est du code qui tourne en local avec un certificat de confiance, un canal de mise à jour automatique, des permissions système, et tout un réseau de dépendances en amont sur lequel tu n’as aucune visibilité. Quand l’une de ces dépendances se fait piéger, et ça arrive à toutes, le problème descend jusqu’à toi.

Ce que tu fais maintenant

1. Ouvre ChatGPT.app, va dans Paramètres → À propos. Si tu es en 1.2026.125 ou antérieure, lance la mise à jour. Si rien ne s’affiche, télécharge directement depuis chatgpt.com/download. Jamais un miroir, jamais un lien partagé.

2. Si tu utilises Codex App ou Codex CLI, même vérification. CLI : codex --version puis npm update -g @openai/codex ou réinstall propre. Pour Atlas, mise à jour intégrée.

3. Vérifie que macOS est à jour, Gatekeeper renforcé sur Sequoia 15.x et Sonoma 14.7+. Les anciennes versions sont plus laxistes sur la vérification de notarisation au lancement.

4. Profite du créneau pour te poser la question doctrinale : qu’est-ce que l’app ChatGPT native t’apporte vraiment que chatgpt.com dans Safari ne t’apporte pas ? Dictée système, raccourcis clavier, intégration spotlight, OK. Si tu ne te sers d’aucun des trois, le navigateur réduit ta surface d’attaque. Pas de certificat de signature à gérer, pas de mise à jour silencieuse, pas de code persistant en local. Le réflexe vaut pour Claude Desktop, Perplexity, Mistral Le Chat et toutes les apps IA tierces que tu as installées sans trop savoir pourquoi. Une app native sur ton Mac, c’est une dette de sécurité. Parfois justifiée, parfois pas.

À lire aussi, Anthropic MCP, faille de design qui ouvre RCE. Même logique, code IA tiers qui descend en exécution locale dangereuse.

Sources

Stalkerware domestique, le malware du conjoint jaloux

Mac Souverain — Tue, 26 May 2026 17:09:58 GMT

Le stalkerware grand public (Spyzie, Cocospy, Spyic, mSpy) fait plus de trois millions de victimes sur la seule famille Cocospy/Spyic/Spyzie. Trente à soixante-dix dollars par mois, opérateurs Chine. Sur iPhone, ton conjoint connaît ton Apple ID et siphonne iCloud depuis le web. Plus rarement, profil MDM camouflé installé en deux minutes par un proche. Sur Android, app planquée. Modules premium : suivi GPS temps réel et activation micro à distance. La victime ne cherche jamais le mot « stalkerware ». Elle ne sait même pas que ça existe.

Ce que tu dois faire

1. Vérifie Réglages, Général, VPN et gestion des appareils. Tout profil que tu n’as pas posé toi-même, surtout aux noms vagues type « iOS Update », tu supprimes. Vérifie Temps d’écran, désactive le mot de passe que tu n’as pas mis.

2. Change ton mot de passe Apple ID, active la double authentification, sors les appareils inconnus de ta liste, active Protection avancée des données pour basculer tes sauvegardes iCloud en E2EE.

3. Bascule sur Signal pour les messages sensibles, Bitwarden ou KeePassXC pour les mots de passe, jamais un trousseau partagé.

4. Si tu suspectes une installation active, agis depuis un autre appareil et un autre réseau. La Coalition Against Stalkerware liste des ressources par pays.

Le 26 mai, Joseph Cox de 404 Media interviewe Zack Whittaker, le journaliste qui a sorti à peu près tous les leaks stalkerware grand public depuis cinq ans. Verdict, ce n’est pas un marché de niche, c’est un marché de masse. Centaines de milliers de victimes sur un seul réseau. Cible iPhone et Android. Installation par ton conjoint, ton ex, ton colocataire, en deux minutes pendant que tu prends ta douche.

Le fait

Le stalkerware, c’est du spyware vendu à monsieur et madame tout le monde. Pas Pegasus, pas Predator, pas le calibre de spyware mercenaire que Citizen Lab traque depuis Toronto. Le truc qu’on installe sur le téléphone de sa copine pour lire ses messages, écouter ses appels, suivre sa position et activer son micro à distance. Les marques s’appellent Spyzie, Cocospy, Spyic, mSpy, TheTruthSpy.

Whittaker en fait des leaks à répétition depuis 2021. La dernière vague, février 2025, a exposé 518 000 clients de Spyzie dont au moins 4 900 iPhones compromis, et 2,65 millions d’adresses email sur le réseau jumeau Cocospy + Spyic. Plus de trois millions de victimes cumulées sur cette seule famille d’opérateurs.

L’abonnement coûte trente à soixante-dix dollars par mois pour la formule standard, plus si tu prends les modules premium genre micro et caméra. Les sociétés vivent dans des holdings offshore, Chypre, Îles Vierges britanniques, ou directement en Chine. Cocospy, Spyic et Spyzie sont la même équipe, tracée par Whittaker jusqu’à un même opérateur chinois.

mSpy joue un modèle économique identique mais sous une enseigne distincte, héritage Chypre-Ukraine. Quand un leak les expose, ils ferment et rouvrent sous un nouveau nom. Mai 2025, Cocospy disparaît, revient en quelques semaines. Le marché total tourne autour de cent quarante-cinq millions de dollars par an d’après Future Market Insights.

Côté iPhone, la méthode dominante n’a même pas besoin de toucher au téléphone. Ton conjoint connaît ton mot de passe Apple ID, parce que tu le partages, parce qu’il a vu ton iPhone se déverrouiller cent fois, ou parce que vous utilisez le même depuis quinze ans. Il se logue à iCloud depuis un navigateur, télécharge tes sauvegardes, et l’app stalkerware côté serveur fait le tri. Pas d’app sur ton téléphone, rien à détecter en local. C’est la mécanique exacte documentée par Whittaker pour Cocospy, Spyic et Spyzie en 2025.

Variante plus rare mais plus complète : un profil de configuration MDM, le mécanisme conçu à la base pour gérer les flottes d’entreprise. Le proche installe l’app de stalkerware via Apple Configurator sur son Mac, en supervisant ton téléphone avec un câble Lightning ou USB-C. Le profil est marqué removalDisallowed, baptisé d’un nom anodin du genre « iOS Update » ou « Battery Optimizer ». Un mot de passe Temps d’écran que tu ne connais pas masque l’entrée « Gestion d’appareils » dans les Réglages. Tu ne vois rien. Côté Android, c’est l’app camouflée en outil système, planquée derrière un nom générique, avec accessibilité activée pour tout lire à ta place.

Pourquoi ça compte pour toi

C’est ici que la couverture habituelle de la presse cybersec décroche. On parle beaucoup des mercenaires, NSO, Intellexa, Paragon, les milliards d’euros et les cibles diplomatiques. Mais le danger statistique pour un particulier, ce n’est pas un État qui te surveille, c’est ton ex qui te traque. Les États y mettent leur part eux aussi, à pousser pour le contrôle de masse côté législatif comme je l’ai démonté dans Six mois et dix-neuf textes mondiaux, la terrible convergence, mais la fréquence brute de victimes côté domestique écrase tout.

Whittaker répète depuis cinq ans que le stalkerware domestique fait infiniment plus de victimes que tous les spywares mercenaires réunis. La presse l’ignore parce que c’est sale, intime, et que ça n’a pas l’aura géopolitique de Pegasus.

L’asymétrie d’information est totale. L’acheteur tombe sur ces produits en trois clics : faux comparatifs « Top 10 spy apps » dont le site appartient au vendeur, SEO sur les requêtes de jaloux, Reddit avec des comptes affiliés, TikTok au format « POV j’ai pécho mon mec », Google Ads détournés sur « Find My iPhone » ou « family locator ».

Façade marketing « contrôle parental enfants » qui pivote très vite sur « monitor your spouse ». La victime potentielle, elle, ne cherche jamais le mot « stalkerware ». Elle ne sait même pas que ça existe. C’est la définition même d’une menace qu’on ne voit pas venir.

Tu es exactement la cible. Couple avec iPhone et Mac, écosystème Apple intégré, partage iCloud familial, mots de passe communs « parce qu’on se fait confiance ». Le jour où la confiance se fissure, le siphonnage tient en quelques clics depuis un navigateur, ou l’installation MDM en deux minutes pendant que tu fais une course. Et tu ne le sauras qu’en lisant cet article.

Ce que tu fais maintenant

1. Vérifie ton iPhone, profil de configuration et Temps d’écran.
Réglages, Général, VPN et gestion des appareils. Si tu vois un profil que tu n’as pas installé toi-même, surtout avec un nom vague genre « iOS Update », « Battery Saver », « Profile Service », tu désinstalles. Puis Réglages, Temps d’écran. Si un mot de passe est actif et que ce n’est pas toi qui l’as mis, tu désactives via ton Apple ID. Ce mot de passe sert souvent à masquer l’entrée VPN et gestion des appareils. Si le bouton de suppression du profil est grisé ou si le profil revient après un Effacer contenu et réglages, c’est qu’il est marqué removalDisallowed avec supervision DEP active : passage Apple Store nécessaire pour casser la supervision côté serveur Apple. Référence Apple : supprimer un profil de configuration.

2. Reprends le contrôle de tes comptes critiques.
Change immédiatement ton mot de passe Apple ID et active la vérification en deux étapes avec un numéro que ton entourage proche ne contrôle pas. Vérifie la liste des appareils connectés à ton compte Apple ID dans Réglages, ton nom, en haut. Tout appareil que tu ne reconnais pas, tu le supprimes. Active Protection avancée des données iCloud pour passer tes sauvegardes en chiffrement de bout en bout, l’exfiltration discrète depuis le web devient inopérante.

3. Bascule sur des outils E2EE pour ce qui compte.
Messages sensibles sur Signal, pas iMessage. Mots de passe dans un gestionnaire à toi seul, Bitwarden auto-hébergé ou KeePassXC en fichier local, pas un trousseau Apple partagé avec quelqu’un. Backups locaux chiffrés sur disque externe, pas seulement iCloud.

4. Si tu suspectes une installation active, sors du périmètre physique avant d’agir.
Le stalkerware avec micro et GPS te trahit en temps réel. Si tu veux contacter un service d’aide spécialisé sans alerter la personne qui t’espionne, fais-le depuis un appareil et un réseau qui ne sont pas surveillés. La Coalition Against Stalkerware liste des ressources par pays et un kit de réponse pour les victimes.

Sources

Millions of people are installing malware on their partner’s phones, with Zack Whittaker, 404 Media, 26/05/2026 (source primaire)
Spyzie stalkerware spying on thousands of Android and iPhone users, TechCrunch, 27/02/2025 (enquête Whittaker, 518k clients + 4 900 iPhones)
Cocospy and Spyic exposing phone data of millions of people, TechCrunch, 20/02/2025 (architecture du marché, lien 711.icu Chine)
Cocospy stalkerware apps go offline after data breach, TechCrunch, 19/05/2025 (pattern rebranding post-leak)
Stalkerware apps escape Google’s ad ban, TechCrunch, 11/08/2020 (contournement Google Ads)
Coalition Against Stalkerware, ressources victimes

Des termes techniques ? Consulte le glossaire.

Le régulateur cyber US a laissé fuiter ses clefs AWS six mois

Mac Souverain — Tue, 26 May 2026 13:39:33 GMT

CISA, l’agence cyber fédérale américaine, vient de découvrir qu’un de ses sous-traitants avait laissé pendant six mois un dépôt GitHub public bourré de clefs admin AWS GovCloud, tokens, mots de passe en clair. Détection externe par GitGuardian, pas en interne. Les clefs sont restées valides 48 h après le retrait du repo. Si le régulateur cyber fédéral ne sait même pas garder ses propres secrets, tu te demandes comment toi tu le pourrais ? Je t’explique ça !

Ce que tu dois faire

1. Inventorie ce que tu confies aujourd’hui à un cloud tiers, et pour chaque ligne demande-toi qui a la clef de déchiffrement. Le chiffrement at-rest avec les clés coté serveur égal zéro.

2. Choisis tes fournisseurs cloud sur un seul critère : chiffrement bout-en-bout, clef côté client (Proton, Tuta, Mullvad côté UE).

3. Ce qui se passe chez toi reste chez toi : sauvegardes sur disque externe chiffré APFS, double exemplaire offsite chiffré.

CISA, l’agence cyber fédérale américaine, vient de découvrir que son propre sous-traitant Nightwing avait laissé traîner pendant six mois un dépôt GitHub public bourré de clefs admin AWS GovCloud. Personne chez eux ne s’en est aperçu. C’est GitGuardian, depuis l’extérieur, qui a tiré la sonnette.

Le fait

Le 22 mai 2026, Brian Krebs publie l’enquête. Un salarié de Nightwing, sous-traitant historique de la CISA basé à Dulles en Virginie, a créé le 13 novembre 2025 un dépôt GitHub baptisé sobrement « Private-CISA ». Le mot « Private » dans le nom, le réglage public dans les paramètres. Le repo est resté en ligne, accessible à n’importe qui, jusqu’à mi-mai 2026. Six mois.

À l’intérieur, du lourd. Trois jeux de clefs d’administration pour des comptes AWS GovCloud, l’environnement cloud d’Amazon dédié aux agences fédérales américaines, certifié FedRAMP High pour héberger des données sensibles non classifiées (CUI).

Des tokens d’accès, des clefs SSH, des logs internes, et des mots de passe en clair suivant le pattern « plateforme-année » que ton stagiaire de troisième n’oserait pas tenter. Plus quelques documents internes sur les processus de développement logiciel de l’agence. Ben autant dire presque rien quoi !

Et la détection ? Ni interne CISA, ni audit Nightwing. C’est Guillaume Valadon, chercheur chez GitGuardian, qui scanne en continu les dépôts publics à la recherche de secrets oubliés, qui a trouvé le repo. Krebs et la boîte conseil Seralys ont notifié la CISA, qui a fait retirer le repo. Cerise : les clefs AWS sont restées valides 48 heures de plus après la suppression du dépôt. Le temps que l’agence se décide à les révoquer.

La déclaration officielle CISA tient en une phrase, on l’a déjà vue cent fois : « rien n’indique à ce stade que des données sensibles aient été compromises ». Nightwing renvoie sur CISA, CISA renvoie sur l’enquête. Krebs qualifie l’épisode d’« une des fuites de données gouvernementales les plus scandaleuses de l’histoire récente », et Bruce Schneier reprend la formule sans la nuancer.

Pourquoi ça compte pour toi

Tu n’es pas la CISA, tu n’as pas de sous-traitant Nightwing, tu n’utilises pas AWS GovCloud. Très bien. Maintenant, fais le calcul froid. L’agence qui dicte aux administrations US les règles de l’art en cybersécurité, qui publie les guides « secure by design » et les alertes CVE que toute l’industrie suit, vient de laisser ses propres clefs d’admin cloud en libre accès pendant six mois sans s’en rendre compte. Ni un sous-traitant douteux, ni un SaaS de troisième zone : le régulateur cyber lui-même.

L’argument est structurel, pas anecdotique. Quand tu confies tes secrets à un tiers, peu importe son sérieux affiché, tu hérites de toute sa chaîne de sous-traitance. CISA confie à Nightwing, Nightwing emploie quelqu’un, ce quelqu’un pousse sur GitHub. Le maillon faible compromet toute la chaîne en un instant. C’est déjà assez grave en soi. Mais si tu ajoutes à ça la flambée des menaces IA, tu obtiens potentiellement une porte d’entrée sur des systèmes plus confidentiels encore.

On va en revenir à toi. Tu as un repo GitHub perso ? Tu as déjà collé une clef d’API dans un commit pour « tester rapidement » avant d’oublier de la sortir de l’historique ? Tu utilises un gestionnaire de mots de passe cloud propriétaire pour des creds qui ouvrent ton infra ? Tu fais confiance à un éditeur SaaS sous juridiction étrangère pour garder tes secrets bien chiffrés chez lui ? Le radar CISA, c’est toi en miniature, mais avec moins de zéros sur les conséquences.

L’angle MacSouverain ne change pas d’un millimètre depuis le premier article. Tes secrets, tu les gardes chez toi. Sur ta machine, dans ton coffre local, sous ta clef. Tu peux déléguer la mise en page, la synchro, la sauvegarde chiffrée. Tu ne délègues pas la sécurité elle-même. Parce que le jour où ton fournisseur se vautre, et il se vautrera, tu veux que le rayon de l’explosion s’arrête à lui.

Ce que tu fais maintenant

1. Refais l’inventaire de ce que tu confies aujourd’hui à un tiers cloud.
Sors une feuille. Mots de passe, mails, agenda, contacts, fichiers, notes, sauvegardes photos. Pour chacun, écris où c’est stocké et qui a la clef de déchiffrement. Si la réponse à “qui a la clef” est “le fournisseur, ou un de ses sous-traitants”, tu es exactement dans la position de la CISA. Tu fais confiance à une chaîne dont tu ne contrôles pas un maillon. La CISA y croyait aussi.

2. Choisis tes fournisseurs cloud sur le critère “chiffré bout-en-bout, clef côté lecteur”.
Pour ce que tu dois forcément mettre dans le cloud (synchro multi-appareils, partage, sauvegarde), n’accepte que des fournisseurs qui ne peuvent pas lire ton contenu, même s’ils en avaient envie ou qu’on le leur demandait.

Côté mail et stockage : Proton ou Tuta, juridiction européenne, chiffrement bout-en-bout par défaut. Côté VPN : Mullvad ou Proton VPN, sans logs. La différence avec AWS, Google Drive, iCloud non-ADP : tu n’as pas à croire le fournisseur sur parole, l’architecture rend la fuite techniquement inexploitable.

3. Ce qui se passe chez toi reste chez toi.
Ce que tu peux garder local, garde-le local. Photos, archives, documents sensibles, sauvegardes : un disque externe chiffré APFS chez toi, plus un deuxième exemplaire chiffré que tu déposes chez un proche ou dans un coffre. Si tu as besoin de synchroniser des fichiers entre tes propres machines sans passer par un tiers, Syncthing fait du P2P direct entre tes appareils, point. Tu ne montes pas dans le cloud par défaut, tu y montes par choix réfléchi. La règle CISA s’applique en miniature à chacun : le jour où ton fournisseur se vautre, et il se vautrera, tu veux que le rayon de l’explosion s’arrête à lui, pas qu’il t’emporte avec.

Sources

CISA Admin Leaked AWS GovCloud Keys on GitHub, Krebs on Security, 22/05/2026 (source primaire)
CISA Security Leak, Schneier on Security, 22/05/2026 (reprise commentée)
GitGuardian, scanner de secrets dans les dépôts publics

Voir aussi

À lire : Le cloud, c’est l’ordinateur de quelqu’un d’autre

À lire : Gestionnaire de mots de passe sur Mac, comparatif

Des termes techniques ? Consulte le glossaire.

Cinq ans de défense mémoire M5 tombent en cinq jours

Mac Souverain — Tue, 19 May 2026 07:23:49 GMT

Trois chercheurs ont pris le contrôle total d’un Mac M5 en cinq jours, avec un coup de main de Mythos, l’IA spécialisée vulnérabilités d’Anthropic. Au passage, ils ont fait tomber MIE, la nouvelle protection mémoire qu’Apple a mis cinq ans à construire. Apple a déjà patché dans macOS Tahoe 26.5 le 11 mai. Premier exploit kernel public sur silicon M5, et démonstration grandeur nature qu’une IA peut accélérer ce genre de travail d’un facteur dix.

Ce que tu dois faire

1. Mets à jour macOS Tahoe 26.5 immédiatement (Préférences Système, Mise à jour de logiciels).

2. Active Lockdown Mode si tu es exposé professionnellement (journaliste, militant, cadre).

3. Évite tout binaire utilisateur non-vérifié. Gatekeeper strict, signatures sur Homebrew.

Le fait

Le 14 mai 2026, la boîte sécu Calif.io raconte comment elle a fait. Trois chercheurs (Bruce Dang, Dion Blazakis, Josh Maine) ont trouvé deux bugs dans le noyau de macOS, sur un Mac M5 flambant neuf. Ils ont enchaîné les deux. Résultat : un utilisateur normal, sans aucun privilège spécial, obtient les pleins pouvoirs sur la machine (root). Lecture de toute la mémoire, accès au Keychain, désactivation des protections. Tout.

Ce qui rend le truc historique, c’est ce qui est tombé au passage. La puce M5 embarque pour la première fois MIE (Memory Integrity Enforcement), une protection gravée directement dans le silicium. En clair : Apple a mis une étiquette sur chaque morceau de mémoire utilisé par le noyau, et le hardware refuse les manipulations frauduleuses. Cinq ans de travail. Présenté l’an dernier comme la nouvelle frontière de la sécurité Mac. Calif l’a contournée en cinq jours.

L’élément qui change la donne : Mythos. C’est le modèle frontier d’Anthropic, en accès restreint, dédié à la recherche en vulnérabilités. Les chercheurs précisent que Mythos n’a pas trouvé l’exploit tout seul. Bypasser MIE demande une expertise humaine pointue. Mais Mythos a repéré les bugs très vite, là où des humains seuls auraient passé des semaines à fouiller. Le travail qui prenait des mois prend désormais quelques jours.

Calif a remis les détails à Apple à Cupertino, en main propre. Apple a publié les correctifs dans macOS Tahoe 26.5 le 11 mai 2026. Les release notes créditent nommément « Calif.io in collaboration with Claude and Anthropic Research ». Le rapport technique complet (55 pages) reste sous embargo le temps que les patchs se déploient partout. Apple n’a pas commenté publiquement la chaîne d’exploit.

Pourquoi ça compte pour toi

Si tu as un Mac M5, ton hardware était vendu comme la frontière haute de la sécurité Apple. Cinq jours après la sortie de l’exploit, la frontière s’est déplacée. La protection matérielle ne suffit plus, un humain bien équipé peut la faire tomber en une semaine.

Bonne nouvelle : ce n’est pas une attaque à distance. Pour exploiter les bugs sur ton Mac, l’attaquant a besoin d’un pied dans la porte. Un binaire piégé que tu as lancé toi-même (Homebrew compromis, app récupérée hors App Store, fichier ouvert depuis un drive partagé douteux). À partir de là, par contre, il devient root et fait ce qu’il veut.

Le contexte plus large : Mythos enchaîne les coups d’éclat. Le 11 mai, le mainteneur de curl, Daniel Stenberg, confirmait qu’une faille de son code avait été trouvée par Mythos (Stenberg reste très critique sur le hype, mais reconnaît le résultat). Trois jours plus tard, Calif.io fait tomber MIE. La fenêtre entre « bug découvert » et « exploit fonctionnel » se referme. Apple, Google et Microsoft ont tous reconnu publiquement que les modèles IA dernière génération changent leur modèle de menace. On le voit maintenant en pratique.

Ce que tu fais maintenant

1. Mets à jour macOS Tahoe 26.5 maintenant, sur tous tes Macs (M5, M4, M3, M2, M1, Intel). La mise à jour couvre des bugs au-delà du seul M5. Préférences Système, Général, Mise à jour de logiciels. Si tu es resté sur macOS Sequoia 15.7.7 ou macOS Sonoma 14.8.7, ils ont reçu les correctifs cousins le même jour.

2. Active Lockdown Mode si tu es exposé professionnellement (journaliste, militant, cadre dirigeant, chercheur). Lockdown Mode coupe drastiquement la surface d’attaque sur la mémoire du noyau, exactement le type de bugs que Calif a utilisé. Préférences Système, Confidentialité et sécurité, Lockdown Mode. Attention, frictions à prévoir.

À lire : Lockdown Mode, pourquoi l’activer

3. Évite les binaires venus de nulle part. Pas d’app hors App Store sans audit, pas d’exécutable récupéré au hasard. Vérifie les signatures (GPG, SHA256) sur les outils sensibles, Homebrew compris. Active Gatekeeper strict dans Préférences Système, Confidentialité et sécurité, n’autoriser que l’App Store.

4. À suivre : les 55 pages techniques de Calif sortent une fois les patchs déployés partout. Le jour où le rapport est public, attends-toi à une vague de copies sur GitHub et à un scan complet du parc Mac par les équipes sécu. D’ici là, tu n’as rien à faire de plus que rester à jour.

Sources

Voir aussi

Anthropic Mythos : accès non autorisé identifié

Google Ads et vrai chat Claude partagé vident tes credentials

Mac Souverain — Thu, 14 May 2026 11:58:10 GMT

Une campagne malvertising détourne Google Ads et la fonction Share de Claude.ai pour pousser MacSync, infostealer macOS qui vide ton Trousseau via une simple commande Terminal collée par toi-même. Le pattern combine deux signaux de confiance (domaine officiel claude.ai + faux Support Apple) pour t’amener à exécuter du base64 sans te méfier.

Ce que tu dois faire

1. Ne paste jamais de commande Terminal dictée par un site, un chat IA ou un PDF “officiel”.

2. Active Little Snitch ou LuLu et surveille les sorties réseau inattendues.

3. Si déjà exécuté : déconnecte le Wi-Fi, change tous tes mots de passe browser, scanne avec KnockKnock.

Tu cherches “Claude mac download” sur Google. Le premier résultat sponsorisé pointe vers claude.ai, donc l’URL est légitime. Sauf que c’est un chat partagé Claude où un faux “Apple Support” te dicte la commande Terminal à coller. Tu colles, et MacSync part avec ton Trousseau, tes cookies et tes credentials browser.

Le fait

Berk Albayrak (Trendyol Group) et BleepingComputer documentent depuis le 10 mai 2026 une campagne de malvertising macOS active qui détourne deux mécanismes légitimes simultanément. D’abord Google Ads : une annonce sponsorisée pour “Claude mac download” pointe vers claude.ai, le domaine officiel d’Anthropic. Ensuite Claude.ai Share : la fonctionnalité de chats partagés sert à héberger un faux guide d’installation signé “Apple Support” qui dicte au lecteur de coller une commande encodée en base64 dans Terminal.

Le contenu de cette commande télécharge un shell script polymorphe depuis l’infrastructure attaquante, vérifie la disposition clavier (sortie immédiate si russe ou CIS), puis exécute le payload de seconde étape via osascript (le moteur AppleScript natif de macOS), pour livraison fileless. Le malware s’appelle MacSync, c’est un infostealer qui collecte les credentials et cookies des navigateurs, exfiltre le Trousseau macOS et fingerprint la victime (IP, hostname, version OS, langue clavier).

Les indicateurs de compromission publiés : payload customroofingcontractors[.]com/curl/ et bernasibutuwqu2[.]com/debug/loader.sh, exfil vers briskinternet[.]com. Les deux URL Claude.ai Share piégées identifiées sont claude[.]ai/share/9aac1046-a39e-4618-8265-f54c4be863f7 et claude[.]ai/share/eb2db455-1d47-4baf-8671-0a689e165902.

Te fais pas de bile, ici les liens sont désactivés. Mais Anthropic n’avait pas désactivé le mécanisme de share au moment de la publication BleepingComputer.

Pourquoi c’est un précédent

Deux choses, vraiment. D’abord, la fonctionnalité “shared chat” d’une plateforme IA grand public devient une surface de distribution malware. Les pages partagées Claude.ai sont publiques, indexables, et fait notable ici, pas modérées comme du contenu utilisateur classique. Elles héritent de la confiance visuelle du domaine Anthropic, et au moment des publis BleepingComputer / GBHackers, les deux URL share piégées étaient toujours en ligne.

Ensuite, le détournement de marque IA vient s’ajouter aux schémas malvertising connus (Homebrew, Loom, Notion, AnyDesk), Claude Code étant un outil dev récent, sa page officielle d’installation n’est pas encore un réflexe musculaire, ce qui laisse une fenêtre exploitable.

C’est aussi un cas d’école sur Google Ads, malgré les contrôles annoncés, des publicités usurpant des marques continuent de passer en exploitant l’URL d’affichage légitime tout en pointant vers une page piégée chez l’éditeur lui-même.

La validation domaine ne suffit pas quand l’éditeur héberge du contenu utilisateur. La responsabilité se répartit alors, Anthropic doit muscler la modération des shared chats (détection chats se présentant comme support officiel d’autres marques, bannière sur chats contenant des commandes shell, watermark visuel distinguant un chat partagé d’une page produit), Google doit aller au-delà du domaine d’affichage dans la validation Ads. Mais la dernière ligne reste toi, ne jamais coller aveuglément une commande shell.

Pourquoi ça compte pour toi

Le pattern social engineering ici est redoutable parce qu’il enchaîne deux signaux de confiance habituellement légitimes. Domaine claude.ai officiel, fonctionnalité Share native d’Anthropic, faux “Apple Support” dans un environnement IA réputé sérieux. Tu n’as pas affaire à un site obscur de download, tu cliques sur ce qui ressemble à de la doc officielle remontée par un moteur de recherche, c’est exactement le genre d’attaque qui passe sous le radar de la vigilance habituelle.

La cible est large. Pas seulement les développeurs (Homebrew, GitHub) mais tout utilisateur Mac curieux d’essayer Claude en application desktop. Le malware ne demande aucune élévation système, pas de 0day, pas de TCC à contourner, l’utilisateur fait tout le boulot lui-même en collant la commande. Et osascript étant un binaire Apple signé natif, il passe inaperçu de la plupart des EDR grand public et même de XProtect.

L’angle qui te concerne directement : c’est le retour offensif du Trousseau macOS comme cible privilégiée. Tu as appris à protéger le mot de passe utilisateur de ton Mac, à activer FileVault, à mettre Touch ID. Mais une commande Terminal lancée par toi-même contourne tout ça, parce que c’est toi-même qui ouvres la porte.

Ce que tu fais maintenant

1. Ne colle JAMAIS une commande Terminal dictée par un site web, un chat IA ou un PDF “support officiel”. Si tu dois installer un outil comme Claude desktop, va directement sur claude.ai/download en tapant l’URL toi-même, jamais via résultat sponsorisé Google. La règle universelle : si quelqu’un te demande de coller quoi que ce soit dans Terminal, c’est non.

2. Active Little Snitch ou LuLu en mode silencieux durci. Les deux loggent et bloquent les sorties réseau inattendues vers les IOC publiés (customroofingcontractors[.]com, bernasibutuwqu2[.]com, briskinternet[.]com). En cas de doute après une commande hâtive, regarde les connexions sortantes des minutes qui suivent.

3. Si tu as exécuté une commande douteuse récemment : déconnecte-toi du Wi-Fi immédiatement, change tous tes mots de passe browser (depuis un autre device propre), révoque tous tes tokens de sessions cloud actives (mail, sync, password manager), scanne avec KnockKnock ou ReiKey d’Objective-See, vérifie les launch agents dans ~/Library/LaunchAgents/.

4. Surveille ton Trousseau. security dump-keychain | grep -i password te dit ce qui est dedans. Pour la suite, migre tes mots de passe sensibles vers Apple Passwords ou Proton Pass, pas dans le Trousseau iCloud généraliste par défaut.

Sources

Voir aussi

Apple corrige des CVE iOS et macOS : patche, puis règle les profils Safari

Mac Souverain — Wed, 13 May 2026 14:15:25 GMT

iOS 26.5 et macOS Tahoe 26.5 publiés le 11 mai corrigent 98 CVE chacun (dont 21 et 22 sur WebKit). Lockdown Mode global, c’est trop pour ton quotidien. Les profils Safari, dispos depuis iOS 17, font la segmentation d’usage à ta place.

Ce que tu dois surveiller

1. Installe iOS 26.5 et macOS Tahoe 26.5 dès aujourd’hui.

2. Crée un profil Safari “Sensible” avec extensions privacy activées uniquement sur lui.

3. Bascule dessus pour banque, mail web, liens douteux, recherche médicale. Profil par défaut intact pour le reste.

Apple a publié le 11 mai iOS 26.5 et macOS Tahoe 26.5, qui corrigent 98 CVE côté iOS (dont 21 sur WebKit, le moteur de Safari) et 98 côté macOS (dont 22 WebKit). Tu installes le patch. Et après ? Plutôt qu’activer Lockdown Mode partout et casser la moitié des sites que tu visites, il existe une option plus fine, dispo depuis iOS 17 et que presque personne n’utilise : les profils Safari.

Le fait

Lundi 11 mai, Apple a publié iOS 26.5 et macOS Tahoe 26.5 en stables. 98 correctifs de sécurité côté iOS (dont 21 sur WebKit), 98 côté macOS (dont 22 WebKit). Plusieurs vulnérabilités permettaient à un site malveillant d’exécuter du code ou de contourner les protections sandbox. C’est le profil normal d’une release Apple : WebKit prend toujours le plus gros lot, parce que c’est la plus large surface d’attaque d’un iPhone ou d’un Mac.

Patche maintenant. Ça, c’est l’évidence. La vraie question, c’est ce que tu fais entre deux patchs, sur les liens reçus par mail, les recherches sensibles, les sessions banque.

Pourquoi Lockdown Mode tout le temps, c’est trop

Lockdown Mode est solide. MacSouverain en a fait l’éloge dans l’article 29. Pour un journaliste, un dissident, un avocat sur dossier sensible, c’est exactement ce qu’il faut.

Pour un freelance ou une PME qui veut juste lire son mail Proton, faire sa compta en ligne et regarder une recette le soir, c’est trop. JIT JavaScript désactivé, extensions Safari coupées, formats média restreints, pièces jointes Messages filtrées. Trop de friction, trop de sites qui rendent mal. Résultat classique : tu actives trois jours, tu trouves ça pénible, tu désactives, tu te retrouves avec rien.

Ce que sont les profils Safari

Depuis iOS 17 et macOS Sonoma (septembre 2023), Safari supporte plusieurs profils dans la même app. Resté discret, jamais mis en avant en keynote. La plupart des gens à qui tu en parles ne savent pas que ça existe.

Chaque profil a son propre historique, ses propres cookies, ses propres extensions activées, son propre moteur de recherche, ses propres favoris et groupes d’onglets. Aucun mélange : le cookie de session Google de ton profil “Perso” n’est pas vu par ton profil “Sensible”. Les extensions privacy actives sur “Sensible” ne ralentissent pas la navigation “Perso”. Bascule en deux taps (bouton onglets sur iPhone, menu Safari sur Mac), synchro iCloud entre Mac et iPhone.

C’est la segmentation d’usage qu’on conseille en sécurité depuis des années, mais sans installer un second navigateur.

Ce que tu fais maintenant

1. Installe iOS 26.5 et macOS Tahoe 26.5. Réglages, Général, Mise à jour logicielle. Vingt minutes, redémarrage compris.

2. Crée un profil Safari “Sensible”. Sur Mac : Safari, menu Safari, Créer un profil. Sur iPhone : Réglages, Apps, Safari, Profils, Nouveau profil. Nom, icône, couleur.

3. Configure le profil “Sensible” : moteur de recherche DuckDuckGo ou Qwant (réglage par profil), favoris vides, et ajoute deux ou trois extensions privacy activées uniquement sur ce profil : AdGuard pour Safari (gratuit App Store, filtrage réseau et cosmétique), Vinegar si tu veux un YouTube propre (achat one-shot), StopTheMadness Pro si tu as déjà sa licence. Ton profil par défaut reste intact, pas de ralentissement quand tu surfes normalement.

4. Ce que le profil n’isole pas : les réglages avancés Safari (bloquer tous les cookies, désactiver JavaScript, blocage du tracking) sont globaux, ils s’appliquent à tous les profils. Si tu veux durcir ces toggles, fais-le globalement dans Réglages, Apps, Safari, en sachant que ça affectera aussi ton profil par défaut.

Quand basculer sur le profil “Sensible”

Lien reçu par mail d’un expéditeur inconnu. Recherche médicale ou juridique. Connexion banque ou broker. Mail Proton sur le web depuis un appareil moins utilisé. Tout site dont tu n’es pas sûr et que tu n’as aucune envie de cookier ton profil principal avec. Deux taps, tu bascules, tu fais ce que tu as à faire, tu reviens.

Segmentation d’usage, pas durcissement global. Tu gardes ton confort sur ton profil par défaut, tu as un mode “navigation propre” à disposition.

Ce que ça ne remplace pas

Les profils Safari ne sont pas Lockdown Mode. Le JIT JavaScript reste actif sur tous les profils. Si tu es journaliste source-sensible, avocat sur dossier étatique, dissident, ou si tu as déjà reçu une notification Apple de menace, Lockdown Mode global reste le bon réglage. Les profils Safari sont un outil pour le quotidien standard, pas une protection contre des acteurs étatiques.

Et l’hygiène de base ne change pas : tu patches (iOS 26.5 maintenant), tu n’ouvres pas les pièces jointes que tu n’attends pas, tu vérifies l’URL avant de taper un mot de passe.

Sources

Voir aussi

Proton Mail passe au chiffrement post-quantique (et c'est gratuit)

Mac Souverain — Wed, 06 May 2026 06:39:41 GMT

Proton Mail propose désormais une option de chiffrement qui résiste aussi à un futur ordinateur quantique. Disponible sur tous les plans, gratuit inclus. À activer toi-même, et seulement pour tes nouveaux emails.

Ce que tu dois surveiller

1. Active l’option dans Réglages, Encryption and keys, mais ne crois pas que ça protège tes anciens emails, ça ne marche que pour la suite.

2. Le bénéfice est maximal quand ton correspondant est aussi sur Proton. Côté Gmail ou autre, retour au chiffrement classique pour cet envoi.

3. Le forwarding chiffré E2E est temporairement incompatible. Si tu l’utilises, choisis l’un ou l’autre en attendant la résolution.

Proton Mail vient d’activer une option qui protège tes nouveaux emails contre le déchiffrement par un futur ordinateur quantique. C’est dispo sur tous les plans, y compris le gratuit, à activer toi-même. Et ce n’est pas du simple marketing.
\

Le fait

Le 5 mai 2026, Proton a poussé une nouvelle option dans les réglages de Proton Mail : « Enable post-quantum protection ». Une fois activée, les nouveaux emails que tu envoies sont chiffrés avec une combinaison classique plus algorithme « post-quantique », un type de cryptographie conçu pour résister aussi à un ordinateur quantique de demain. Disponible sur tous les plans, y compris gratuit, ce qui est suffisamment rare dans l’industrie pour être souligné.

L’option n’est pas activée par défaut. Tu vas dans Réglages, Encryption and keys, et tu coches toi-même. Proton justifie cette prudence par le statut encore expérimental côté écosystème externe.

L’idée derrière, c’est de contrer ce qu’on appelle « harvest now, decrypt later ». En clair : un attaquant peut intercepter et stocker tes emails chiffrés aujourd’hui, sans pouvoir les lire, dans l’espoir de les déchiffrer dans dix ou vingt ans, quand un ordinateur quantique suffisamment puissant existera. Le chiffrement classique d’aujourd’hui (RSA, courbes elliptiques) tomberait alors comme un château de cartes. Le post-quantique, c’est l’assurance que même ce scénario ne donne rien à l’attaquant.

Pourquoi ça compte pour toi

Plusieurs choses à savoir avant de courir l’activer.

La protection ne s’applique qu’aux nouveaux emails. Tout ce qui est déjà dans ta boîte, envoyé ou reçu avant l’activation, reste chiffré comme avant. Proton le dit noir sur blanc : « Post-quantum protection applies to new encrypted emails going forward. It does not retroactively re-encrypt emails that are already in your mailbox, for now. » Si tes vieux emails ont déjà été aspirés par quelqu’un, l’option d’aujourd’hui ne change rien pour eux. Le « for now » suggère qu’un re-chiffrement rétroactif est sur la roadmap, mais ce n’est pas livré.

Le destinataire compte. Le scénario qui marche le mieux, c’est Proton vers Proton, où les deux côtés ont des clés post-quantiques. Si ton interlocuteur est ailleurs (Gmail, un client OpenPGP classique, etc.), Proton retombe sur le chiffrement habituel pour cet envoi, ce qui est la seule chose raisonnable à faire en attendant que les autres clients adoptent la même norme.

Quelques frictions. Si tu utilises le forwarding chiffré de bout en bout chez Proton, il est temporairement incompatible avec la nouvelle option. Tu choisis l’un ou l’autre pour l’instant. Petit impact perfo aussi à l’envoi, à peine perceptible sur du matériel récent d’après Proton.

L’angle qui change tout : standard ouvert vs silos

Proton n’est pas le tout premier service mail à proposer du post-quantique. Tuta (ex-Tutanota) le fait depuis 2024, avec son propre schéma maison. Apple a déployé PQ3 sur iMessage en février 2024. Signal a fait pareil avec PQXDH dès septembre 2023.

La différence Proton, c’est qu’il le fait sur OpenPGP, le standard ouvert que d’autres clients mail peuvent adopter. Apple PQ3 reste prisonnier de l’écosystème Apple, Signal PQXDH ne sort pas de Signal, et le schéma de Tuta est propriétaire à Tuta. Proton parie au contraire sur la standardisation, en collaboration annoncée avec le projet Thunderbird, pour que demain ton client mail souverain (Thunderbird, GnuPG, ou un autre) puisse lire et écrire des emails post-quantiques compatibles avec Proton sans avoir à passer par l’app Proton elle-même.

C’est l’angle souveraineté important. Un standard ouvert, c’est ce qui empêche que la sécurité de tes communications dépende du bon vouloir d’un seul fournisseur. Aujourd’hui en pratique, l’interop reste largement Proton vers Proton, l’écosystème externe n’est pas encore au rendez-vous. Mais la direction est posée, et c’est ce qui distingue cette annonce d’un simple coup marketing.\

Ce que tu fais maintenant

1. Va dans Proton Mail, Réglages, Encryption and keys, et active « Enable post-quantum protection ». Lis le bandeau d’avertissement (forwarding, etc.) avant de valider.

2. Garde en tête que ça ne protège QUE tes nouveaux envois. Si tu as des conversations sensibles archivées, pose-toi la question du tri. Le re-chiffrement rétroactif viendra plus tard, mais pour l’instant c’est du conditionnel pur.

3. Si ton correspondant est aussi sur Proton, encourage-le à activer de son côté. Tant que les deux extrémités ne sont pas équipées, le bénéfice reste partiel.

4. Si tu utilises Proton Bridge avec Apple Mail (cf. l’article dédié), assure-toi que ton Bridge est à jour, sinon les nouveaux emails post-quantiques pourraient ne pas être lisibles côté client local.

Voir aussi

Sources

iOS 26.5 chiffre enfin les RCS iPhone-Android (mais Signal reste devant)

Mac Souverain — Tue, 05 May 2026 11:42:53 GMT

Apple active le chiffrement E2EE sur les messages RCS avec iOS 26.5. Tes échanges iPhone-Android ne passeront plus en SMS clair. Un vrai progrès, mais le protocole RCS reste inférieur à Signal pour les conversations sensibles.

Ce que tu dois surveiller

1. Active Advanced Data Protection sur iCloud pour que tes backups soient aussi chiffrés E2EE

2. Garde Signal pour le sensible : seul protocole où tes clés ne sortent jamais de ton appareil et où les métadonnées (qui parle à qui, quand) ne fuient pas vers un opérateur ou Google.

3. Vérifie que tes contacts Android supportent bien RCS, sinon retour au SMS clair

Apple active enfin le chiffrement de bout en bout sur les messages RCS avec iOS 26.5. Tes échanges iPhone-Android ne passent plus en SMS clair, mais le protocole reste inférieur à Signal pour le sensible.

Le fait

Apple a confirmé le 4 mai 2026 que iOS 26.5 (release candidate disponible, stable publique attendue autour du 11-12 mai) intègre le chiffrement de bout en bout pour les messages RCS échangés entre iPhone et Android. Concrètement, quand tu envoies un message depuis ton iPhone vers le Samsung de ton pote, le contenu sera chiffré E2EE selon le profil RCS Universal Profile 3.0, publié par la GSMA en mars 2025, qui repose sur le protocole MLS (Messaging Layer Security), un standard IETF audité, le même socle que celui retenu pour le futur chiffrement interopérable de Matrix et d’autres messageries.

À noter : Apple précise que la fonctionnalité reste en bêta même en iOS 26.5 stable, et qu’elle dépend du support opérateur des deux côtés (iPhone et Android sur des opérateurs RCS UP 3.0 compatibles). Un cadenas dans Messages indiquera quand le canal est effectivement chiffré, et un toggle est ajouté dans Réglages > Messages.

C’est la fin d’une anomalie qui durait depuis des années : les échanges cross-platform passaient en SMS/MMS, donc en clair, interceptables par n’importe quel opérateur ou acteur étatique sur le chemin. Google poussait RCS depuis 2019, Apple traînait des pieds. Le timing n’est pas anodin : la pression de la GSMA, des opérateurs et les critiques publiques répétées sur la sécurité des SMS cross-platform ont visiblement accéléré le calendrier de Cupertino.

Pourquoi ça compte pour toi

Si tu utilises iMessage entre appareils Apple, rien ne change : ton canal reste E2EE comme avant. Le vrai gain concerne les échanges avec l’écosystème Android, qui représente 70% du marché mondial. Jusqu’ici, ces conversations tombaient en SMS (texte brut) ou MMS (compression destructive, zéro chiffrement). Avec RCS E2EE, tu obtiens enfin un niveau de protection décent par défaut.

Mais gardons la tête froide. Le chiffrement RCS repose sur l’infrastructure des opérateurs et de Google (qui fournit Jibe, le backend RCS dominant). Les clés transitent par leurs serveurs lors de l’établissement de session. Ce n’est pas du Signal où tu contrôles la totalité de la chaîne. Pour une conversation sensible (avocat, médecin, source journalistique, deal business confidentiel), Signal reste le gold standard : protocole audité, serveurs minimaux, métadonnées réduites, code open source.

L’autre point à surveiller : Apple n’a pas confirmé si les backups iCloud des conversations RCS seront chiffrés E2EE. Sans Advanced Data Protection activée, tes messages RCS pourraient se retrouver en clair sur les serveurs Apple, annulant le bénéfice du chiffrement en transit.

Ce que tu fais maintenant

1. Active Advanced Data Protection sur ton compte iCloud (Réglages > Apple Account > iCloud > Protection avancée des données). Sans ça, tes backups restent accessibles à Apple et aux réquisitions judiciaires. Note : l’ADP couvre les backups Messages, mais pas iCloud Mail, Contacts et Calendrier qui restent hors E2EE par design.

2. Pour les conversations vraiment sensibles, reste sur Signal. Le chiffrement RCS est un progrès pour le tout-venant, pas un remplacement du gold standard souverain.

3. Vérifie que tes contacts Android ont bien RCS activé. L’indicateur fiable du chiffrement effectif sera le cadenas dédié dans Messages (annoncé par Apple), pas la couleur de bulle (vert = SMS/RCS, bleu = iMessage, sans rapport direct avec le E2EE). Un Android sur un opérateur qui ne supporte pas RCS UP 3.0 te ramène en SMS clair.

4. Mets à jour vers iOS 26.5 dès la release stable pour bénéficier du chiffrement. Les bêtas c’est sympa pour tester, mais pas pour ton daily driver.

Sources

Trellix : l'éditeur cybersécu partenaire d'Europol se fait piquer son code source

Mac Souverain — Sun, 03 May 2026 07:43:12 GMT

Trellix, éditeur cybersécu partenaire d’Europol, a annoncé le 02/05 un accès non autorisé à une portion de son code source. Pas d’évidence d’exploitation selon l’éditeur, déclaration de la victime à vérifier.

Ce que tu dois surveiller

1. Le périmètre exact de l’intrusion (produits, durée, attribution) que Trellix n’a pas communiqué au 03/05.

2. Toute communication officielle Trellix dans les semaines à venir, ou une éventuelle apparition du code en clair sur un forum.

3. Si tu as Trellix sur ton parc, demande par écrit à ton revendeur la liste des produits concernés et planifie une revue de configuration ; si tu as un autre EDR, ne change pas d’éditeur sur un coup de tête.

Mises à jour

04/05/2026, J+2, confirmation externe presse cybersécu

BleepingComputer reprend la divulgation Trellix et fixe l’échelle de l’éditeur : plus de 50 000 clients entreprises et administrations, plus de 200 millions d’endpoints sous protection. Trellix précise que le code accédé est du « code de développement produit » et n’inclut « ni les environnements ni les données clients ». Affirmation de l’éditeur, à vérifier comme le reste, mais c’est une affirmation cadrée, pas un silence.

Aucun élément technique nouveau : périmètre fin, durée d’intrusion et attribution restent non communiqués. La fenêtre du « peut-être que ça ne sortira pas » est fermée, l’incident est désormais officiellement repris par la presse cybersécu de référence.

Source : BleepingComputer, 04/05/2026

Le chasseur s’est fait chasser

Trellix vend de l’EDR (le truc qui surveille les processus de tes machines pour repérer les comportements suspects) à des entreprises et des administrations. Trellix est aussi partenaire industrie d’Europol sur les grosses opérations de takedown des dernières années : Endgame en novembre 2025 (1025+ serveurs Rhadamanthys, Elysium et VenomRAT démantelés), Cobalt Strike en juillet 2025. John Fokker, responsable du renseignement sur les menaces de la maison, donnait encore une interview au Register il y a quatre semaines pour expliquer comment Trellix aide à coffrer les opérateurs de rançongiciels.

Le 2 mai 2026, Trellix a publié un communiqué officiel sur son propre site pour annoncer qu’un acteur non identifié avait obtenu un accès non autorisé à une « portion » de son code source. Experts en investigation numérique mandatés, autorités notifiées, enquête en cours, formules d’usage. C’est leur code à eux qui s’est fait extraire.

Tu peux le formuler poliment, ou tu peux le formuler franchement : l’éditeur qui chasse les attaquants pour le compte d’Europol s’est fait visiter le repo. Et si tu trouves que c’est embarrassant pour Trellix, tu n’as pas tort. Si tu trouves que c’est isolé, par contre, tu n’as pas suivi les news des dix dernières années.

Ce qu’on sait, sourcé

Selon le communiqué officiel Trellix publié le 02/05/2026, un acteur non identifié a obtenu un accès non autorisé à une « portion » du code source, périmètre volontairement vague. L’éditeur a mandaté des experts en investigation numérique et notifié les autorités. Les détails sont repris verbatim par The Hacker News, Security Affairs et plusieurs autres sources presse cybersécu. Pour situer Trellix : partenaire industrie d’Europol sur les opérations Endgame (novembre 2025, 1025 serveurs Rhadamanthys, Elysium et VenomRAT démantelés) et détournement de Cobalt Strike (juillet 2025).

Histoire confirmée, mais jeune. C’est un SIGNAL, pas encore une ALERTE.

Ce que Trellix dit, ce que personne ne sait

Trellix affirme deux choses dans son communiqué : « pas d’évidence que le code source ait été exploité », « pas d’impact sur les produits clients ni sur le pipeline de distribution ». Tu prends ces deux affirmations comme tu prendrais n’importe quel communiqué d’une entreprise qui vient de se faire pirater : c’est la version de la victime. Pas un mensonge a priori, mais pas un fait vérifié non plus. « Pas d’évidence » en J+1, ça veut dire que les enquêteurs n’ont pas encore eu le temps de creuser.

Le reste, c’est du brouillard officiel.

Zones d’ombre non communiquées par Trellix au 03/05/2026

Quels produits sont concernés (EDR, XDR, SIEM Helix, code historique McAfee Enterprise ou FireEye/Mandiant)

Quand l’intrusion a commencé, combien de temps elle a duré

Comment elle a été détectée (alerte interne, signalement externe, demande de rançon)

Quelle plateforme hébergeait le repo (GitHub Enterprise, GitLab self-hosted, Azure DevOps)

L’attribution : pas un nom, pas un groupe, rien

Les données clients : silence radio, Trellix parle uniquement du code

Aucune de ces réponses n’est obligatoire le jour de la divulgation, soyons honnêtes. Le calendrier classique d’un incident de ce type prend des semaines. Mais c’est précisément pour ça qu’il faut tracer l’incertitude maintenant et pas la diluer dans une chronologie reconstruite trois mois plus tard, quand tout le monde aura oublié que personne ne savait rien le 3 mai.

Ce que ça rappelle (et ce que ça ne rappelle pas)

Pour cadrer : un éditeur cybersécu de premier rang qui se fait extraire son code, ce n’est ni nouveau ni anecdotique. FireEye en 2020 (Sunburst, outils Red Team exfiltrés). SolarWinds la même année (chaîne de build empoisonnée). Kaseya en 2021 (REvil par la supply chain). CrowdStrike en juillet 2024 (pas une intrusion mais un push malheureux qui a planté 8,5 millions de Windows). Aucun de ces incidents n’est strictement comparable à ce qui arrive à Trellix, et c’est justement le point : ils ne se ressemblent pas, mais ils racontent la même histoire structurelle. Aucun éditeur cybersécu n’est sanctuaire, y compris ceux qui chassent les attaquants pour le compte des États.

Ce que ça ne rappelle pas, en revanche : on ne sait pas si on parle d’un incident type Sunburst (compromission de la supply chain avec persistance dans les produits clients) ou d’une simple extraction de repo (du code dehors, pas d’impact aval). Trellix dit la deuxième option. L’enquête dira si c’est exact. D’ici là, « Trellix dit » et « c’est confirmé », c’est pas la même chose.

Ce que tu fais maintenant

1. Si tu as Trellix EDR ou XDR sur ton parc. Tu mets une alerte calendrier sur 30 jours pour suivre les communications Trellix et tu demandes par écrit à ton revendeur ou à ton chargé de compte la liste des produits exactement concernés (réponse souvent vague au début, insiste). Tu profites de la fenêtre pour planifier une revue de configuration que tu repoussais depuis six mois. Tu ne paniques pas, tu ne désinstalles pas dans la nuit.

2. Si tu as un autre EDR. Tu ne changes pas d’éditeur sur un coup de tête. L’herbe n’est pas plus verte ailleurs, demande à ceux qui ont remplacé leur EDR par CrowdStrike juste avant juillet 2024. Tu continues ton monitoring, et tu prends cet incident comme un rappel que ta posture sécu ne peut pas reposer sur une couche unique, peu importe l’éditeur.

3. Si tu es un particulier sur Mac. Ça ne change strictement rien à ton quotidien aujourd’hui. Trellix n’est pas un produit grand public Apple. Ce qui te concerne, c’est le rappel : ton antivirus, ton EDR, ton VPN, ton gestionnaire de mots de passe sont tous des éditeurs qui peuvent se faire pirater. La défense en profondeur, ce n’est pas un slogan. Ta sécu en open source self-host et multicouches. On revient là-dessus bientôt.

Ce négociateur ransomware bossait pour le gang, pourquoi tes backups restent ta seule garantie

Mac Souverain — Fri, 01 May 2026 10:53:02 GMT

Un négociateur ransomware américain a plaidé coupable d’avoir secrètement travaillé pour les gangs qu’il était censé combattre. Cette affaire révèle un problème structurel : tout l’écosystème post-incident (négociateurs, assureurs, consultants) a intérêt à ce que tu paies.

Ce que ça change pour toi

1. Tes backups chiffrés client-side (Kopia, zero-knowledge) et testés restent ta seule garantie fiable, les tiers peuvent être compromis.

2. Segmente ton réseau pour qu’un ransomware ne touche pas tes sauvegardes. Tailscale mesh.

3. Documente ta procédure de réponse AVANT l’incident, sans dépendre d’intermédiaires.

Le fait

Un consultant en cybersécurité américain vient de plaider coupable devant un tribunal fédéral. Son métier officiel : négocier avec les gangs de ransomware pour le compte d’entreprises victimes. Son activité réelle : informer secrètement ces mêmes gangs de l’état des négociations, des capacités de paiement des victimes, et saboter les tentatives de récupération qui auraient pu éviter le versement de rançon.

Le schéma est élégant dans sa perversité. Tu appelles un “expert” pour te sortir du merdier, et cet expert joue contre toi depuis le début. Il connaît tes réserves financières, il sait que tes backups sont inutilisables, et il touche des deux côtés.

Ce n’est pas un cas isolé d’individu vénal. C’est un symptôme structurel d’un marché où tous les intermédiaires ont intérêt à ce que tu paies. Le négociateur (commission sur la rançon), l’assureur cyber (prime ajustée au risque perçu, pas réel), le gang (revenus directs).
Toi, tu es la vache à lait.

Pourquoi ça compte pour toi

Si tu lis MacSouverain, tu as probablement déjà une allergie aux tiers de confiance non vérifiables. Cette affaire confirme cliniquement pourquoi.

Le problème n’est pas qu’un type était corrompu. Le problème, c’est que le modèle économique du ransomware crée des incitations pour que TOUT le monde autour de toi préfère que tu paies. L’assurance cyber ? Elle te rembourse (partiellement), donc elle ne combat pas le paiement, elle le facilite. Le négociateur ? Payé au résultat, et le “résultat” c’est de conclure un deal payant (avec commission) pour restaurer tes données.

Quand l’écosystème entier est aligné contre toi, la seule position tenable c’est de ne pas en dépendre. Pas de négociateur si tu peux restaurer seul. Pas d’assurance cyber comme stratégie principale si tes backups sont solides. Autonomie technique d’abord, recours externes en dernier ressort.

Ce que tu fais maintenant

1. Vérifie que ta stratégie backup suit la règle 3-2-1-1 : trois copies, deux supports différents, une hors site, une hors ligne (air-gapped). Kopia chiffre tout côté client avant l’envoi (zero-knowledge), les destinations (B2, S3, NAS, SFTP) ne voient que des blobs opaques, déduplicés, indéchiffrables sans ta passphrase. Si le serveur est compromis, ton repo reste illisible.

2. Teste ta restauration. Un backup jamais testé n’existe pas. Programme un exercice trimestriel où tu restaures effectivement un système depuis zéro.

3. Segmente ton réseau. Un ransomware qui touche ton poste de travail ne doit pas avoir accès direct à ton NAS backup. Tailscale mesh wireguard + ACLs strictes entre segments.

4. Documente ta procédure de réponse AVANT l’incident. Qui tu appelles (et pourquoi tu leur fais confiance), quelles machines tu isoles en premier, où sont tes clés de restauration. Pas dans Notes iCloud sans ADP, ni dans un quelconque doc partagé en clair.

Sources

https://www.schneier.com/blog/archives/2026/05/a-ransomware-negotiator-was-working-for-a-ransomware-gang.html

Résultats Apple Q2, derrière l'euphorie la question des services en abonnement

Mac Souverain — Fri, 01 May 2026 09:02:35 GMT

Apple affiche un trimestre solide avec un Mac en forme et des Services en croissance à deux chiffres. Pour qui utilise l’écosystème Apple comme pivot souverain, c’est une confirmation : le hardware reste sain, mais la tentation du lock-in cloud s’intensifie.

Ce que ça change pour toi

1. Le Mac et l’iPhone restent solides à long terme, Apple est en pleine forme.

2. La croissance Services signifie plus de pression pour t’enfermer dans iCloud, Apple Music, Apple One.

3. Ta stack souveraine (ADP + Proton + Etebase) devient un choix actif, pas un compromis.

Le fait

Apple vient de publier ses résultats du deuxième trimestre fiscal 2026, et comme le résume Jason Snell sur Six Colors : « net-net over the moon ». Traduction pour les non-comptables, Wall Street est aux anges et Cook peut dormir tranquille.

Les Mac continuent leur trajectoire post-Apple Silicon avec des ventes solides. L’iPhone résiste malgré un marché smartphone globalement atone. L’iPad fait du surplace, ce qui est presque une victoire vu l’état du marché tablettes. Mais le vrai moteur de croissance, celui qui fait briller les yeux des analystes, c’est encore et toujours les Services.

Cette catégorie fourre-tout (App Store, Apple Music, iCloud, Apple TV+, Apple One, Arcade, News+, Fitness+) représente désormais une part significative des revenus et, surtout, des marges. Apple ne vend plus seulement du hardware, il vend un abonnement perpétuel à son écosystème.

Pourquoi ça compte pour toi

Bonne nouvelle d’abord, le hardware Apple reste un pari solide. Si tu as investi dans un Mac Studio, un MacBook Pro M3 ou un iPhone comme pivot de ta stack, tu n’es pas sur un navire en perdition. Apple a les moyens de maintenir son écosystème hardware pendant des décennies. La santé financière de la boîte, c’est ta garantie que les mises à jour macOS continueront, que les puces Apple Silicon évolueront, que ton investissement matériel ne sera pas orphelin dans trois ans.

Maintenant, la partie qui mérite ton attention critique : cette croissance Services n’est pas neutre. Chaque point de pourcentage gagné là-dessus, c’est Apple qui resserre son étreinte.

Plus iCloud devient central dans l’expérience par défaut, plus le chemin vers Proton Drive ressemble à une randonnée hors-piste. Plus Apple One semble « économique », plus tu paies en dépendance ce que tu crois économiser en euros.

Pour nous qui avons choisi la souveraineté pratique, ces résultats sont un rappel. Apple n’est pas ton allié idéologique, c’est ton fournisseur hardware. Un excellent fournisseur, mais un fournisseur quand même.

Sa croissance Services, c’est sa stratégie pour te rendre captif. Ta contre-stratégie, c’est Advanced Data Protection activé, Proton pour le mail et le calendrier critique, Etebase pour les contacts, et une conscience claire de ce que tu délègues volontairement versus ce qu’on t’impose par défaut.

Ce que tu fais maintenant

1. Vérifie que Advanced Data Protection est bien activé sur ton compte iCloud (Réglages > Apple ID > iCloud > Protection avancée des données). C’est le minimum pour que ton iCloud reste E2EE (on a expliqué pourquoi ici).

2. Audite ton abonnement Apple One si tu en as un. Quels services utilises-tu vraiment ? Apple Music peut se justifier, mais iCloud+ au-delà de 50 Go mérite réflexion.

3. Identifie tes données critiques (mots de passe, contacts pro, documents sensibles) et confirme qu’elles transitent par ta stack souveraine : Vaultwarden ou Proton Pass pour les credentials, Etebase pour les contacts, Proton Drive pour les fichiers cloud E2EE.

4. Ces résultats ne changent rien à court terme. Mais ils confirment la direction, Apple pousse aux Services, et ta vigilance doit suivre le même rythme.

Sources

MCP d'Anthropic — un défaut de conception expose 200 000 instances à l'exécution de code distante

Mac Souverain — Mon, 27 Apr 2026 07:05:47 GMT

OX Security a publié le 15 avril 2026 une vulnérabilité architecturale dans le Model Context Protocol (MCP) d’Anthropic : l’interface STDIO des SDKs officiels permet l’exécution de commandes OS arbitraires depuis la configuration. 7 000+ serveurs publics, 150M+ téléchargements et environ 200 000 instances sont exposés. Côté Mac : Cursor, Windsurf et Claude Desktop sont concrètement touchés via leurs intégrations MCP. Anthropic refuse de patcher : “by design”.

Ce que tu dois faire

1. Si tu utilises Cursor, Windsurf ou Claude Desktop avec des serveurs MCP installés : audite la liste des MCPs connectés, désactive ceux que tu n’as pas explicitement vérifiés, et ne charge jamais une configuration MCP venant d’un tiers (gist, dépôt GitHub forké, partage Slack) sans la lire intégralement.

2. Mets à jour vers les versions patchées des outils impactés (LiteLLM, LangFlow, Windsurf, Flowise, DocsGPT, GPT Researcher, Bisheng, Agent Zero), au moins 10 CVE émis (CVE-2026-30615 Windsurf via HTML malveillant, CVE-2026-30623 LiteLLM, CVE-2025-65720 GPT Researcher, etc.). Mets aussi à jour Cursor et Claude Desktop, qui utilisent les SDKs MCP sans avoir leur propre CVE.

3. Si tu héberges un serveur MCP exposé en réseau : bloque l’accès public, place-le dans un sandbox avec permissions restreintes, monitore les invocations.

4. Considère que toute config MCP externe est non-fiable par défaut : Anthropic considère que la responsabilité du sandboxing revient au développeur, pas au protocole.

Tu as installé Cursor ou Windsurf sur ton Mac pour développer avec un assistant LLM. Tu as ajouté quelques serveurs MCP, un pour ta DB, un pour ton API, un pour les fichiers locaux. Cette stack qui te semble faite “à la maison” est en réalité bâtie sur un protocole dont l’interface principale considère que n’importe quelle configuration peut exécuter n’importe quelle commande shell. Et selon OX Security, ce n’est pas un bug : c’est l’interprétation officielle d’Anthropic.

Ce qui se passe

Le 15 avril 2026, l’équipe de recherche d’OX Security publie un rapport intitulé “The Mother of All AI Supply Chains”. Le constat : le Model Context Protocol (MCP) d’Anthropic — protocole standard pour brancher des outils, données et services à un LLM — contient une faille architecturale dans son interface STDIO. La configuration peut directement déclencher l’exécution de commandes système arbitraires, sans contrôle, sans sanitization (validation des entrées), sans isolation par défaut.

Les chiffres documentés par OX :

7 000+ serveurs MCP publics indexés
150 millions+ de téléchargements des SDKs et serveurs concernés
~200 000 instances estimées vulnérables
10 CVE émis (statut patché ou pending)
Validation pratique : commandes exécutées avec succès sur 6 plateformes en production

Les CVE notables :

CVE-2026-30615 (Windsurf, reporté) : prompt injection via HTML malveillant menant à RCE locale, CVSS 8.0 (HIGH).
CVE-2026-30623 (LiteLLM, patché) : RCE authentifié via configuration JSON.
CVE-2025-65720 (GPT Researcher, reporté) : UI injection menant à reverse shell.
Et d’autres sur LangFlow, Flowise, DocsGPT, Bisheng, Agent Zero, Fay Framework, Langchain-Chatchat, Upsonic.

OX décrit quatre familles d’attaque distinctes, toutes exploitant la même primitive : la conversion configuration → commande sans frontière.

La position d’Anthropic, telle que rapportée par OX et confirmée par des reprises (THN, devops-daily) : le comportement est “by design”. Le modèle d’exécution STDIO est jugé “secure default” si l’utilisateur fait son boulot de sanitization. Anthropic refuse de modifier le protocole.

Pourquoi c’est important pour toi

Tu n’es pas un opérateur de cloud LLM, tu n’as pas 50 000 serveurs MCP publics. Mais si tu es lecteur de MacSouverain, il est très probable que :

Tu utilises Cursor, Windsurf ou Claude Desktop sur ton Mac, les trois disposent d’intégrations MCP officielles, écrites avec les SDKs vulnérables Anthropic.
Tu as branché 1 ou 2 serveurs MCP, typiquement un MCP filesystem, un MCP DB, un MCP shell, un MCP Notion. Chacun d’eux est une surface d’attaque potentielle.
Tu as importé une configuration MCP partagée, un gist GitHub, un fichier claude_desktop_config.json venu d’un repo public, un export d’un collègue. C’est exactement le vecteur principal : la config peut déclencher l’exécution.

L’argument “by design” d’Anthropic est défendable techniquement (un protocole n’est pas un sandbox). Mais Anthropic transfère la responsabilité du sandboxing aux développeurs en aval, dans un contexte où :

Les utilisateurs grand public adoptent Claude Desktop sans formation devsec.
Les SDKs officiels sont publiés sans documentation de mitigation pré-installée.
Les patches viennent des outils en aval (Cursor, Windsurf, etc.), pas du protocole lui-même.

Ce que tu dois faire

Immédiat (cette semaine) :

Inventorie tes MCPs actifs. Sur Cursor : Settings → MCP. Sur Claude Desktop : ~/Library/Application Support/Claude/claude_desktop_config.json. Sur Windsurf : check la liste depuis l’IDE. Désactive tout MCP que tu n’as pas déployé toi-même ou validé en lisant son code source.
Mets à jour Cursor, Windsurf, et tous les outils LLM-natifs vers les versions patchées (≥ avril 2026). Vérifie via les release notes que la CVE concernée est explicitement corrigée.
Audit des configurations partagées : si tu as récupéré une config MCP depuis un dépôt public, un Slack pro, un gist, un Discord, lis-la intégralement avant de l’activer. Les chemins exécutables, les commandes, les variables d’environnement. Une configuration MCP, c’est un script shell déguisé.

Dans la semaine :

Pour les MCPs filesystem ou shell que tu gardes : limite leur portée au strict minimum. Pas de chemin / ni ~. Donne le sous-dossier précis du projet courant.
Pour les MCPs qui tournent comme serveur HTTP local : vérifie que le port n’est pas bind sur 0.0.0.0. Doit être 127.0.0.1. Sinon une page web malveillante via navigateur peut déclencher l’exécution.

À surveiller :

La position d’Anthropic peut évoluer si la pression communautaire grimpe. Surveille les release notes du SDK MCP officiel (@modelcontextprotocol/sdk sur npm, mcp sur PyPI) pour un éventuel mode “strict” ou “sanitize-by-default”.
Les outils tiers (Cursor, Windsurf, Claude Desktop) peuvent ajouter des couches de sandboxing, vérifie leur documentation sécurité dans les semaines à venir.

Sources

OX Security — “The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of Anthropic’s MCP” — 15 avril 2026 — https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/
OX Security — “MCP Supply Chain Advisory: RCE Vulnerabilities Across the AI Ecosystem” — 15 avril 2026 — https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem/
The Hacker News — “Anthropic MCP Design Vulnerability Enables RCE, Threatening AI Supply Chain” — 20 avril 2026 — https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html
DevOps Daily — “The MCP Design Flaw That Exposes 150M Downloads to RCE” — 15 avril 2026 — https://devops-daily.com/posts/mcp-design-flaw-rce-supply-chain-risk

Voir aussi

Mythos, le modèle qui trouve des failles tout seul, vient de fuiter

Mac Souverain — Sun, 26 Apr 2026 16:54:15 GMT

Anthropic garde sous clé un modèle, Mythos, capable de trouver des failles zero-day toute seule sur iOS, macOS, Windows et les navigateurs. Un groupe non autorisé, dont un employé d’un sous-traitant Anthropic, y accède depuis l’annonce du programme, via une URL devinée.

Ce que tu dois faire

1. Installe les mises à jour en attente sur ton Mac et ton iPhone, et active les mises à jour automatiques.

2. Filtre les expéditeurs inconnus dans iMessage et les appels d’inconnus sur ton iPhone.

3. Méfie-toi des liens et des pièces jointes, durablement.

Anthropic garde sous clé un modèle capable de trouver des failles zero-day toute seule. Un groupe non autorisé y accède depuis l’annonce du programme, en ayant simplement deviné l’URL. Le jour où cette capacité bascule côté offensif, ce n’est plus un scénario de film.

Ce qui se passe

Mythos, c’est le nom du modèle qu’Anthropic juge trop dangereux pour un accès public. Sa spécialité : découvrir des failles zero-day sur les OS majeurs et les navigateurs de manière autonome, enchaîner plusieurs bugs en exploits complets, mener des opérations cyber complexes avec une intervention humaine minimale. Lors des tests internes, Mythos a sorti « des milliers » de vulnérabilités majeures. Bloomberg résume la chose sans fioriture : Mythos est très loin devant tout autre modèle IA en capacités cyber.

L’accès est censé être verrouillé. Un programme limité baptisé « Project Glasswing » a été ouvert à Apple, Amazon, Microsoft et Nvidia. Certaines agences gouvernementales américaines y ont accès. La CISA, elle, non. TechCrunch et Bloomberg rapportent le 21 avril qu’un petit groupe d’utilisateurs non autorisés a trouvé l’endpoint en devinant l’URL à partir des conventions habituelles de nommage d’Anthropic.

L’un d’eux est employé d’un sous-traitant tiers d’Anthropic. Les échanges se font dans un Discord privé dédié à la veille des modèles non publiés. Accès régulier depuis le jour de l’annonce. Pas d’usage offensif constaté à ce stade. Anthropic confirme l’enquête et dit ne voir « aucune preuve d’impact » sur ses systèmes.

Pourquoi c’est important pour toi

C’est la première fois qu’un modèle publiquement documenté comme capable de trouver des failles en série échappe au périmètre prévu. Pour l’instant, les intrus font de la veille. Mais la capacité est entre des mains qui n’auraient jamais dû l’avoir, avec un employé de sous-traitant dans la boucle. L’histoire des armes numériques a une constante : elles partent de cibles d’État, elles finissent sur des sites de phishing crypto visant des particuliers. Une IA qui trouve des zero-days toute seule, ça valait des milliards il y a cinq ans. Ça vient de fuiter dans un Discord.

Concrètement, la technologie qui peut sécuriser macOS demain, c’est celle qui peut aussi produire un exploit iOS utilisable par un acteur sans budget NSA. Anthropic trouve « des milliers » de vulnérabilités en interne, ça veut dire que le stock n’est pas un problème. La CISA, qui coordonne la réponse cyber aux États-Unis, n’est pas dans la boucle. L’autorité régulatrice australienne surveille la situation. Bloomberg a même titré un épisode de son podcast sur le sujet : « Will Mythos Save or Break the System? ».

Ce que tu dois faire

1. Maintenant : mets ton Mac, ton iPhone et Safari à jour. Mythos cible les OS majeurs et les navigateurs, les patchs déjà déployés ferment autant de portes qu’une IA curieuse pourrait pousser. Ce n’est pas du zèle, c’est de l’hygiène.

2. Active les mises à jour automatiques : Réglages → Général → Mise à jour logicielle → tout cocher (téléchargement + installation + Réponses Rapides de Sécurité). Sur Mac et sur iPhone. Le prochain patch critique tombera peut-être un mardi à 23h, tu n’as pas envie d’en dépendre.

3. Filtre les vecteurs invisibles sur iPhone : Réglages → Messages → “Filtrer les expéditeurs inconnus”. Réglages → Téléphone → “Filtrer les appels inconnus”. Ça neutralise les portes que les exploits de type Pegasus utilisent pour atteindre un téléphone : un iMessage ou un appel FaceTime d’un numéro que tu ne connais pas.

4. Méfie-toi des liens et des pièces jointes : pas pendant quelques semaines, à partir de maintenant et durablement. Un mail “facture en attente” qui pousse une PJ piégée n’a plus besoin d’un développeur expert pour être armé.

5. À surveiller : l’évolution de l’enquête Anthropic, l’arrivée éventuelle de CVE iOS/macOS sans auteur revendiqué dans les prochaines semaines, les déclarations de la CISA quand elle sortira du silence.

Sources

TechCrunch — 21 avril 2026
Bloomberg — 21 avril 2026
Axios — 21 avril 2026
Bloomberg — background Mythos — 16 avril 2026

GPT-5.5 passe en capacity-class cybersec. OpenAI serre les accès.

Mac Souverain — Sun, 26 Apr 2026 16:36:14 GMT

OpenAI classe officiellement GPT-5.5 en capacité cybersec « High ». Le modèle soutient des campagnes de recherche de failles sur plusieurs jours, produit les briques de base d’un exploit mémoire crédible sur des systèmes blindés et sature les compétitions de hacking pro. OpenAI a durci ses filtres à l’entrée et restreint l’accès aux modes où l’IA enchaîne plusieurs failles toute seule.

Ce que tu dois surveiller

1. Garde ton Mac et ton iPhone strictement à jour. La fenêtre entre publication d’un bug et exploitation IA-assistée se referme.

2. Réduis ta surface d’attaque navigateur (Safari, extensions au minimum, pas de Chrome sur le Mac principal).

3. Sur les appareils exposés (cadre, journaliste, militant), active Lockdown Mode, pas pour GPT-5.5 en particulier, pour la classe d’outils qu’il annonce.

4. Suis les deux prochaines system cards majeures (OpenAI, Anthropic). C’est là qu’on verra si la barre Critical cybersec tombe en 2026.

OpenAI a sorti GPT-5.5 le 23 avril et publié en même temps sa system card. Le document officialise ce que Mythos avait ouvert à la porte d’à côté : les grands modèles sont entrés dans la classe « cybersec High ». Ils ne franchissent pas encore la barre « Critical », mais la marge se réduit vite.

Ce qui se passe

Dans la taxonomie Preparedness d’OpenAI, la cybersécurité est découpée en trois paliers. « Medium », c’est un modèle qui aide un attaquant à aller plus vite. « High », c’est un modèle qui amplifie des chemins d’attaque sévères existants. « Critical », c’est un modèle qui ouvre des chemins qu’aucun humain ne pouvait emprunter seul, typiquement, produire des exploits zero-day fonctionnels, de manière autonome, sur des systèmes durcis en production.

GPT-5.5 franchit le seuil « High ». La system card détaille pourquoi : sur VulnLMP (le banc de test interne de recherche de vulnérabilités), le modèle mène des campagnes de recherche de failles qui durent plusieurs jours, identifie des bugs mémoire exploitables dans des systèmes pourtant blindés et construit les briques de base d’un exploit fonctionnel. Ce qui le sépare encore de « Critical » n’est pas l’ampleur de la recherche, c’est le jugement, savoir lequel des mille crashs mérite qu’on y passe la semaine.

Sur les terrains de jeu fermés, GPT-5.5 sature les compétitions de hacking pro, résout 7 sur 11 des scénarios CyScenarioBench (contre 5 sur 11 pour GPT-5.4) et monte à 93,33 % de réussite sur les terrains d’entraînement cybersécu. Le coût par succès est divisé par 2,7 à 3. Pour OpenAI, ça justifie un durcissement, filtres plus stricts à l’entrée, plus de refus sur les demandes cybersec, accès restreint aux modes où l’IA enchaîne plusieurs failles toute seule.

Pourquoi c’est important pour toi

Le grand public regarde GPT-5.5 comme une mise à jour marketing. Lu avec les bonnes lunettes, c’est un jalon de capacité offensive. En six mois, on passe de « les IA aident un humain à écrire un exploit » à « les IA mènent des campagnes de recherche sur plusieurs jours et produisent les briques d’un exploit utilisable ». La system card est explicite : ce n’est plus théorique, c’est mesuré.

Le modèle lui-même reste encadré. Ce qui l’est déjà moins, ce sont les modèles concurrents en libre téléchargement qui avancent en parallèle, et leurs versions retravaillées qui circulent chaque semaine sur les plateformes communautaires. Pour un amateur qui télécharge un modèle open source de niveau équivalent dont les filtres ont été retirés, la marche est moins haute qu’on ne le croit.

Côté Anthropic, ce qu’on sait de Mythos suggère qu’il est déjà dans cette zone, le modèle reste juste sous clé (enfin, quand il ne fuite pas. Oups, c’est fait !) Côté OpenAI, GPT-5.5 est encore un cran en dessous, mais la marge se réduit. Le seuil devrait être franchi à la prochaine system card publique, dans six à neuf mois.

Côté Apple, la conséquence directe est évidente. Un modèle capable de pister des bugs mémoire dans des systèmes blindés s’intéresse, par définition, à ce que fait Apple en blindage iOS (mémoire protégée contre les manipulations depuis iPhone 15 Pro et Mac M2, isolation des apps sur macOS, système verrouillé en lecture seule). Tant qu’Apple garde l’avance sur la surface d’attaque, ton Mac à jour reste très difficile à prendre, mais l’écart se joue maintenant en semaines, pas en mois.

Ce que tu dois faire

1. Immédiat : mets à jour macOS, iOS, Safari, et tous tes navigateurs tiers. L’écart entre publication d’un CVE et exploitation assistée par IA s’est contracté, chaque patch compte davantage qu’il y a six mois.

2. Réduis ta surface d’attaque navigateur : Safari en mode strict, extensions au minimum, et surtout pas de Chrome sur le Mac principal.

3. Si tu es exposé (journaliste, militant, cadre dirigeant, détenteur de crypto) : active Lockdown Mode sur iPhone et Mac.

4. À surveiller : les deux prochaines system cards OpenAI et Anthropic. Si l’une des deux bascule en « Critical » cybersec dans une system card publique, c’est le moment de relire tes pratiques de mise à jour et de sauvegarde, pas de paniquer, mais de serrer fort le curseur.

Sources

OpenAI, GPT-5.5 System Card, 23 avril 2026
OpenAI, GPT-5.5 System Card (hub principal), 23 avril 2026
CNBC, OpenAI annonce GPT-5.5, 23 avril 2026
TechCrunch, GPT-5.5 superapp, 23 avril 2026

Voir aussi

Le modèle qui trouve des failles tout seul vient de fuiter, 21 avril 2026
Claude Opus transforme un bug en exploit pour 22 dollars, avril 2026

Une IA grand public a fabriqué un exploit Chrome pour 2 283 dollars

Mac Souverain — Wed, 22 Apr 2026 16:02:04 GMT

Un chercheur a demandé à Claude Opus 4.6, le même modèle accessible à n’importe qui pour un abonnement mensuel, de fabriquer le code pour exploiter un bug Chrome corrigé. Résultat : Discord ouvre la calculatrice de ton Mac sans ta permission. Convention des chercheurs en sécurité : si calc s’ouvre sans te demander, n’importe quoi peut s’ouvrir. Discord, Slack, Teams, Notion tournent toutes sur Chrome sous le capot et patchent avec retard. Facture de l’opération : 2 283 $.

Ce que tu dois faire

1. Mets à jour Chrome, Safari, Firefox, Edge sur ton Mac ce soir.

2. Ouvre Discord, Slack, Teams et vérifie qu’ils tournent sur la dernière version.

3. Désinstalle toute app abandonnée (pas de mise à jour depuis plus de 6 mois).

Un chercheur a demandé à Claude Opus 4.6, le même modèle accessible à n’importe qui pour un abonnement mensuel, de fabriquer le code pour exploiter un bug Chrome corrigé. Facture : 2 283 dollars, 20 heures, et Discord qui ouvre la calculatrice de ton Mac sans ta permission. C’est la convention des chercheurs en sécurité pour dire : si on peut ça, on peut tout.

Ce qui se passe

Point de départ : un bug dans Chrome, corrigé et rendu public. Dans le monde de la sécurité, “corrigé publiquement” veut dire que la nature exacte du problème est désormais accessible à tout le monde, dans la base officielle de Google. Pas un secret, un défaut connu, documenté, dont le correctif est lisible par n’importe qui.

Mohan Pedhapati, chercheur en sécurité chez Hacktron, a soumis ce bug à Claude Opus 4.6 avec une question simple : construis-moi le code pour l’exploiter.

Résultat après 20 heures et 1 765 échanges avec le modèle : un programme qui s’exécute dans Discord et ouvre la calculatrice de ton Mac. Pas de vol de données, pas de destruction. La calculatrice. C’est la tradition des chercheurs en sécurité : quand ils veulent prouver qu’une faille permet à quelqu’un de faire tourner un programme sur ta machine sans ta permission, ils le prouvent en ouvrant calc. Inoffensif, mais éloquent : si quelqu’un peut ouvrir la calculatrice sans te demander, il peut aussi bien lancer n’importe quoi d’autre.

Facture totale : 2 283 dollars. Le modèle qui compte les calories de tes recettes peut aussi, avec guidage et patience, écrire un exploit navigateur.

Pourquoi c’est important pour toi

“Dans Discord” n’est pas anodin. Discord, Slack, Teams, Notion, Spotify, VS Code : aucune de ces apps n’est une application native. Ce sont des apps web déguisées, construites sur le moteur de Chrome. Résultat concret : quand Chrome corrige un bug, ces apps continuent à tourner sur l’ancienne version jusqu’à ce qu’elles se mettent à jour de leur côté. Discord tournait encore sur une version vulnérable de Chrome quand Pedhapati a publié son exploit. Le correctif officiel était disponible depuis des semaines.

L’implication est large. Avant cette étude, transformer un bug corrigé en exploit fonctionnel demandait des années d’expertise pointue. Maintenant, ça demande 2 283 dollars et quelqu’un qui sait poser les bonnes questions à un modèle. La liste des bugs Chrome corrigés est publique. La liste des apps qui traînent en retard de patch aussi.

C’est exactement ce que Schneier décrivait comme inévitable à propos de Mythos, et il arrive, pas avec un modèle militaire.

Ce que tu dois faire

→ Immédiat : mets à jour Chrome, Safari, Firefox, Edge sur ton Mac ce soir. La dernière version de Chrome corrige le bug précis utilisé dans l’étude, mais l’intérêt de l’affaire, c’est qu’il y en aura d’autres du même type. Sinon tu fais comme moi : tu désinstalles Chrome et tu passes à Safari. Mais c’est une autre conversation.

→ Cette semaine : passe en revue les apps “web déguisées” sur ton Mac. Discord, Slack, Teams, Notion, Spotify, VS Code, 1Password desktop si tu l’utilises encore. Pour chacune, vérifie dans les préférences que la mise à jour automatique est activée et que tu tournes sur la dernière version. Une app abandonnée ou rarement mise à jour devient une cible de choix.

→ À surveiller : la réaction de Discord, Slack et consorts sur la fréquence de mise à jour de leur moteur interne. L’arrivée de services commerciaux qui packageraient ce type d’expérimentation, aujourd’hui un chercheur en labo, demain un produit sur le darknet. Les premières campagnes réelles utilisant un exploit navigateur assisté par IA contre des apps mal maintenues. Si ça arrive, ce sera une autre conversation.

Sources

Security Affairs — 20 avril 2026
Étude Hacktron — Pedhapati — 20 avril 2026
Schneier on Mythos — 13 avril 2026 (contexte)

Voir aussi

[[radar-extensions-chrome-malveillantes-avril-2026|Extensions Chrome malveillantes]]
[[radar-tcc-macl-avril-2026|TCC macOS : contournement permissions]]
[[radar-agents-ia-anssi-avril-2026|Agents IA : risques ANSSI]]

Post Mastodon

🚨 Claude Opus 4.6 (abonnement grand public) a fabriqué un exploit Chrome fonctionnel.

Convention des chercheurs en sécu : prouver une faille en ouvrant la calculatrice de la machine cible. Si calc s’ouvre sans ta permission, n’importe quoi peut s’ouvrir.

Résultat ici : Discord ouvre ta calculatrice sans autorisation. 20h de travail, 1 765 échanges avec le modèle, pour 2 283 $.

Discord, Slack, Teams, Notion tournent sur Chrome sous le capot. Elles patchent avec retard.

1️⃣ Maj Chrome, Safari, Firefox, Edge ce soir
2️⃣ Maj Discord, Slack, Teams, Notion, VS Code
3️⃣ Désinstalle les apps abandonnées

Pas le Claude Mythos de la NSA. Le Claude de tes recettes, ça fout les jetons.

https://macsouverain.com/radar-claude-opus-exploit-2283-avril-2026/

IA #sécurité #Chrome #Mac

Vérification d'âge EU, hackée en 2 minutes, la surveillance mal codée

Mac Souverain — Wed, 22 Apr 2026 10:19:10 GMT

L’app de vérification d’âge de la Commission européenne, lancée le 14 avril, a été contournée en moins de deux minutes. Config éditable, booléen pour la biométrie, PIN non lié au vault d’identité. Le standard EUDI Wallet prévoyait du zero-knowledge (SD-JWT VC, IRMA/Yivi, AnonCreds). L’implémentation l’ignore.

Le vrai scandale

L’UE a écrit le bon standard. L’app de référence l’a trahi.

À surveiller, même architecture EUDI utilisée demain pour permis, ordonnances, fisc, 450 millions d’Européens.

L’app de vérification d’âge de la Commission européenne, lancée le 14 avril 2026, a été contournée en moins de deux minutes. Le vrai scandale n’est pas le bug, c’est le choix d’implémentation.

Les faits

Le 14 avril, la Commission dévoile son app de vérification d’âge, pilier du dispositif de protection des mineurs en ligne dans les 27 États membres. Trois jours plus tard, le consultant britannique Paul Moore publie une démo, bypass complet en moins de deux minutes. Le cryptographe français Olivier Blazy confirme le diagnostic. Un moratoire signé par 400+ chercheurs avait déjà alerté en mars. Personne n’a écouté.

Les trois failles

Config éditable, le PIN chiffré est stocké dans eudi-wallet.xml, modifiable localement.
Biométrie en booléen, un flag true/false gouverne l’auth biométrique. Flip, skip.
PIN non lié au vault, un attaquant redéfinit le PIN en réutilisant les credentials d’un profil précédent.

L’alternative existait, dans le standard lui-même

Le standard EUDI Wallet prévoit la divulgation sélective via SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credentials), prouver qu’on est majeur sans révéler sa date de naissance, ni lien entre deux sessions, via des preuves à connaissance nulle. Des implémentations tournent déjà en production, IRMA/Yivi (Radboud University), AnonCreds (Hyperledger), Google ZK age assurance.

L’UE a écrit le bon standard. L’app de référence l’a trahi en stockant le PIN dans un XML éditable.

Le pattern

Même logique que Chat Control / CSAR, Bruxelles pousse une infrastructure de surveillance, personne n’audite en amont, faille de niveau débutant. L’EUDI Wallet gérera bientôt permis, ordonnances, signatures fiscales de 450 millions d’Européens. Une faille triviale aujourd’hui n’est pas un incident, c’est un avertissement.

Souveraineté numérique, c’est le droit de ne pas prouver son âge à chaque clic. Et si on doit le prouver, alors par ZKP, pas par un XML modifiable au doigt mouillé.

Sources

Le FBI a récupéré des messages Signal effacés. Merci les notifications iPhone.

Mac Souverain — Tue, 21 Apr 2026 06:20:56 GMT

Le FBI a reconstruit des messages Signal déjà supprimés en passant par les notifications push iPhone. Apple conserve ces métadonnées et les remet sur mandat. Le chiffrement de bout en bout de Signal n’y change strictement rien, parce que la fuite se passe ailleurs.

Ce que tu dois faire

1. Signal : Settings → Notifications → « No Name or Content » — l’app n’injecte plus rien dans le payload push.

2. iOS : Réglages → Notifications → Aperçus → Jamais — tu coupes le contenu pour toutes les apps d’un coup.

3. Vérifie les autres apps de messagerie (Messages, WhatsApp) : même réglage à appliquer.

Un document judiciaire américain vient confirmer ce que les chercheurs en privacy répètent depuis 2023 : les notifications push iPhone sont une porte d’entrée pour remonter le contenu de messages chiffrés, même quand l’utilisateur les a supprimés. Signal fait correctement son boulot. Apple aussi, techniquement. C’est la combinaison des deux qui te trahit.

Ce qui se passe

Début avril 2026, 9to5Mac publie le détail d’une affaire fédérale américaine. Le FBI enquête sur un individu, demande à Apple les données de notifications push liées à son compte iCloud, et reconstruit ainsi le contenu de messages Signal reçus que la cible avait pourtant effacés de son appareil.

Le mécanisme est simple. Quand un message arrive sur Signal, l’app déclenche une notification push. Cette notification transite par APNs, le service de notifications d’Apple. Si l’utilisateur a laissé l’aperçu par défaut, le contenu du message part en clair dans le payload de la notification. Apple conserve ces métadonnées de notifications pendant une durée qu’Apple ne précise pas, et, sur mandat judiciaire, les remet aux autorités.

L’EFF a publié le 16 avril une analyse complète du problème. Le constat est net : ce n’est pas un bug Signal, ce n’est pas un bug Apple, c’est l’architecture même du système de notifications qui crée un angle mort. Signal chiffre ses messages de bout en bout. Apple livre la notification. Entre les deux, il y a un relais serveur qui voit passer le contenu si tu ne l’as pas verrouillé à la source.

Le sénateur Ron Wyden avait déjà tiré la sonnette en décembre 2023, en révélant que le gouvernement américain demandait couramment ces données à Apple et Google. Trois ans plus tard, on a enfin la preuve que la technique a été utilisée pour remonter des conversations Signal. Et que ça marche même après suppression côté utilisateur.

Pourquoi c’est important pour toi

Tu peux avoir le meilleur chiffrement de bout en bout du monde. Si la notification qui atterrit sur ton écran de verrouillage contient la phrase « Rendez-vous à 21h à l’adresse habituelle », cette phrase existe quelque part sur un serveur Apple avant d’arriver chez toi. Et ce « quelque part » est accessible sur mandat.

Ce n’est pas un scénario pour journalistes dissidents ou activistes. C’est le fonctionnement par défaut de ton iPhone aujourd’hui. Aperçus de notifications activés, nom de l’expéditeur affiché, première ligne du message lisible depuis l’écran verrouillé. Pratique, très pratique. Aussi pratique pour toi que pour n’importe quel acteur institutionnel.

Le point qui pique particulièrement : ça survit à la suppression. Tu effaces la conversation sur Signal, elle disparaît de ton téléphone, et elle n’a jamais existé côté serveurs Signal. Parfait.

Mais la notification qui annonçait ce message, elle, a laissé une trace chez Apple. La trace est plus volatile que tes emails, mais elle est suffisante pour reconstituer une conversation si la demande arrive dans la bonne fenêtre temporelle.

Le cas 9to5Mac concerne le FBI et un individu poursuivi aux États-Unis. Mais le mécanisme est universel. N’importe quelle autorité qui peut contraindre Apple à livrer des données iCloud peut en principe accéder à ces métadonnées. Juridiction américaine, CLOUD Act, pas besoin de schéma.

Le paradoxe est cruel. Tu as choisi Signal pour la privacy max. Tu as activé les messages éphémères. Tu as été discipliné. Et tu es trahi par un réglage iOS que personne ne t’a jamais présenté comme une question de sécurité.

Ce que tu dois faire

Deux réglages, cinq minutes, et la fuite est bouchée.

1. Immédiat : Signal > Settings > Notifications > « No Name or Content ». L’app cesse d’injecter le nom de l’expéditeur et le contenu dans la notification. Tu sais qu’un message Signal est arrivé, tu ne sais plus ni de qui ni quoi avant d’ouvrir l’app.

2. Dans la semaine : iOS > Réglages > Notifications > Aperçus > Jamais. Tu coupes les aperçus de contenu pour toutes les apps d’un coup, y compris Messages, Mail, WhatsApp et le reste. Confort légèrement dégradé, surface d’exposition énormément réduite.

3. Si tu veux aller plus loin : prends trente minutes pour faire le tour complet des réglages privacy de macOS et iOS. La plupart des angles morts se règlent une fois et tiennent des années.

À lire : Privacy macOS, les paramètres à changer immédiatement

Des termes techniques ? Consulte le glossaire.

Sources

Ton Mac affiche « Aucun accès » pour une app, mais elle lit quand même tes fichiers. Depuis 2019

Mac Souverain — Fri, 17 Apr 2026 06:06:48 GMT

macOS grave un accès permanent sur tes fichiers quand une app utilise le sélecteur Open/Save natif. Cet accès est distinct des réglages Confidentialité & Sécurité. Tu révoques l’app dans les réglages, elle disparaît de la liste, et elle continue quand même à lire tes fichiers. Depuis 2019.

Ce que tu dois faire

1. Vérifie quelles apps ont touché tes dossiers protégés via Terminal : xattr -l ~/Desktop | grep com.apple.macl

2. Pour révoquer un accès fantôme : copie le fichier sur un autre volume, supprime l’original, recopie, l’attribut ne suit pas.

3. Revois les réglages privacy de ton Mac avec notre guide dédié, en gardant en tête que ces réglages ne couvrent pas ce mécanisme.

Quand tu ouvres un fichier via le sélecteur natif d’une app, macOS grave un attribut directement sur le fichier. Cet attribut accorde à l’app un accès permanent, indépendant des réglages Confidentialité & Sécurité. Tu peux révoquer l’app dans les Réglages Système, l’interface affichera « Aucun accès », et l’app continuera de lire. Depuis 2019. Sans que tu le saches.

Ce qui se passe

Howard Oakley, chercheur macOS reconnu et auteur du blog Eclectic Light, a publié début avril 2026 une démonstration qui tient en une phrase : l’interface Confidentialité & Sécurité de macOS ment sur les accès réels des applications à tes fichiers.

Le mécanisme s’appelle com.apple.macl. C’est un attribut étendu, un petit marqueur que macOS colle directement sur le fichier ou le dossier ciblé. Il est créé automatiquement quand tu utilises le sélecteur Open/Save d’une app, quand tu fais un glisser-déposer depuis le Finder, ou quand tu double-cliques sur un fichier pour l’ouvrir avec une app.

Cet attribut contient deux identifiants : un pour l’app, un pour le fichier. Une fois gravé, l’app peut accéder au fichier sans repasser par la case permission. C’est géré par le noyau (Sandbox.kext), pas par le système TCC classique qui alimente les réglages que tu vois dans Réglages Système.

Et c’est là que ça coince. Réglages Système > Confidentialité & Sécurité lit uniquement la base de données TCC. Elle ne voit pas les attributs com.apple.macl. Résultat : tu révoques l’accès d’une app dans les réglages, l’interface affiche « Aucun accès », et l’app conserve son accès via le xattr. Oakley l’a démontré avec son outil de test Insent, notarisé par Apple, reproductible par n’importe qui.

Pourquoi c’est important pour toi

Ce n’est pas un bug. Apple a présenté ce mécanisme à la WWDC 2019 (Session 701) sous le nom “User Intent”, en opposition au “User Consent” classique du système TCC. L’idée : quand tu choisis explicitement un fichier dans le sélecteur, ton geste vaut autorisation permanente. Pas besoin de redemander.

Le problème n’est pas le principe. C’est que l’interface censée te montrer qui a accès à quoi ignore complètement ce canal. Tu penses avoir un tableau de bord fidèle de tes autorisations. En réalité, tu regardes la moitié du tableau.

Et ce mécanisme est actif depuis macOS Catalina (2019). Sept ans. Confirmé fonctionnel sur Tahoe (macOS 26). Jamais documenté publiquement par Apple de manière complète. Jeff Johnson, développeur macOS, écrivait en 2019 : “there’s no documentation of this important privacy protections change.”

Concrètement, ça veut dire que chaque fois que tu as utilisé Open/Save, glisser-déposer ou double-clic pour accéder à un fichier dans Desktop, Documents ou Downloads, l’app a potentiellement reçu un accès persistant que les réglages macOS ne reflètent pas.

Un thread Hacker News à 511 points confirme l’ampleur de la surprise dans la communauté technique. Plusieurs développeurs rapportent qu’Apple aurait classé le comportement comme “expected behavior” quand il a été signalé.

Ce que tu dois faire

Concrètement :

1. Vérifie si tes dossiers protégés portent des attributs macl. Ouvre Terminal et tape : xattr -l ~/Desktop | grep com.apple.macl Répète pour ~/Documents et ~/Downloads. Si tu vois des résultats, des apps ont un accès persistant invisible dans les réglages.

2. Pour révoquer un accès macl sur un fichier sensible, la méthode la plus accessible : copie le fichier vers un autre volume (clé USB, disque externe, autre partition), supprime l’original, recopie le fichier. La copie n’hérite pas du xattr com.apple.macl. C’est artisanal, mais ça fonctionne.

3. L’alternative technique : démarrer en mode Recovery et lancer xattr -d com.apple.macl <chemin_du_fichier>. Ça nécessite de désactiver SIP temporairement, ce qui n’est pas anodin. À réserver aux utilisateurs qui savent ce qu’ils font.

4. Ce qui ne suffit pas : tccutil reset All <bundle_id> suivi d’un redémarrage. Cette commande réinitialise la base TCC, pas les xattr macl. Oakley lui-même le reconnaît dans son article. Le redémarrage seul ne change rien non plus, l’attribut est gravé dans le système de fichiers, il survit au reboot.

5. Revois les réglages privacy de ton Mac. Ils restent utiles pour contrôler le canal TCC (localisation, micro, caméra, contacts). Mais garde en tête qu’ils ne couvrent pas ce second canal d’accès.

L’article #16 te guide à travers les réglages que tu contrôles. Ce Radar te montre ceux que tu ne contrôles pas, du moins pas depuis l’interface prévue à cet effet.

À lire : Privacy macOS, les paramètres à changer immédiatement

Des termes techniques ? Consulte le glossaire.

Sources

Eclectic Light, Why you can’t trust Privacy & Security, Howard Oakley, 10 avril 2026
Apple WWDC 2019 Session 701, Advances in macOS Security, 2019
XPN InfoSec, We Need To Talk About MACL, ~2020
Hacker News, discussion (511 points), avril 2026
lapcatsoftware, Persistent File Access via com.apple.macl xattr, Jeff Johnson, 2019

108 extensions Chrome piégées, ton Google et ton Telegram avec

Mac Souverain — Thu, 16 Apr 2026 06:37:00 GMT

108 extensions malveillantes ont été identifiées dans le Chrome Web Store, avec environ 20 000 installations cumulées. Elles volent les tokens Google et Telegram, et installent des backdoors. Google a été notifié mais les extensions étaient encore en ligne à la publication du rapport. Si tu as installé une extension Chrome récemment, le mal peut être déjà fait.

Ce que tu dois surveiller

1. Passe en revue tes extensions Chrome et désinstalle tout ce que tu n’utilises pas vraiment.

2. Déconnecte tes sessions Google actives depuis myaccount.google.com, section Sécurité.

3. Révoque les sessions Telegram depuis Paramètres, Appareils, sur n’importe quel client.

4. Considère sérieusement Safari pour ta navigation par défaut sur Mac.

Source : 108 Chrome Extensions Linked to Data Exfiltration (Socket, 2026-04)

Mi-avril 2026, les chercheurs de Socket identifient 108 extensions Chrome malveillantes dans le Chrome Web Store, avec environ 20 000 installations cumulées. Vol d’OAuth Google, backdoors universelles, exfiltration Telegram. Les extensions étaient encore en ligne lors de la divulgation publique. Si tu utilises Chrome sur Mac, et la plupart des utilisateurs Mac le font, tu es directement concerné.

Ce qui se passe

Les chercheurs de Socket ont identifié 108 extensions publiées dans le Chrome Web Store sous cinq alias d’éditeurs différents (Yana Project, GameGen, SideGames, Rodeo Games, InterAlt) pour brouiller les pistes. Divulgation publique le 13 avril 2026. Les extensions étaient encore en ligne malgré la notification de Google.

Le butin est varié, et assez précis pour un travail de masse. 54 extensions récupéraient les tokens OAuth Google, ces petites clés qui permettent à un service tiers d’accéder à ton compte Google sans que tu retapes ton mot de passe.

45 autres contenaient une backdoor universelle qui ouvre des URL arbitraires dès le lancement du navigateur, un canal parfait pour pousser du phishing ou du contenu malveillant à la demande.

Et une extension dédiée exfiltrait le token de session Telegram Web toutes les 15 secondes, en vidant localStorage vers un serveur de contrôle. De quoi te voler un compte messagerie sans même que tu t’en aperçoives.

Environ 20 000 installations cumulées. C’est de la collecte industrielle, qui ratisse large.

Pourquoi c’est important pour toi

Aucun 0-day macOS dans cette affaire. Pas de faille Apple Silicon, pas de bypass Gatekeeper. Le vecteur, c’est Chrome, et l’écosystème d’extensions qui tourne dessus.

Et Chrome, sur Mac, c’est le navigateur par défaut d’une bonne partie des utilisateurs, y compris des professionnels qui gardent Safari pour le reste. Tu synchronises tes onglets avec Google, tu laisses Chrome gérer ton autofill, tu installes trois extensions pour ton workflow, et tu oublies.

Les extensions ont accès à tes onglets, à tes cookies, à ce qui circule dans les formulaires. Quand l’une d’elles devient malveillante, elle peut lire ce que tu lis. Dans ce cas, la cascade est brutale.

Un token OAuth Google volé, c’est un accès potentiel à Gmail, Drive, Photos, Calendar, selon les scopes accordés. Un token Telegram exfiltré, c’est l’accès à tes conversations, tes groupes, tes canaux, tes fichiers partagés. Pas besoin de connaître ton mot de passe : le token est la session, et la session ouvre la porte.

Le Chrome Web Store n’est pas l’App Store. Google revoit les extensions, mais pas avec le même niveau d’exigence qu’Apple. Les mauvaises extensions passent, et passent souvent.

Ce que tu dois faire

Concrètement :

1. Ouvre Chrome, va sur chrome://extensions, et désactive tout ce que tu n’utilises pas au quotidien. Les extensions qui traînent depuis deux ans, au cas où, sont exactement la surface d’attaque que tu veux réduire.

2. Connecte-toi sur myaccount.google.com, section Sécurité, puis Vos appareils. Déconnecte toutes les sessions que tu ne reconnais pas. Pendant que tu y es, vérifie les applications tierces qui ont accès à ton compte Google, et révoque celles que tu ne reconnais pas.

3. Sur Telegram, va dans Paramètres puis Appareils (ou Sessions actives selon le client). Ferme toutes les sessions autres que celle que tu utilises. Si tu vois une session depuis un pays ou un appareil que tu ne reconnais pas, c’est déjà trop tard pour cette session-là, mais tu peux encore couper le flux.

4. Réfléchis à Safari comme navigateur par défaut sur Mac. Moins d’extensions disponibles, c’est aussi moins de surface d’attaque. Safari ne te protège pas magiquement, mais son modèle d’extensions est plus restrictif, et Apple contrôle la distribution via le Mac App Store pour la plupart d’entre elles.

Et la règle de fond, au-delà de cet incident : une extension de navigateur voit tout ce que ton navigateur voit. Installe-les comme tu installerais une app système, c’est-à-dire avec méfiance et parcimonie.

À lire : Privacy macOS, les paramètres à changer immédiatement

Des termes techniques ? Consulte le glossaire.

Sources

Socket Threat Research Team, 108 Chrome Extensions Linked to Data Exfiltration, Session Theft, Shared C2, 13 avril 2026
CyberInsider, 108 Chrome Extensions Caught Stealing User Data and Hijacking Sessions, 14 avril 2026

Google livre tes données à l'immigration — sans te prévenir

Mac Souverain — Wed, 15 Apr 2026 06:05:38 GMT

Google avait promis de te prévenir avant de livrer tes données aux autorités. Il ne l’a pas fait. Sur simple subpoena administratif d’ICE, sans mandat, sans juge, il a transmis les informations d’un journaliste étudiant. La notification est arrivée après. Le dossier était déjà parti.

Ce que tu dois surveiller

1. Tout compte Google avec ta vraie identité est exposable à une demande gouvernementale sans mandat ni préavis

2. Un subpoena administratif suffit : pas de juge, pas de recours possible avant la divulgation

3. La migration vers Proton Mail te sort de cette équation — guide complet ici

Sources : EFF Deeplinks · The Intercept

Agents IA sur Mac : l'ANSSI place Claude Cowork et OpenClaw en alerte

Mac Souverain — Tue, 14 Apr 2026 11:28:16 GMT

L’ANSSI vient de publier une alerte officielle sur les agents IA autonomes : OpenClaw et Claude Cowork sont nommément cités, parmi d’autres solutions open source. Ces outils exécutent des commandes, lisent tes fichiers, envoient des emails, et une page web malveillante peut les manipuler à ton insu. Autrement dit : les assistants IA sur ton Mac sont aussi des surfaces d’attaque.

Ce que tu dois faire

1. Désactive les accès de tes agents IA aux apps sensibles (email, calendrier, fichiers de travail) dans leurs réglages respectifs.

2. N’utilise pas Claude Cowork, OpenClaw ou tout agent autonome sur une machine contenant des données clients ou financières, tant qu’aucune supervision n’est en place.

3. Vérifie quelles applications sont accessibles à chaque agent IA installé sur ton Mac.

4. Je te prépare un guide complet pour réduire les risques : filtres automatiques, cloisonnement des accès, ce que tu peux désactiver sans perdre l’utilité de l’outil : Bientôt dans un tuto

L’ANSSI a publié le 13 avril 2026 une alerte officielle sur les agents IA autonomes sur postes de travail. OpenClaw et Claude Cowork sont nommément cités. Ces outils peuvent exécuter des commandes, lire et écrire des fichiers, envoyer des emails — et une injection de prompt suffit à les retourner contre toi.

Je te prépare un guide complet pour réduire les risques : filtres automatiques, cloisonnement des accès, ce que tu peux désactiver sans perdre l’utilité de l’outil. À suivre.

Sources

ANSSI / CERT-FR, Vulnérabilités et risques des produits d’automatisation par IA agentique sur les postes de travail, 2026-04-13