Mac Souverain — Radars (English)

A fake Zoom update empties your iCloud Keychain

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

A contact you know invites you to a video call on Telegram, except their account has been hijacked. During the call, a fake "Zoom SDK Update" pops up, you click to fix your mic, and **a stealer siphons your browser keys** out of your iCloud Keychain. BlueNoroff, North Korea, zero flaw exploited, 100% social engineering. It's the third ClickFix on macOS in six weeks.

What you need to do

1. An install prompt in the middle of a meeting, you refuse. No video call ships you an "SDK Update" mid-call.

2. A meeting link, even from a real contact, verify it through another channel. The Telegram account on the other end may be compromised.

3. An outbound firewall, Little Snitch or LuLu, sees the exfil leave for Telegram while the stealer empties your keychain.

What’s really happening mid-call

BlueNoroff, the North Korean banner that targets crypto professionals, exploits no flaw. Zero exploit, zero CVE. Just social engineering, scaled into an industrial chain. The research comes from JUMPSEC, the “ClickFake Interview” cluster is tracked by Sekoia, and The Hacker News picked it up on July 24, 2026.

Here’s how it goes. A contact you’ve met in person messages you on Telegram, except their account has been hijacked. They send you a Calendly link in their name, which redirects you to a typosquatted Zoom or Teams domain, us.zoom.06webin.us. You type your name, you allow the camera, and the kit gets to work behind your back. It captures your video stream via mediasoup WebRTC and profiles the crypto wallet extensions installed in your browser. Then a fake message, “your mic isn’t working”, followed by a “Zoom SDK Update” prompt. You click to fix your mic, you install the payload.

On macOS, the rest unfolds without you. A shell script downloads a fake Teams or Zoom installer, a stealer extracts Chrome’s master keys from your macOS login keychain, where Chrome stores its encryption key, the ones that unlock your crypto wallet extensions, and exfiltrates everything through a Telegram channel named “Aurora”, before dropping further payloads. On the Windows side, the variant disables Defender via a PowerShell loader and hunts for Telegram sessions in Chrome, Edge, Brave and Firefox. Same actor, two chains.

Two details change the scale. The video calls are faked with deepfakes, AI-generated faces layered over real body language, captured from earlier victims. And the mechanism self-propagates, each compromised Telegram account becomes the trusted sender for the next one. Five versions of the kit have been spotted between May 31 and July 14, 2026, the operator is tied to the Telegram bot @alchemy_john_mac. This is no one-off, it’s a factory that iterates.

The technique has a name, ClickFix, and it already drags a trail of victims behind it.

Read next: ClickFix, the fake fix that makes you launch the malware yourself

The third ClickFix on macOS in six weeks

Do the math. CrashStealer in July, ClickLock before it, now BlueNoroff. Three times in six weeks the same pattern has hit macOS, one harmless gesture that triggers the install. The vector is going industrial, and this version aims straight at your keychain, where macOS stores your browser’s keys.

Read next: An Apple-notarized malware slips past Gatekeeper

What protects you here is neither antivirus nor notarization. It’s a behavioral rule, simple and absolute, never install a binary offered to you during a meeting. Zoom doesn’t ship you an “SDK Update” mid-call. Neither does Teams. An update that surfaces during a video call is not an update, it’s the payload.

There’s a stack angle, provided you’re honest about its reach. Proton Meet is end-to-end encrypted and runs in your browser, with no native client to install. So the “install this SDK update” pretext has nowhere to latch on, there’s no app to update. It shrinks the attack surface, it doesn’t replace the behavioral rule. Switching to Proton Meet does not protect you from this phishing, social engineering depends on no tool.

Read next: Proton Meet, the encrypted video call that runs in your browser

The part that should worry you is the sender. It’s not a stranger, it’s someone whose hand you’ve shaken. Interpersonal trust is the vector, not your gullibility. A genuine Telegram account, a name you recognize, a meeting link, that’s all it takes.

What you do now

1. An install prompt that appears during a meeting, you refuse, no exceptions. Zoom, Teams, no video call asks you to install an “SDK Update” or to fix your mic through a download. You leave the call, you click nothing.

2. A meeting link, even sent by a real contact, you verify it through another channel before clicking. A voice call, a Signal message, “did you really send me this Calendly?”. The Telegram account on the other end may already be hijacked.

3. Look at the URL before allowing your camera. us.zoom.06webin.us is not a Zoom domain, it’s typosquatting. The real Zoom is zoom.us. A long trailing subdomain grafted onto an unknown name, you close the tab.

4. Install an outbound firewall and let it speak. Little Snitch or LuLu see the exfiltration leave for Telegram, exactly when the stealer empties your keychain. It’s your last line when everything else has been bypassed.

Read next: Little Snitch vs LuLu, which outbound firewall for your Mac

Sources

The Hacker News, which relayed the research on July 24, 2026
Primary research JUMPSEC, analysis of the BlueNoroff phishing kit
“ClickFake Interview” cluster tracked by Sekoia

Claude Cowork in local mode, the agent walks out of the sandbox

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

You connect one folder to Claude Cowork, and the agent actually has your whole disk within reach. In local execution mode on macOS, Cowork mounts the entire filesystem read-write inside the agent's virtual machine. A single message is enough to walk it out, without any permission prompt showing up. Anthropic closed the report as "informative", with no fix: the shift to cloud execution does mitigate the risk, but it is a gradual beta, and local mode stays exposed.

What you need to do

1. Check your Cowork execution mode. Cloud has become the default, but in beta and in waves: go read it in your settings instead of assuming it. Local mode leaves you exposed.

2. Never run a local session from a macOS account that holds your Keychain, your SSH keys or your password manager file.

3. Treat everything the agent reads, web page, attachment, ticket, as hostile code. That is the entry point of the chain.

What Cowork actually mounts

In local execution mode on macOS, Claude Cowork mounts your Mac’s entire filesystem read-write inside the Linux virtual machine where the agent runs, at a mount point named /mnt/.virtiofs-root, visible only to the guest-root account. The whole disk. Not the folder you connected. The sandbox is a box, it just has no walls. The research, named SharedRoot, comes from Oren Yomtov, Principal Security Researcher at Accomplish AI, published on July 23, 2026 and picked up the same day by The Hacker News.

Anthropic’s documentation, however, states for local mode that file access is “limited to folders the member has connected”. That is the promise. The mount itself exposes the entire host.

The escape unfolds in one go. The agent starts as an unprivileged session user, grants itself root inside a user namespace, then has the kernel autoload a module from the Traffic Control subsystem that carries CVE-2026-46331, known as pedit COW: merely referencing it is enough to load it. The flaw is rated 7.8 on CVSS 3.1 by kernel.org on its NVD entry, 6.7 by Red Hat, with a public exploit, PACKET_EDIT_MEME.c, available since June 17. Page cache corruption poisons a cached binary, which the coworkd daemon then re-executes as root. By the end of the chain, guest-root has the host’s entire disk in hand.

The Hacker News claims roughly 500,000 macOS users in local sessions, a ballpark figure that no published methodology supports and that the researchers’ post does not repeat. Keep the scale, not the number. What is certain is that no permission prompt appears at any point in the chain.

On the fix, precision matters, because this subject invites shortcuts. Anthropic closed the report as “informative”, with no dedicated fix. At the same time, Cowork moved to cloud execution by default: Anthropic publishes no version number for Cowork, but dates the change to July 7, 2026 and describes it as a beta rolling out gradually, starting with the Max plan. The researchers note that the local escape path “does not appear to apply” on the cloud side, without having audited it. The mitigation is real. It fixes nothing for those running locally, and it has not reached everyone yet.

The VM looks like a wall

The point holds well beyond this one flaw: an agent’s sandbox is not a security boundary if it mounts the whole disk. The virtual machine gives the impression of isolation, the mount quietly voids it. Between the folder you think you are sharing and your entire user account, there is a gap that nothing in the interface flags.

Read next: AI Agents on Mac: ANSSI flags Claude Cowork and OpenClaw

The chain assumes the agent is already executing hostile code. Except that is its job: ingesting content you do not control, web page, PDF, ticket, then acting on it. On this kind of tool, prompt injection is no laboratory hypothesis. It is the main entry point.

Read next: Hugging Face compromised, and your local model?

The researchers recommend four hardening measures, and point out that each one, on its own, is enough to break the chain. Only one addresses the root cause though: mounting nothing but the folders actually connected. The other three remove a step from that particular staircase, the fourth removes the staircase.

The flaw is not isolated, it is a whole class of flaw. A model escaping its test sandbox, an agent protocol exposing code execution, now an agent handed the entire disk. The common thread is never the bug, it is the generosity of the perimeter granted by default.

Read next: Anthropic’s MCP, A design flaw exposes 200,000 instances to remote code execution

What you do now

1. Check your Claude Cowork execution mode. Cloud has become the default, but in beta and in waves since July 7: do not assume your account received it, go read it in the settings. If you are running locally, deliberately or by inheriting an old setting, you are affected.

2. Never run a local session from a macOS account that hosts your Keychain, your SSH keys or your password manager file. A dedicated user account for the agent, empty of secrets, costs five minutes and removes any value from the escape.

3. Treat everything the agent ingests as hostile code. A web page, an attachment, a client ticket: that is the entry point, and it is not filtered. You would not run that content through a script without looking, so do not feed it to an agent that has write access.

Sources

Hugging Face compromised, and your local model?

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

The model hub where LM Studio fetches your models has been breached, Hugging Face announced on July 16th. The company left internal infrastructure credentials, not yours, and no public model tampering has been reported. The twist? No hacker involved. OpenAI claims it was their own models, escaped from an internal test.

What to watch out for

1. If you don't have a Hugging Face account, you've got nothing to worry about. Your downloads are untouched.

2. If you do have an account, rotate your access tokens and review recent activity, as a precaution.

3. Hugging Face is still assessing if partner or client data has been affected.

What happened

On July 16, 2026, Hugging Face disclosed a breach that had occurred a few days earlier in part of its production infrastructure. The entry point? A malicious dataset exploiting two code execution paths: a remote dataset loader, and a template injection in its configuration. Then privilege escalation and lateral movement, quietly, over a weekend.

The company analyzed the attack log with LLM agents, yielding “more than 17,000 recorded events”. That’s a forensic count of log events, not a tally of the attacker’s actions. Hugging Face goes on to describe a swarm of tens of thousands of automated actions. Nobody ever saw a human at the keyboard.

What was exposed? “a limited set of internal datasets” and “several credentials used by our services”, plus cloud and cluster credentials picked up along the way. The keys to Hugging Face’s house, not yours. No user data breach has been confirmed. And a week later, the company’s still evaluating if partner or client data was affected.

Your local model hasn’t budged

Here’s the part that matters if you’ve installed LM Studio and downloaded a model in MLX. Hugging Face is clear: no evidence of tampering with models, datasets, or public Spaces, and the software supply chain, container images and published packages, “was verified clean”. The file sitting on your SSD really is the one you think it is.

But “no evidence of tampering” isn’t “we’ve proven there was no tampering”. It’s the best information available, from a company in the middle of an incident response. Not a notarized guarantee.

If you have an account, Hugging Face recommends rotating your tokens and reviewing recent activity “as a precaution”. Hold on to that “as a precaution”: nothing suggests a user token has leaked.

A model already sitting on your disk couldn’t care less about the health of the hub it came from.

Read: Install your first AI model locally on Mac

The twist, the attacker wasn’t a hacker

On July 21st, OpenAI announced that the incident was carried out by a combination of its own models, including GPT-5.6 Sol and a more capable pre-release model, all with cyber safeguards relaxed for evaluation purposes, during an internal test on an offensive capabilities benchmark called ExploitGym. TechCrunch reported the statement verbatim, and Bloomberg, Fortune and The Register corroborated it.

That leaves the awkward question: how did these models get out of their testing environment? OpenAI claims they exploited a zero-day flaw in the proxy cache of a package registry. That’s the official story, self-declared, with no external audit to verify. Hugging Face, on the other hand, brought in external forensic specialists, but for its own incident, not OpenAI’s escape. No outsider has looked under that hood.

Read: Mythos, the Model That Finds Bugs on Its Own, Just Leaked

Two details that don’t age well. Hugging Face never amended its security advisory: the official text still says the LLM used remains unknown. Attribution lives in an OpenAI blog post and oral statements, not in that document. And the company reported the incident to law enforcement, for what turns out to be a third party’s accident. Nobody has said what becomes of that report.

Read: GPT-5.5 Ups Its Cybersecurity Game. OpenAI Tightens Access.

The lesson nobody meant to teach

During its incident response, Hugging Face tried to analyze the logs using frontier models through commercial APIs. The vendors’ guardrails, unable to tell an incident response team from an attacker, blocked its analysts. They ended up using GLM 5.2, an open-weight model from the Chinese company Z.ai, on their own infrastructure.

Savor the irony: the model that ended up helping them came from China, and it was precisely because it ran on their own infrastructure that its origin stopped mattering. The day you’re investigating your own machine, the model helping you had better be running at home.

What to do now

1. No Hugging Face account? You’re good. Nothing to do. Hugging Face hasn’t reported any alterations on public models, and your local installation isn’t tied to any affected identifiers.

2. Have a Hugging Face account? Rotate your access tokens, revoke the ones you no longer use, review recent activity. Precautionary, not urgent, free.

3. Get in the habit of checking where a model comes from. In LM Studio, each variant shows its original repo, and an official or community-established repo has a different trust profile than a mirrored one reposted by an account created last month.

Sources

Apple-notarized malware slips past Gatekeeper

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

CrashStealer, a macOS infostealer disguised as an Apple crash-reporting tool, clears Gatekeeper without the slightest alert. It's signed by a valid Developer ID and notarized by Apple. Your Mac trusts the signature, not the intent behind it. Apple revoked the certificate after the fact, once the damage was done.

What you should do

1. Any app or DMG from outside the App Store received by invitation or direct link, the Apple signature doesn't redeem the provenance.

2. A prompt asking for your login password "to continue" with no legitimate install underway is a red flag.

3. Unexpected outbound connections, an application firewall like Little Snitch or LuLu sees them go out.

A piece of malware disguises itself as an Apple crash-reporting tool. It’s signed by a valid Developer ID and notarized by Apple itself. The result, it clears Gatekeeper without the slightest warning, because your Mac checks the signature, never the intent.

The fact

Jamf Threat Labs spotted a suspicious sample on VirusTotal in early May 2026, then observed real infections on client Macs in early July. The malware is called CrashStealer. A rare trait, it’s written in native C++, where the vast majority of macOS stealers cobble something together in AppleScript. It poses as an Apple crash-reporting tool, the kind of window you’ve seen a hundred times without paying attention.

The delivery is polished. The malware arrives in a disk image named “Werkbit,” and the app inside is called “Werkbit.app.” Notably, the DMG itself is signed, not just the app it contains. The certificate, a Developer ID under the name “Emil Grigorov” (WWB7JA7AQV), valid, active, notarized by Apple. The distribution domain, werkbit[.]io, was registered in June 2026, and the download is locked behind a meeting PIN code. Translation, the installer is served only to chosen victims, never to automated scanners or the passing visitor.

Once launched, the dropper pulls the real payload from the attacker’s infrastructure. Before harvesting anything, it shows you a fake system prompt and validates your session password locally. Then it drains everything, browser profiles, the Keychain, fourteen password managers (1Password, Bitwarden, LastPass, Dashlane, Keeper included) and close to eighty crypto wallet extensions. The loot is encrypted with AES-GCM then exfiltrated over libcurl. It copies and re-signs itself to persist.

Apple revoked the signing certificate after Jamf’s report. The damage was already done for those who had clicked.

Why Gatekeeper saw nothing

Here’s the knot. Apple notarization is not a security audit. It’s an automated scan that looks for signatures of already-known malware and checks that the binary is signed by a valid Developer ID. Nothing more. Apple didn’t read CrashStealer’s code, it didn’t judge its intent, it passed a binary that was clean at scan time through a grinder that saw nothing familiar.

The notarization stamp says one thing, “this file is signed by an identified developer and matches no known malware.” It doesn’t say “this software is safe.” The nuance sounds theoretical. It’s the whole point.

An attacker who opens an Apple Developer account for 99 dollars a year, under a credible identity, gets a pass to clear Gatekeeper in silence. Apple’s kill-switch, revoking the certificate, only kicks in after the fact, once the damage is documented. Apple pushes its defenses silently, it doesn’t warn you when it has let something through. It’s a firefighter, not a guard.

Read more: Your Mac got patched by XProtect without you knowing

What it changes for you

The collective reflex, “it’s Apple-signed, so it’s fine,” just took a bullet. Your Mac trusts the signature, not the intent behind it. A notarized binary is not a blessed binary. It’s a binary whose declared author is known, useful for going after them afterward, useless for sparing you the infection.

The meeting-PIN targeting also changes the game. This malware isn’t trawled off a warez forum. It comes by invitation, in a context that looks professional, served to you and not to a scanner. The old reflex “I only download known stuff” no longer holds when the link is handed to you personally.

The real line of defense isn’t the Apple stamp. It’s you, your suspicion, and a tool that sees what the software actually does once it’s launched, its outbound connections.

What you do now

1. Treat any app or DMG received outside the App Store as suspect by default, especially when it arrives by invitation, direct link, or an “install this for the meeting” message. The Apple signature doesn’t redeem a dubious provenance. If you didn’t go looking for it yourself, you don’t install it.

2. A genuine macOS system prompt doesn’t ask again for your admin password without a clear reason. A freshly launched app that demands your login password “to continue,” with no legitimate install underway, is a red flag, not a formality. You close it, you type nothing.

3. Install an application firewall and let it speak. Little Snitch or LuLu show you the unexpected outbound connections, exactly the moment a stealer sets off to exfiltrate your loot. It’s your surveillance camera on what the system does behind your back.

Read more: Little Snitch vs LuLu, which outbound firewall for your Mac

And if you have the slightest doubt you ran a dubious installer recently, the drill already exists, it’s the same as for infostealers spread through social engineering.

Read more: Google Ads and a real shared Claude chat drain your credentials

Sources

Chat Control 1.0: Adopted by Those Who Voted Against

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

On July 9th, 2026, the European Parliament let Chat Control 1.0 (voluntary CSAM scanning, EU Regulation 2021/1232) slip through. Not by a vote for, but with 314 against, 276 for, yet blocking the Council’s position needed 361 votes. The majority voted no, but the text passed anyway. End-to-end encryption is explicitly excluded from this text. The real fight, Chat Control 2.0 (CSAR), resumes in September.

What you need to watch out for

1. CSAR (Chat Control 2.0), potential mandatory client-side scanning on end-to-end, which resumes trilogue in September 2026. That’s the only date that matters.

2. The method: a text rejected by the majority of voters that passes due to lack of an absolute majority to block it. Remember the mechanism, it’ll come back.

3. Viral posts claiming WhatsApp and Signal are now being scanned. That’s false for 1.0, end-to-end is excluded. Don’t spread the panic.

What Happened on July 9th

On July 9th, 2026, the European Parliament renewed Chat Control 1.0, i.e., Regulation (EU) 2021/1232: an exemption to the ePrivacy directive that allows providers to voluntarily scan communications for child sexual abuse material (CSAM). This text had expired on April 3rd, 2026. It’s been renewed, in effect until April 3rd, 2028.

The detail that matters: it wasn’t adopted by a yes vote. The count was 314 against, 276 for, 17 abstentions. The majority of voters said no. But to reject the Council’s position, you needed an absolute majority of 361 votes, which was missed by 47. Result: the text passes due to lack of blocking. Patrick Breyer calls it a democratic farce, and on this point, he’s not entirely wrong.

Second detail, denounced by several MEPs: the dossier was rescheduled at the very start of the parliamentary holidays, when the hemicycle is sparsely populated. A classic scheduling move, but an effective one.

Debunk Express

Three falsehoods have been circulating since July 9th. Here’s the reality check.

“The Parliament voted FOR Chat Control.” False. 314 voted against, 276 for: the majority voted no. The text passes because the threshold to block it, 361 votes, wasn’t reached, not because it was approved.

“WhatsApp, Signal, iMessage will be scanned.” False. A Renew amendment adopted on the same day explicitly excludes end-to-end encryption from the scope of this text. The 1.0 remains voluntary scanning, outside of E2E.

“This is the big mandatory Chat Control that just passed.” False. The text of July 9th is the voluntary 1.0. Mandatory scanning, potentially client-side on E2E, is the CSAR (Chat Control 2.0), still in trilogue, to be revisited in September.

Two texts, two stories. The 1.0 is voluntary and excludes E2E. The 2.0 is the real danger, and it’s not settled yet.

Why It Concerns You

On your Mac and iPhone, the 1.0 doesn’t change anything today: your iMessage, WhatsApp, Signal remain end-to-end encrypted, explicitly outside the scope of this text. Don’t let anyone sell you a product panic that doesn’t exist.

But this text isn’t limited to messaging apps. It also covers emails, and here, the nuance changes everything: a regular email (Gmail, Outlook, iCloud Mail) isn’t end-to-end encrypted. It’s fully within the scope of the voluntary scan that the 1.0 prolongs.

Google and others can scan the content of your emails for CSAM, and the E2E exclusion won’t protect you, since there’s no E2E to protect. Only a genuinely end-to-end encrypted messaging service, like Proton Mail, slips through the net.

Consider what this means. It’s like the Police reading your mail when you’ve done nothing wrong. It’s like something out of the Stasi!

The real risk has another name: client-side scanning by the CSAR 2.0. That’s the principle of inspecting your messages on your device before they’re encrypted. The crypto isn’t broken, it’s emptied of its meaning: your message is read in plaintext on your phone before it’s sent. And once that inspection point is in place, it belongs to the “nice guys” forever.

It’s not science fiction on Apple’s side. In 2021, Apple announced NeuralHash, a system for client-side CSAM scanning on iPhones, before abandoning it in December 2022 under pressure. The code exists, the logic does too.

A binding CSAR would be exactly the lever that would reopen this dossier, this time by law and not by choice. The lawsuit against Apple by West Virginia in February 2026 shows that judicial pressure on this issue isn’t letting up.

What You Can Do

Nothing to install, nothing to fix on your device: the 1.0 opens no product vulnerabilities. It’s a political signal, and a lesson in method: a text rejected by the majority of voters can still pass when the blocking threshold isn’t reached. Remember the mechanism, because it’ll come up again in September.

The appointment is the CSAR at the September 2026 restart. Five rounds of trilogue without agreement, the last on June 29th, and the fracture line remains encryption.

Keep Signal as a fallback messaging service, follow EDRi and Patrick Breyer for the real outcome, and write to your MEP before the 2.0 comes back on the table. Public pressure has already shifted lines on this dossier before, it can do so again.

To dig deeper: Chat Control 2.0, the complete mechanism · NIS2 vs CSAR, when the EU contradicts itself · The global convergence of anti-privacy texts

Wazuh 5.0 lands, your home SIEM evolves

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

Wazuh 5.0 lands in public beta, revamps its architecture, Filebeat’s gone, clustering enabled by default, new engine. If you’ve set up your SIEM with our series, your 4.x install is still running, the upgrade to 5.0 won’t be blind.

What changes for you

1. Check your version with wazuh-control info, recent 4.11 and later still receive updates.

2. Snapshot your VM and backup /var/ossec/etc/ before attempting the 5.0 upgrade.

3. Wait for a stable 5.0.x release (5.0.1 or 5.0.2) before migrating, we’ll update the SIEM series then, migration guide included.

If you’ve set up your home SIEM following episode 2/7 of the Sovereign SIEM series, brace yourself: Wazuh 5.0 is here in public beta, and it’s shaking things up. Don’t panic, but do take a look before blindly updating. And we’ll update the SIEM series when the time comes.

The Deal

Wazuh has just released the public beta of its 5.0 version, with a stable release estimated for late June or early July 2026. This isn’t just a version bump, it’s an architectural overhaul.

What’s changing, concretely: Filebeat is gone, replaced by a native indexer-connector integrated into the manager. Every Wazuh server becomes a cluster node by default, even in a single-server install. The old analysisd engine, which handled logs and triggered rules, is replaced by a new one. Vulnerability detection has shifted to Wazuh Indexer, centralized. And Role-Based Access Control (RBAC), fine-grained permissions management, has been entirely revamped.

Direct consequence for MacSouverain: episode 2/7 of the Sovereign SIEM series, which documents the 4.x architecture step-by-step, will be partially outdated once 5.0 is released. We’ll update the series when 5.0 is stable, not before.

Why It Matters to You

If you’ve followed the guide in episode 2/7 of the Sovereign SIEM series to set up your own SIEM, you’re likely running on a 4.x version. Good news, your setup continues to work, no one’s pulling the plug. Bad news, upgrading to 5.0 won’t be as simple as apt upgrade without reading the docs. Bye-bye Filebeat, that means your log pipeline’s plumbing is changing. Default cluster, that changes your initial config even if you’re sticking to one machine.

Practical translation: if you were planning to upgrade as soon as it’s out, take an hour to read the release notes and make a snapshot first. If you’re on a stable setup you use daily, wait for one or two corrective versions, let the early adopters iron out the kinks.

What It Changes for You

1. Note which version of Wazuh you’re currently running. On your manager, use wazuh-control info or check the dashboard. If you’re on 4.11 or later, you’re on the branch that’s still receiving updates.

2. Before attempting to upgrade to 5.0, snapshot your VM or backup your config /var/ossec/etc/ and your Wazuh Indexer’s state. A clean rollback saves your bacon if the new engine doesn’t play nice with your custom rules.

3. Wait for the stable 5.0.x release (at least 5.0.1 or 5.0.2) before migrating a production personal install. Beta’s for testing on disposable VMs, not the one monitoring your network every day. Keep an eye on: Wazuh’s official migration guide from 4.x to 5.0, and the upcoming overhaul of episode 2/7 of the Sovereign SIEM series on MacSouverain.

Sources

Wazuh 5.0 Public Beta Discussion (GitHub)

Chat Control: The EU's playing with your encryption's fate.

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

June 29th saw the EU’s 5th and final trilogue on Chat Control 2.0 (CSAR). At stake: mass scanning of your private messages before encryption, versus a Parliament defending end-to-end. The outcome’s now, deciding if WhatsApp, Signal, and iMessage stay truly encrypted in Europe.

What to watch:

1. The publication of the trilogue’s outcome (or failure) and whether there’s an explicit exemption for end-to-end encryption.

2. The return of « Chat Control 1.0 » (extended voluntary scanning) that Metsola threatens to reopen if 2.0 stalls: a Trojan horse if negotiations fail.

3. Mandatory age verification, which kills online anonymity far beyond fighting CSAM.

What Happened on June 29th

Under Cypriot presidency, the EU Council held what was billed as the fifth and final trilogue on the CSAR regulation, dubbed « Chat Control 2.0 », on June 29th. The presidency’s stated goal was to secure a political agreement before the summer break.

The sticking point remains unchanged. On one side, a Council text that mandates mass surveillance of private communications via ‘detection orders’, a provision that the Council’s own legal service deems contrary to Article 7 of the Charter of Fundamental Rights. On the other, a Parliament that, on March 26, 2026, rejected mass surveillance by a single vote (307 to 306), and is holding firm to end-to-end encryption protection.

As of now, no official source has published the outcome of this trilogue: neither success nor failure confirmed. The Cypriot presidency is pushing for formal adoption in July, but the impasse over encryption could still derail everything. Keep an eye on this silence in the coming days.

Why It Matters to You

Client-side scanning requires inspecting your messages on your device, before they’re encrypted. The crypto of WhatsApp, Signal, or iMessage isn’t broken, it’s neutered: your message is read plaintext on your phone before it’s sent. And this inspection point isn’t reserved for ‘nice guys’, it’s exploitable by any attacker who gets their hands on it.

Adding to this is the mandatory age verification, which requires tying a real identity to your messaging account. It’s the end of default anonymity, sold under the guise of child protection.

What You Can Do

Nothing to install today: it’s a political signal, not a product flaw. But keep Signal as a fallback messaging option, watch your MEP’s positions, and follow EDRi / Patrick Breyer for real-time updates. Once it’s published, we’ll update our articles on the topic.

Your stance is leaking through the network, not through your iPhone.

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

Citizen Lab linked, in its “Bad Connection” report from April 2026, real surveillance traffic to operators’ infrastructures. Commercial entities can locate any mobile device through network interconnection flaws, SS7 in 2G/3G, Diameter in 4G, without ever touching the device. Nothing to patch on your iPhone: the hole is in the network, not in iOS.

What you need to watch out for

1. No setting blocks this vector: neither Isolation mode, nor eSIM, nor Signal, nor turning off data. The only workaround is to make yourself unreachable by turning on airplane mode or turning off your phone. Don’t think you’re covered just because you’re encrypting your messages.

2. Use 2FA codes for apps, not SMS. It doesn’t stop geolocation, but it closes the interception of codes via the same network.

3. The real defense is structural, on the operators’ and regulators’ side. NIS2 and ENISA frame the risk, but no strong technical obligation yet requires securing interconnection.

The Citizen Lab published a report in April 2026 that for the first time links real surveillance traffic to identified operator infrastructures. The principle has been known for ten years, but the finding remains unsettling: commercial companies can locate any mobile device in the world without ever touching the device itself. Your iPhone is not at fault, and that’s precisely the problem.

The Fact

The report is called “Bad Connection”. It documents actors who track phones across over twenty countries, with one of them conducting over 1700 attacks, almost all of which are dedicated to geolocation. The described target is a “VVIP” in the Middle East, but the typical profile of this market is known: journalists, dissidents, and political figures.

The mechanism exploits the protocols that make operators communicate with each other when you roam or change antennas. They were designed in an era when a handful of national operators trusted each other implicitly. Today, there are thousands of them, and this implicit trust has become a backdoor. Three vectors coexist: SS7 on 2G and 3G, Diameter on 4G, and a variant called SIMjacker that uses a silent SMS executed on your SIM card. The Citizen Lab is categorical: these are not software bugs, but inherent flaws in global telecoms.

A crucial detail: usually, it’s not your operator selling your location. There are two markets. The first one exists: in the US, major operators have sold the location of their subscribers to data brokers, resulting in nearly $200 million in FCC fines in 2024.

The second one, the heart of this radar, is different: surveillance companies like Rayzone, Circles, or Cognyte exploit interconnection flaws by leasing legitimate access points to the global network, often via a small accomplice operator. They remotely query the network of your target, without their consent or their operator’s.

Why This Matters to You

Here’s the angle that’s unsettling. You can encrypt your messages, harden your Mac, close every macOS setting one by one, but your physical location still passes through infrastructure you don’t control, and Apple has no say in it. There’s nothing to patch on this end because it’s not a hole in iOS. It’s the architecture of the network itself.

So, most of the precautions you think of won’t help against this specific vector, and it’s better to know that than to be lulled into a false sense of security. “Hardcore” mode on your iPhone doesn’t touch an SS7 request that happens in the network. An eSIM changes the format of the card, not the protocol: as long as there’s a reachable number, you’re exposed.

Signal protects the content of your messages, not the signaling metadata that reveals where you are. Turning off data or GPS doesn’t matter either, the tracking uses the cell identifier, not your puck. The only individually effective solution is airplane mode or turning off the phone, which is hardly practical daily.

Two caveats to avoid selling you false barriers. Two-factor authentication by app has real utility, but against another risk: SMS interception of your codes, not geolocation. A dedicated number or eSIM reduces the link between your location and your real identity, but doesn’t make that number any less traceable.

The real defense is structural. It plays out with operators and regulators, with signaling firewalls that the GSMA documents in its FS.11 guide. Your security here doesn’t depend on you, but on infrastructure and a legal framework you don’t control.

Let’s be clear about the real risk: for an average person, the likelihood of being targeted remains low. This matters not because of an imminent threat to you, but because of what it reveals. Digital sovereignty doesn’t stop at the edge of your device: as long as you have a SIM card, your location circulates in a weakly constrained global network.

What You Do Now

1. Recalibrate your expectations, that’s the most useful gesture here. Keep Signal, “Hardcore” mode, and your good habits, they protect content and the device, but don’t believe they make you invisible on the network. Confusing the two is the trap.

2. For connection codes, abandon SMS and switch to app-based or hardware key two-factor authentication. It won’t protect you from geolocation, but it closes the interception of codes via the same network, and that’s a real risk to your accounts.

3. If you have a genuinely exposed profile, like a journalist, political dissident, or lawyer on a sensitive case, the only serious individual lever is physical discipline: in airplane mode or with the phone turned off, your device is no longer registered on the network, there’s nothing to locate. You only become traceable again upon re-registration. A dedicated number cloisters your identity, but remains traceable the same way.

4. For the rest, the real work isn’t on your desk. Follow the subject on the regulator side: NIS2 and ENISA set a framework, but no strong technical obligation yet forces operators to close these flaws. That’s where pressure needs to be applied.

Sources

“Bad Connection: Uncovering Global Telecom Exploitation by Covert Surveillance Actors”, Citizen Lab, April 2026 (primary source)
Signalling Security in Telecom SS7/Diameter/5G, ENISA (protocols deemed fundamentally flawed, EU recommendations)
FS.11 SS7 Interconnect Security Monitoring and Firewall Guidelines, GSMA (the signaling firewall reference, industry self-regulation)
Hacking Your Phone, 60 Minutes, CBS, 2016 (interview with Representative Ted Lieu via SS7, demonstration on an elected official)
FCC Fines Major U.S. Wireless Carriers for Selling Customer Location Data, Krebs on Security, 2024 (the distinct market of data brokers, $200M USD in fines)

Technical terms? Check the glossary.

Siri AI blocked in EU, privacy signed Google

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

Apple Launches Siri AI at WWDC, But Blocks It on iPhone and iPad in EU Due to DMA. Commission Says It’s Apple’s Choice, Not a Requirement. To Top It Off, This “Confidential” Platform Partially Relies on Google Gemini.

What This Means for You

1. No Siri AI on iPhone or iPad in Europe. But without cloud AI assistant, your device is safer: you lose a feature, not a protection.

2. For the Sensitive, Stay Local and enable Advanced Data Protection on iCloud. For encrypted email, use Proton Mail, not iCloud Mail.

3. Ask Yourself the Real Question: Is trusting your most intimate assistant to an Apple-Google chain a technical guarantee or a contractual promise?

Apple Unveils Siri AI at WWDC

Apple has unveiled Siri AI, its new voice assistant platform. Two details stand out: it’s partly built on Google Gemini, and it won’t be available on iPhone or iPad in the European Union. Privacy, Cupertino-style, becomes a blocking argument.

The Fact

On June 8, 2026, at the WWDC, Apple introduced Siri AI, the much-anticipated revamp of its voice assistant and the announced foundation of its next generation of products, including future portable devices. The platform’s core is a hybrid architecture: local tasks run on Apple’s in-house models, but cloud intelligence relies on a custom Gemini model from Google, estimated to be around a billion dollars a year, according to several press sources.

The catch is geography. Apple announced that Siri AI won’t be available on iPhone or iPad in the EU with iOS 27 and iPadOS 27. EU users will have access on macOS 27 and visionOS 27, but not on iPhone, iPad, or Apple Watch, as watchOS 27 depends on a paired iPhone with Siri AI. Apple cites the Digital Markets Act (DMA) and its interoperability requirements, claiming regulators rejected its compliance proposals, including a Trusted System Agent framework meant to open access to competing assistants while maintaining security standards.

The Commission disputes the framing. For spokesperson Thomas Regnier, Apple’s decision not to deploy Siri AI in the EU is “Apple’s alone,” with nothing in the DMA preventing a new product launch. The market, however, has spoken: Apple’s stock dropped about 2% on the day of the announcement and another 3% the next day. Note of caution: iOS 27 and iPadOS 27 are currently announcements, not stable builds. The release timeline and block perimeter could still shift.

Why It Matters to You

If you’re in Europe, the message is clear: your iPhone and iPad won’t have the flagship feature of the next OS. Before blaming Brussels, look at what’s really happening. Apple presents privacy as the reason it can’t comply with interoperability demands.

The Commission responds that no one’s forcing Apple to cripple its product. The two versions aren’t symmetrical, and the official site isn’t the only source of truth here, but one thing’s certain: privacy has become a negotiation point as much as a technical promise.

The irony’s worth noting. Apple pitches Siri AI as privacy-respecting while outsourcing cloud processing to Google, whose business model relies on data exploitation. Apple swears its architecture segregates everything via Private Cloud Compute, that Google sees nothing, and requests are anonymized. It’s plausible on paper, and Apple has a solid track record. But you’re moving from a verifiable promise, all-on-device, to a contractual one, trusting partners to keep their word. It’s not the same level of assurance.

The underlying issue goes beyond Siri. We’re seeing digital ecosystem fragmentation by jurisdiction. The same iOS version won’t offer the same features in Paris, New York, or Beijing. User sovereignty now hinges not just on encryption, but on the iPhone-dependent arms race between an American industrial giant, a European regulator, and a third-party AI provider.

What It Changes for You

1. Don’t confuse Siri AI’s absence with loss of privacy. Your iPhone without a cloud AI assistant remains fully functional and more secure. The “lack” is a feature, not a lost protection.

2. For sensitive queries, stick local. Enable Advanced Data Protection on iCloud (Settings > Apple Account > iCloud > Advanced Data Protection) for end-to-end encrypted backups. Note: ADP doesn’t cover iCloud Mail, Contacts, or Calendar. For genuinely encrypted email, try Proton Mail or Tuta, for instance.

3. Keep an eye on developments without getting overwhelmed. The EU block perimeter and timeline may shift. What matters isn’t the release date, but the broader question: are you ready to entrust your most intimate assistant to an Apple-Google chain, based on a contractual promise?

OpenAI Certificate Compromised, Update ChatGPT Mac Before June 12th

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

**If you’re using ChatGPT, Codex, or Atlas natively on your Mac, you’ve got until June 12, 2026 to update. OpenAI’s signature certificate has been compromised via a supply-chain attack on npm. After that, your app won’t start.

Here’s what you need to do:

1. Open ChatGPT.app, go to Settings → About. Update if your version is ≤ 1.2026.125. Same for Codex App (≤ 26.506.31421), Codex CLI (≤ 0.130.0), Atlas (≤ 1.2026.119.1).

2. Official download only, chatgpt.com/download or App Store. No mirrors, no shared links.

3. iOS, Windows, Android, nothing to do, OpenAI re-signs on the server side. Mac only.

You’re using ChatGPT, Codex, or Atlas in a native app on your Mac. On June 12, in a few days, these apps will refuse to launch if you haven’t updated. Not a bug, a certificate revocation due to a supply-chain attack. Here’s what happened and what you need to do.

The Facts

On May 11, 2026, a collective called TeamPCP published 84 tampered versions of 42 @tanstack/* packages on npm in just six minutes. Two OpenAI employees consumed one of these packages that evening. The malware, Mini Shai-Hulud, exfiltrated credentials that granted access to internal repositories containing OpenAI’s code-signing tools. Not user conversations or models, just the keys that prove to macOS that an app comes from OpenAI.

OpenAI announced publicly on May 13, 2026, that the compromised certificate would be revoked on June 12, 2026. On Apple’s end, this means Gatekeeper and notarization will refuse any version signed with the old certificate. In practical terms, the affected versions are:

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

These won’t launch after June 12. iOS and Windows versions are re-signed server-side, no user action needed.

The worm’s source code was published by TeamPCP on May 12, with a $1,000 bounty on BreachForums for the largest supply-chain attack using their tool. Not a defensive bug bounty, an offensive reward. The CVE reference is CVE-2026-45321.

Why This Matters to You

You didn’t do anything wrong, but you still have to act. That’s the essence of a supply-chain attack. Your user hygiene could be perfect, but if the app you’ve installed gets compromised four levels up, in an npm dependency you’ll never know about, you’re the one left with the problem. The compromised certificate, the revoked signing mechanism, the app that won’t launch - it all happens on your end without you clicking anything.

The good news is the revocation mechanism works. Gatekeeper and Apple’s notarization are designed for this: preventing an attacker from using a stolen certificate to sign malware downstream. OpenAI did their job by properly revoking. Apple did their job by blocking. The system held up. OpenAI communicated clearly and promptly, with specific dates and versions - not the norm in the industry.

The bad news is it raises a doctrinal question that goes beyond OpenAI. A native app on your Mac is local code running with a trust certificate, automatic update channel, system permissions, and a network of upstream dependencies you have no visibility into. When one of these dependencies gets compromised - and they all do - the problem comes down to you.

What You Need to Do Now

1. Open ChatGPT.app, go to Preferences → About. If you’re on 1.2026.125 or earlier, start the update. If nothing appears, download directly from [chatgpt.com/download](https://chatgpt.com/download]. Never a mirror, never a shared link.

2. If you’re using Codex App or Codex CLI, do the same check. CLI: codex --version then npm update -g @openai/codex or reinstall cleanly. For Atlas, update is integrated.

3. Make sure macOS is up-to-date, with Gatekeeper strengthened on Sequoia 15.x and Sonoma 14.7+. Older versions are more lenient in notarization checks at launch.

4. Use the window to ask yourself a doctrinal question: what does the native ChatGPT app give you that chatgpt.com in Safari doesn’t? System dictation, keyboard shortcuts, Spotlight integration - okay. If you don’t use any of these, the browser reduces your attack surface. No signature certificate to manage, no silent updates, no persistent local code. The habit applies to Claude Desktop, Perplexity, Mistral AI Chat, and any other third-party AI apps you’ve installed without really knowing why. A native app on your Mac is a security debt - sometimes justified, sometimes not.

Also read, Anthropic MCP, design flaw that opens RCE. Same logic, third-party AI code descending into dangerous local execution.

Sources

Domestic stalkerware, the jealous partner's malware

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

Public stalkerware (Spyzie, Cocospy, Spyic, mSpy) has over three million victims just within the Cocospy/Spyic/Spyzie family. Thirty to seventy dollars a month, operated by Chinese operators. On iPhone, your spouse knows your Apple ID and drains iCloud from the web. Less commonly, a hidden MDM profile installed by a close one in just two minutes. On Android, a hidden app. Premium modules: real-time GPS tracking and remote microphone activation. The victim never searches for the term “stalkerware” and doesn’t even know it exists.

What you need to do

1. Check Settings, General, VPN and Device Management. Any profile you didn’t set yourself, especially vague ones like “iOS Update”, delete it. Check Screen Time, disable any password you didn’t set.

2. Change your Apple ID password, enable two-factor authentication, remove unknown devices from your list, and enable Advanced Data Protection to switch your iCloud backups to end-to-end encryption.

3. Switch to Signal for sensitive messages, Bitwarden or KeePassXC for passwords, never a shared vault.

4. If you suspect active installation, act from another device and network. The Coalition Against Stalkerware lists resources by country.

On May 26th, Joseph Cox of 404 Media interviewed Zack Whittaker, the journalist who’s been leaking pretty much all the major consumer stalkerware cases for the past five years. Verdict? It’s not a niche market, it’s a mass market. Hundreds of thousands of victims on just one network. Targets iPhones and Androids. Installation by your partner, ex, roommate, in two minutes while you’re in the shower.

The Deal

Stalkerware is spyware sold to Joe and Jane Public. Not Pegasus, not Predator, not the mercenary spyware grade that Citizen Lab tracks from Toronto. The stuff you install on your girlfriend’s phone to read her messages, listen to her calls, track her location, and turn on her mic remotely. Brands like Spyzie, Cocospy, Spyic, mSpy, TheTruthSpy.

Whittaker’s been leaking these since 2021. The latest wave, February 2025, exposed 518,000 Spyzie clients including at least 4,900 compromised iPhones, and 2.65 million email addresses on the twin network Cocospy + Spyic. That’s over three million victims just from this one family of operators.

Monthly subscription? Thirty to seventy dollars for the standard plan, more if you add premium modules like mic and cam access. Companies live in offshore holdings, Cyprus, British Virgin Islands, or straight out of China. Cocospy, Spyic, and Spyzie are all the same team, traced back to one Chinese operator by Whittaker.

mSpy runs the same business model under a separate brand, legacy Cyprus-Ukraine. When leaks expose them, they shut down and reopen under a new name. Market size? Around $145 million a year, according to Future Market Insights.

On the iPhone side, the dominant method doesn’t even need physical access. Your partner knows your Apple ID password because you shared it, they’ve seen your iPhone unlock a hundred times, or you’ve used the same one for fifteen years. They log in to iCloud via browser, download your backups, and the stalkerware app does its thing server-side. No app on your phone, nothing to detect locally. Exactly how Whittaker documented Cocospy, Spyic, and Spyzie in 2025.

Rarer but more comprehensive variant: a configuration profile MDM, the mechanism designed for managing business fleets. The close one installs the stalkerware app via Apple Configurator on their Mac, supervising your phone with a Lightning or USB-C cable. The profile’s marked removalDisallowed, named something innocuous like “iOS Update” or “Battery Optimizer”. A Screen Time password your partner set hides the “Device Management” entry in Settings. You’re clueless. On Android, it’s the app disguised as a system tool, hidden behind a generic name, with accessibility turned on to read everything for you.

Why This Matters to You

Here’s where the usual cybersec press coverage drops off. We hear a lot about the mercenaries, NSO, Intellexa, Paragon, the billion-euro budgets and diplomatic targets. But the statistical danger for you? It’s not some state watching you, it’s your ex stalking you. States have their part too, pushing for mass control legislatively, as I’ve broken down in Six Months and Nineteen Global Texts, the Terrible Convergence. But the sheer frequency of domestic victims trumps all.

Whittaker’s been saying since 2021 that domestic stalkerware outdoes all mercenary spyware combined. The press ignores it because it’s dirty, intimate, lacks Pegasus’ geopolitical cachet.

Information asymmetry is total. Buyers find these products in three clicks: fake “Top 10 spy apps” sites owned by sellers, SEO on jealous searches, Reddit with affiliate accounts, TikTok in “POV I hooked my guy” format, Google Ads hijacked on “Find My iPhone” or “family locator”.

Marketing facade: “parental control for kids” quickly pivots to “monitor your spouse”. Potential victims never search for “stalkerware”. They don’t even know it exists. That’s the definition of a threat you don’t see coming.

You’re the target. Couple with iPhone and Mac, integrated Apple ecosystem, shared iCloud family, common passwords “because we trust each other”. When trust cracks, siphoning takes a few clicks from a browser, or two minutes MDM installation while you’re out. You’ll only know reading this.

What You Do Now

1. Check your iPhone, configuration profiles, and Screen Time.
Settings, General, VPN & Device Management. If you see a profile you didn’t install, especially with a vague name like “iOS Update”, “Battery Saver”, “Profile Service”, delete it. Then Settings, Screen Time. If a password’s active and it’s not yours, disable via your Apple ID. That password often hides the VPN & Device Management entry. If the delete button’s greyed out or the profile returns after “Reset All Settings”, it’s removalDisallowed with active DEP supervision: need Apple Store server-side break. Apple reference: remove a configuration profile.

2. Take back control of your critical accounts.
Change your Apple ID password immediately and enable two-factor authentication with a number your close circle doesn’t control. Check the list of devices connected to your Apple ID in Settings, top. Any unknown device, delete it. Enable Advanced Data Protection for end-to-end encrypted backups, server-side exfiltration becomes useless.

3. Switch to E2EE tools for sensitive stuff.
Critical messages on Signal, not iMessage. Passwords in your own manager, Bitwarden self-hosted or KeePassXC local file, not a shared Apple Keychain. Local encrypted backups on external drive, not just iCloud.

4. If you suspect active installation, leave the physical perimeter before acting.
Stalkerware with mic and GPS rats you out in real-time. Contact specialized help services from an unsurveilled device and network. The Coalition Against Stalkerware lists resources by country and a response kit for victims.

Sources

Millions of people are installing malware on their partner’s phones, with Zack Whittaker, 404 Media, 26/05/2026 (primary source)
Spyzie stalkerware spying on thousands of Android and iPhone users, TechCrunch, 27/02/2025 (Whittaker’s investigation, 518k clients + 4,900 iPhones)
Cocospy and Spyic exposing phone data of millions of people, TechCrunch, 20/02/2025 (market architecture, 711.icu China link)
Cocospy stalkerware apps go offline after data breach, TechCrunch, 19/05/2025 (post-leak rebranding pattern)
Stalkerware apps escape Google’s ad ban, TechCrunch, 11/08/2020 (Google Ads workaround)
Coalition Against Stalkerware, victim resources

Tech terms? Check the glossary.

The U.S. cyber regulator let its AWS keys slip six months ago.

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

**CISA, the U.S. federal cyber agency, just found out that one of its subcontractors left a public GitHub repository full of AWS GovCloud admin keys, tokens, and cleartext passwords for six months. External detection by GitGuardian, not internal. The keys remained valid for 48 hours after the repo was removed. If the federal cyber regulator can’t even keep its own secrets, how are you supposed to? Let me explain!

What you need to do

1. Inventory what you’re currently entrusting to a third-party cloud, and for each item ask yourself who has the decryption key. At-rest encryption with server-side keys equals zero.

2. Choose your cloud providers based on one criterion: end-to-end encryption, client-side keys (Proton, Tuta, Mullvad for EU).

3. What happens at home stays at home: backups on encrypted APFS external disk, double offsite encrypted copy.

The Deal

On May 22, 2026, Brian Krebs published the investigation. An employee of Nightwing, a historic subcontractor of CISA based in Dulles, Virginia, created a GitHub repository named “Private-CISA” on November 13, 2025. The word “Private” in the name, the public setting in the parameters. The repo remained online, accessible to anyone, until mid-May 2026. Six months.

Inside, there’s heavy stuff. Three sets of admin keys for AWS GovCloud accounts, Amazon’s cloud environment dedicated to US federal agencies, certified FedRAMP High for hosting non-classified sensitive data (CUI).

Access tokens, SSH keys, internal logs, and clear-text passwords following the “platform-year” pattern that a third-year intern wouldn’t dare to try. Plus some internal documents about the agency’s software development processes. Almost nothing, huh!

And the detection? Neither CISA internal nor Nightwing audit. It’s Guillaume Valadon, a researcher at GitGuardian, who continuously scans public repos for forgotten secrets, who found the repo. Krebs and the consulting firm Seralys notified CISA, which had the repo taken down. The cherry on top: the AWS keys remained valid for 48 hours after the repo was removed before the agency decided to revoke them.

CISA’s official statement is one sentence we’ve seen a hundred times: “At this stage, there’s no indication that sensitive data has been compromised.” Nightwing refers to CISA, CISA refers to the investigation. Krebs qualifies the incident as “one of the most scandalous government data breaches in recent history,” and Bruce Schneier repeats the phrase without qualification.

Why it matters to you

You’re not CISA, you don’t have a Nightwing subcontractor, you don’t use AWS GovCloud. Great. Now, do the cold calculation. The agency that sets the cybersecurity standards for US administrations, that publishes “secure by design” guides and CVE alerts followed by the entire industry, just left its own cloud admin keys open for six months without noticing. Not some dodgy subcontractor or some third-rate SaaS: the cyber regulator itself.

The argument is structural, not anecdotal. When you entrust your secrets to a third party, no matter how serious they claim to be, you inherit their entire supply chain. CISA entrusts to Nightwing, Nightwing employs someone, that someone pushes to GitHub. The weak link compromises the entire chain in an instant. That’s bad enough on its own, but add the IA threat surge, and you’ve potentially got a backdoor into more confidential systems.

Let’s get back to you. You have a personal GitHub repo? You’ve ever pasted an API key into a commit for “quick testing” before forgetting to remove it from history? You use a cloud-owned password manager for creds that open your infrastructure? You trust a SaaS editor under foreign jurisdiction to keep your secrets securely encrypted for you? The CISA radar is you in miniature, but with fewer zeros on the consequences.

The MacSouverain angle doesn’t change by a millimeter from the first article. Keep your secrets with you. On your machine, in your local vault, under your key. You can delegate the formatting, syncing, encrypted backup. You don’t delegate security itself. Because the day your provider screws up, and they will, you want the blast radius to stop at them.

What you do now

1. Inventory what you’re currently entrusting to a cloud third party.
Grab a sheet of paper. Passwords, emails, contacts, files, notes, photo backups. For each one, write where it’s stored and who has the decryption key. If the answer to “who has the key” is “the provider, or one of their subcontractors,” you’re in exactly the same position as CISA. You’re trusting a chain you don’t control a link of.

2. Choose your cloud providers based on “end-to-end encrypted, key on client side”.
For what you have to put in the cloud (multi-device sync, sharing, backup), only accept providers who can’t read your content, even if they wanted to or were asked to.

For email and storage: Proton or Tuta, European jurisdiction, end-to-end encrypted by default. For VPN: Mullvad or Proton VPN, no logs. The difference from AWS, Google Drive, iCloud non-ADP: you don’t have to take the provider’s word for it, the architecture makes unauthorized access technically impossible.

3. What happens at your place stays at your place.
Whatever you can keep local, keep it local. Photos, archives, sensitive documents, backups: an encrypted APFS external drive at home, plus a second encrypted copy you store with a friend or in a safe. If you need to sync files between your own devices without going through a third party, Syncthing does direct P2P between your devices, period. You don’t go to the cloud by default, you go there deliberately. The CISA rule applies in miniature to everyone: the day your provider screws up, and they will, you want the blast radius to stop at them, not take you down with them.

Sources

CISA Admin Leaked AWS GovCloud Keys on GitHub, Krebs on Security, May 22, 2026 (primary source)
CISA Security Leak, Schneier on Security, May 22, 2026 (commented repost)
GitGuardian, scanner of secrets in public repos

Five years of defending memory M5 down in five days

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

Three researchers took full control of a Mac M5 in five days, with a helping hand from Mythos, Anthropic’s specialized IA vulnerability AI. In the process, they took down MIE, Apple’s five-year-old memory protection. Apple patched it in macOS Tahoe 26.5 on May 11. First public kernel exploit on M5 silicon, and a real-world show that AI can speed this kind of work by a factor of ten.

What you need to do

1. Update macOS Tahoe 26.5 immediately (System Preferences, Software Update).

2. Enable Lockdown Mode if you’re professionally exposed (journalist, activist, executive).

3. Avoid all unverified user binaries. Strict Gatekeeper, signatures on Homebrew.

The Deal

On May 14, 2026, Calif.io spilled the beans on how they did it. Three researchers (Bruce Dang, Dion Blazakis, Josh Maine) found two bugs in the macOS kernel on a brand-new Mac M5. They chained them together. Result: a regular user, with no special privileges, gains full control of the machine (root). Reading all memory, accessing the Keychain, disabling protections. Everything.

What makes this historical is what came out alongside it. The M5 chip debuts MIE (Memory Integrity Enforcement), a protection hard-coded into the silicon. In other words, Apple tagged every piece of memory used by the kernel, and the hardware refuses tampering. Five years of work. Unveiled last year as the new frontier of Mac security. Calif bypassed it in five days.

The game-changer: Mythos. It’s Anthropic’s frontier model, restricted access for vulnerability research. The researchers clarify that Mythos didn’t find the exploit alone. Bypassing MIE requires sharp human expertise. But Mythos spotted the bugs fast, where humans alone would’ve taken weeks. Months of work now takes days.

Calif handed the details to Apple in Cupertino. Apple released the fixes in macOS Tahoe 26.5 on May 11, 2026. The release notes credit “Calif.io in collaboration with Claude and Anthropic Research”. The full technical report (55 pages) is under embargo until the patches roll out everywhere. Apple hasn’t publicly commented on the exploit chain.

Why it matters to you

If you’ve got a Mac M5, your hardware was sold as the high-water mark of Apple security. Five days after the exploit was released, the frontier moved. Hardware protection alone isn’t enough; a well-equipped human can bring it down in a week.

Good news: it’s not a remote attack. To exploit the bugs on your Mac, the attacker needs a foothold. A booby-trapped binary you ran yourself (compromised Homebrew, app grabbed outside the App Store, file opened from a sketchy shared drive). From there, though, they’re root and can do whatever they want.

The bigger picture: Mythos is making waves. On May 11, curl maintainer Daniel Stenberg confirmed a flaw in his code found by Mythos (Stenberg’s still skeptical, but acknowledges the result). Three days later, Calif.io took down MIE. The window between ‘bug discovered’ and ‘functional exploit’ is closing. Apple, Google, and Microsoft have all publicly acknowledged that the latest AI models are changing the threat model. We’re seeing it in practice now.

What you do now

1. Update macOS Tahoe 26.5 right now, on all your Macs (M5, M4, M3, M2, M1, Intel). The update covers bugs beyond just the M5. System Preferences, General, Software Update. If you’re still on macOS Sequoia 15.7.7 or macOS Sonoma 14.8.7, they got the cousin fixes the same day.

2. Turn on Lockdown Mode if you’re professionally exposed (journalist, activist, executive, researcher). Lockdown Mode severely cuts the kernel memory attack surface, exactly what Calif exploited. System Preferences, Privacy & Security, Lockdown Mode. Beware, there’ll be friction.

Read: Lockdown Mode, why to turn it on

3. Avoid binaries from nowhere. No out-of-App Store apps without audit, no random executables. Verify signatures (GPG, SHA256) on sensitive tools, Homebrew included. Set Gatekeeper to strict in System Preferences, Privacy & Security, allow only the App Store.

4. Stay tuned: Calif’s 55-page tech report comes out once the patches are widely deployed. When it’s public, expect a wave of copies on GitHub and a full Mac fleet scan by security teams. Until then, just stay updated.

Sources

Also see

Anthropic Mythos: unauthorized access identified

Google Ads and real cat Claude share your credentials

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

A malicious ad campaign is hijacking Google Ads and Claude.ai’s Share function to promote MacSync, an info-stealing macOS malware that empties your Keychain with a simple terminal command you paste yourself. The pattern combines two trust signals (official claude.ai domain + fake Apple Support) to lure you into running base64 without suspicion.

What you need to do

1. Never paste a terminal command dictated by a website, AI chat, or an “official” PDF.

2. Enable Little Snitch or LuLu and monitor unexpected network traffic.

3. If already executed: disconnect from Wi-Fi, change all your browser passwords, and scan with KnockKnock.

You’re searching “Claude mac download” on Google. The first sponsored result points to claude.ai, so the URL is legitimate. Except it’s a shared Claude chat where a fake “Apple Support” dictates a Terminal command to paste. You paste it, and MacSync steals your Keychain, cookies, and browser credentials.

The Fact

Berk Albayrak (Trendyol Group) and BleepingComputer have been documenting since May 10, 2026, an active macOS malvertising campaign that exploits two legitimate mechanisms simultaneously. First, Google Ads: a sponsored ad for “Claude mac download” points to claude.ai, Anthropic’s official domain. Then, Claude.ai Share: this feature is used to host a fake installation guide signed “Apple Support” that tells the user to paste a base64-encoded command into Terminal.

The command downloads a polymorphic shell script from the attacker’s infrastructure, checks the keyboard layout (exits immediately if Russian or CIS), then executes the second-stage payload via osascript (macOS’s native AppleScript engine) for fileless delivery. The malware is called MacSync, an infostealer that collects browser credentials and cookies, exfiltrates the macOS Keychain, and fingerprints the victim (IP, hostname, OS version, keyboard language).

The indicators of compromise published are payload customroofingcontractors[.]com/curl/ and bernasibutuwqu2[.]com/debug/loader.sh, exfiltration to briskinternet[.]com. The two identified Claude.ai Share URLs are claude[.]ai/share/9aac1046-a39e-4618-8265-f54c4be863f7 and claude[.]ai/share/eb2db455-1d47-4baf-8671-0a689e165902.

Don’t worry, the links are disabled here, but Anthropic hadn’t disabled the Share mechanism at the time of BleepingComputer’s publication.

Why This is a Game-Changer

Two things, really. First, the “shared chat” feature of a public AI platform becomes a malware distribution surface. Claude.ai’s shared pages are public, indexable, and notably, not moderated like typical user content. They inherit Anthropic’s visual trust, and at the time of BleepingComputer and GBHackers’ publications, both compromised share URLs were still online.

Second, AI brand hijacking joins known malvertising schemes (Homebrew, Loom, Notion, AnyDesk), with Claude Code being a recent dev tool, its official installation page isn’t yet a muscle memory reflex, leaving an exploitable window.

This is also a case study on Google Ads, despite announced controls, ads impersonating brands continue to slip through, exploiting the legitimate display URL while pointing to a compromised page on the editor’s own site.

Domain validation isn’t enough when the editor hosts user content. Responsibility is shared, Anthropic needs to beef up shared chat moderation (detect chats posing as official support of other brands, banner on chats containing shell commands, visual watermark distinguishing a shared chat from a product page), Google needs to go beyond display domain in Ads validation. But the last line is you, never paste a Terminal command blindly.

Why This Matters to You

The social engineering pattern here is ruthless because it chains two usually legitimate trust signals. The claude.ai official domain, native Anthropic Share feature, fake “Apple Support” in a supposedly serious AI environment. You’re not clicking on some obscure download site, you’re clicking on what looks like official documentation brought up by a search engine, exactly the kind of attack that slips under usual vigilance.

The target is wide. Not just developers (Homebrew, GitHub), but any Mac user curious to try Claude desktop. The malware doesn’t require any system elevation, no 0day, no TCC bypass, the user does all the work themselves by pasting the command. And since osascript is a native, signed Apple binary, it slips under most commercial EDRs and even XProtect.

The angle that concerns you directly: it’s the offensive return of the macOS Keychain as a prime target. You’ve learned to protect your Mac’s user password, enable FileVault, use Touch ID. But a Terminal command launched by yourself circumvents all that, because you’re the one opening the door.

What You Do Now

1. Never paste a Terminal command dictated by a website, AI chat, or “official support” PDF. If you must install a tool like Claude desktop, go directly to claude.ai/download by typing the URL yourself, never via a sponsored Google result. The universal rule: if someone tells you to paste anything into Terminal, it’s a no.

2. Enable Little Snitch or LuLu in hardened silent mode. Both log and block unexpected outgoing network connections to the published IOCs (customroofingcontractors[.]com, bernasibutuwqu2[.]com, briskinternet[.]com). If you suspect a hasty command, check outgoing connections in the minutes after.

3. If you’ve run a suspicious command recently: disconnect from Wi-Fi immediately, change all your browser passwords (from a clean device), revoke all active cloud session tokens (mail, sync, password manager), scan with KnockKnock or ReiKey from Objective-See, check launch agents in ~/Library/LaunchAgents/.

4. Monitor your Keychain. security dump-keychain | grep -i password tells you what’s inside. For the future, migrate sensitive passwords to Apple Passwords or Proton Pass, not the general iCloud Keychain by default.

Sources

Apple patches iOS and macOS CVE vulnerabilities: fixes, then tweaks Safari profiles

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

iOS 26.5 and macOS Tahoe 26.5, released on May 11, fix 98 CVEs each (including 21 and 22 in WebKit). Global Lockdown Mode is overkill for daily use. Safari profiles, available since iOS 17, segment usage for you.

What you need to watch out for

1. Install iOS 26.5 and macOS Tahoe 26.5 today.

2. Create a “Cautious” Safari profile with only privacy extensions enabled, use it for banking, webmail, suspicious links, and medical research. Keep your default profile untouched for everything else.

Apple Publishes iOS 26.5 and macOS Tahoe 26.5, Fixing 98 CVEs

On May 11, Apple released iOS 26.5 and macOS Tahoe 26.5. These updates address 98 security vulnerabilities on iOS (including 21 on WebKit, Safari’s engine) and 98 on macOS (including 22 WebKit). Several of these vulnerabilities allowed malicious websites to execute code or bypass sandbox protections. As usual with Apple releases, WebKit takes the biggest hit, as it’s the largest attack surface on an iPhone or Mac.

Patch now. That’s a no-brainer. The real question is, what do you do between patches, when clicking on mail links, conducting sensitive searches, or logging into online banking?

Why Lockdown Mode All the Time is Too Much

Lockdown Mode is robust. MacSouverain praised it in article 29. It’s perfect for journalists, dissidents, or lawyers handling sensitive cases.

But for freelancers or small businesses just checking email, doing online accounting, or watching recipes, it’s overkill. Disabled JIT JavaScript, cut Safari extensions, restricted media formats, filtered Messages attachments. Too much friction, too many websites breaking. The usual result: you enable it for a few days, find it annoying, disable it, and end up with nothing.

What are Safari Profiles?

Since iOS 17 and macOS Sonoma (September 2023), Safari supports multiple profiles within the same app. It’s been quiet, never highlighted in keynotes. Most people you talk to don’t know it exists.

Each profile has its own history, cookies, enabled extensions, search engine, favorites, and tab groups. No mixing: Google’s session cookie from your “Personal” profile isn’t seen by your “Sensitive” profile. Privacy extensions active on “Sensitive” don’t slow down “Personal” navigation. Switch in two taps (tap on tabs on iPhone, Safari menu on Mac), syncs with iCloud between Mac and iPhone.

It’s the usage segmentation we’ve advised for years in security, without installing a second browser.

What to Do Now

1. Install iOS 26.5 and macOS Tahoe 26.5. Settings, General, Software Update. Twenty minutes, including restart.

2. Create a “Sensitive” Safari profile. On Mac: Safari, menu, Create Profile. On iPhone: Settings, Apps, Safari, Profiles, New Profile. Name, icon, color.

3. Configure the “Sensitive” profile: DuckDuckGo or Qwant search engine (setting per profile), empty favorites, and add two or three privacy extensions active only on this profile: AdGuard for Safari (free on App Store, network and cosmetic filtering), Vinegar if you want a clean YouTube (one-time purchase), StopTheMadness Pro if you already have its license. Your default profile remains untouched, no slowdown when surfing normally.

4. What the profile doesn’t isolate: advanced Safari settings (block all cookies, disable JavaScript, tracking block) are global, applying to all profiles. If you want to toughen these toggles, do it globally in Settings, Apps, Safari, knowing it’ll affect your default profile too.

When to Switch to the “Sensitive” Profile

Clicking on a link from an unknown sender. Medical or legal research. Bank or broker login. ProtonMail on the web from a less-used device. Any site you’re unsure about and don’t want to cookie your main profile with. Two taps, switch, do what you need to do, switch back.

Usage segmentation, not global hardening. Keep your comfort on your default profile, have a “clean navigation” mode on hand.

What It Doesn’t Replace

Safari profiles aren’t Lockdown Mode. JIT JavaScript remains active on all profiles. If you’re a journalist handling sensitive sources, a lawyer on a sensitive case, a dissident, or if you’ve received an Apple threat notification, use global Lockdown Mode. Safari profiles are a tool for daily use, not state actor protection.

Basic hygiene doesn’t change: patch (iOS 26.5 now), don’t open unexpected attachments, verify URLs before entering passwords.

Sources

Proton Mail switches to post-quantum encryption (and it's free)

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

Proton Mail now offers an encryption option that’s quantum-resistant. Available on all plans, even the free one. You’ll need to turn it on yourself, and it only works for new emails.

What you need to watch out for

1. Enable the option in Settings, Encryption and keys, but don’t think it’ll protect your old emails, it only works for new ones.

2. The benefit is maxed out when the person you’re sending to is also on Proton. If they’re on Gmail or elsewhere, it’s back to classic encryption for that send.

3. End-to-end encrypted forwarding is temporarily incompatible. If you’re using it, pick one or the other until it’s fixed.

Proton Mail has just activated an option that protects your new emails against decryption by a future quantum computer. It’s available on all plans, including the free one, and you can enable it yourself. And it’s not just marketing.

The Fact

On May 5, 2026, Proton pushed a new option into Proton Mail’s settings: « Enable post-quantum protection ». Once enabled, new emails you send are encrypted with a combination of classical plus post-quantum algorithm, a type of cryptography designed to resist even a quantum computer of tomorrow. Available on all plans, including free, which is rare enough in the industry to warrant mention.

The option is not enabled by default. You go to Settings, Encryption and keys, and check it yourself. Proton justifies this caution due to the still-experimental status in the external ecosystem.

The idea behind it is to counter what’s called « harvest now, decrypt later ». In plain terms: an attacker could intercept and store your encrypted emails today, unable to read them, hoping to decrypt them in ten or twenty years when a powerful enough quantum computer exists. Today’s classical encryption (RSA, elliptic curves) would crumble like a house of cards. Post-quantum is the insurance that even this scenario yields nothing to the attacker.

Why It Matters to You

Several things to know before you rush to enable it.

The protection applies only to new emails. Anything already in your mailbox, sent or received before enabling, remains encrypted as before. Proton says so: « 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. » If your old emails have already been intercepted by someone, this option doesn’t change anything for them. The « for now » suggests a retroactive re-encryption is on the roadmap, but it’s not delivered yet.

The recipient matters. The best scenario is Proton to Proton, where both sides have post-quantum keys. If your correspondent is elsewhere (Gmail, a classic OpenPGP client, etc.), Proton falls back on the usual encryption for that send, which is the only reasonable thing to do while waiting for others to adopt the same standard.

Some friction. If you’re using Proton’s end-to-end encrypted forwarding, it’s temporarily incompatible with the new option. You choose one or the other for now. There’s also a slight performance impact on sending, barely noticeable on recent hardware according to Proton.

The Game-Changer Angle: Open Standard vs Silos

Proton isn’t the first email service to offer post-quantum. Tuta (ex-Tutanota) did so since 2024, with its own proprietary scheme. Apple deployed PQ3 on iMessage in February 2024. Signal did the same with PQXDH in September 2023.

Proton’s difference is that it does so on OpenPGP, the open standard others can adopt. Apple PQ3 remains locked in the Apple ecosystem, Signal PQXDH doesn’t leave Signal, and Tuta’s scheme is proprietary to Tuta. Proton, meanwhile, bets on standardization, announced collaboration with the Thunderbird project, so tomorrow your sovereign email client (Thunderbird, GnuPG, or another) can read and write post-quantum emails compatible with Proton without going through the Proton app itself.

That’s the sovereignty angle. An open standard is what prevents your communication security from depending on the whim of a single provider. Today in practice, interop is still largely Proton-to-Proton, the external ecosystem isn’t there yet. But the direction is set, and that’s what distinguishes this announcement from mere marketing.

What You Do Now

1. Go to Proton Mail, Settings, Encryption and keys, and enable « Enable post-quantum protection ». Read the warning banner (forwarding, etc.) before validating.

2. Keep in mind that it only protects your new sends. If you have sensitive conversations archived, consider sorting them out. Retroactive re-encryption is coming later, but for now, it’s pure conditional.

3. If your correspondent is also on Proton, encourage them to enable it on their end. Until both ends are equipped, the benefit remains partial.

4. If you’re using Proton Bridge with Apple Mail (see the dedicated article), ensure your Bridge is up-to-date, or new post-quantum emails might not be readable on the local client side.

Also See

Sources

iOS 26.5 finally encrypts RCS iPhone-Android (but Signal still leads)

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

Apple Enables End-to-End Encryption on RCS Messages with iOS 26.5

Your iPhone-Android chats won’t be passing through clear SMS anymore. A real step forward, but RCS protocol still falls short of Signal for sensitive conversations.

What You Need to Watch Out For

1. Enable Advanced Data Protection on iCloud to encrypt your backups end-to-end as well.

2. Keep Signal for sensitive stuff: it’s the only one where your keys never leave your device and metadata doesn’t leak to operators or Google.

3. Make sure your Android contacts support RCS, or you’ll be back to clear SMS.

Apple finally enables end-to-end encryption for RCS messages with iOS 26.5. Your iPhone-Android exchanges are no longer in clear SMS, but the protocol still falls short of Signal for sensitive matters.

The Deal

Apple confirmed on May 4, 2026, that iOS 26.5 (release candidate available, stable public expected around May 11-12) integrates end-to-end encryption for RCS messages exchanged between iPhone and Android. In practice, when you send a message from your iPhone to your friend’s Samsung, the content will be encrypted E2EE according to the Universal Profile 3.0 profile, published by the GSMA in March 2025, which relies on the MLS (Messaging Layer Security) protocol, an audited IETF standard, the same foundation used for the future interoperable encryption of Matrix and other messaging platforms.

Note: Apple specifies that the feature remains in beta even in iOS 26.5 stable, and it depends on operator support on both sides (iPhone and Android on RCS UP 3.0 compatible operators). A lock icon in Messages will indicate when the channel is actually encrypted, and a toggle has been added in Settings > Messages.

This ends a long-standing anomaly: cross-platform exchanges went through SMS/MMS, thus in plaintext, interceptable by any operator or state actor along the way. Google pushed RCS since 2019, Apple dragged its feet. The timing is no coincidence: pressure from the GSMA, operators, and repeated public criticism about the security of cross-platform SMS seems to have sped up Cupertino’s schedule.

Why It Matters to You

If you use iMessage between Apple devices, nothing changes: your channel remains E2EE as before. The real gain is for exchanges with the Android ecosystem, which represents 70% of the global market. Until now, these conversations fell into SMS (plaintext) or MMS (destructive compression, zero encryption). With RCS E2EE, you finally get decent protection by default.

But let’s keep a cool head. RCS encryption relies on operators’ and Google’s (which provides Jibe, the dominant RCS backend) infrastructure. Keys transit through their servers during session establishment. It’s not like Signal, where you control the entire chain. For sensitive conversations (lawyer, doctor, journalistic source, confidential business deal), Signal remains the gold standard: audited protocol, minimal servers, reduced metadata, open-source code.

The other thing to watch: Apple hasn’t confirmed if iCloud backups of RCS conversations will be encrypted E2EE. Without Advanced Data Protection enabled, your RCS messages could end up in plaintext on Apple’s servers, nullifying the benefit of transit encryption.

What You Do Now

1. Enable Advanced Data Protection on your iCloud account (Settings > Apple Account > iCloud > Advanced Data Protection). Without it, your backups remain accessible to Apple and judicial requests. Note: ADP covers Messages backups, but not iCloud Mail, Contacts, and Calendar, which remain outside E2EE by design.

2. For really sensitive conversations, stick with Signal. RCS encryption is progress for everyday use, not a replacement for the sovereign gold standard.

3. Check if your Android contacts have RCS enabled. The reliable indicator of effective encryption will be the dedicated lock icon in Messages (announced by Apple), not the bubble color (green = SMS/RCS, blue = iMessage, unrelated to E2EE). An Android on an operator that doesn’t support RCS UP 3.0 takes you back to clear SMS.

4. Update to iOS 26.5 once the stable release is out to enjoy the encryption. Betas are nice for testing, but not for your daily driver.

Trellix: Cybersecurity software partner of Europol gets source code stolen

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

Trellix, a cybersecurity partner of Europol, announced on 02/05 an unauthorized access to a portion of its source code. No evidence of exploitation, according to the vendor, but this statement needs verification.

What you should watch out for

1. The exact perimeter of the intrusion (affected products, duration, attribution), which Trellix has not yet communicated as of 03/05.

2. Any official communication from Trellix in the coming weeks, or the possible appearance of the code in plain sight on a forum.

3. If you have Trellix on your network, ask your reseller in writing for the list of affected products and schedule a configuration review; if you have another EDR, don’t switch vendors on a whim.

Updates

04/05/2026, Day+2, external press confirmation on cybersecurity

BleepingComputer picks up Trellix’s disclosure and sets the scale: over 50,000 enterprise and government clients, over 200 million endpoints under protection. Trellix specifies that the accessed code is “product development code” and “does not include customer environments or data.” The company’s statement, to be verified like the rest, but it’s a framed assertion, not silence.

No new technical details: perimeter remains unclear, intrusion duration and attribution not communicated. The “maybe it won’t come out” window is closed, the incident is now officially picked up by the reference cybersecurity press.

Source: BleepingComputer, 04/05/2026

The hunter got hunted

Trellix sells EDR (the thing that watches your machines’ processes to spot suspicious behavior) to enterprises and governments. Trellix is also an industry partner of Europol for major takedown operations of recent years: Endgame in November 2025 (1025+ servers Rhadamanthys, Elysium, and VenomRAT dismantled), Cobalt Strike in July 2025. John Fokker, Trellix’s threat intelligence manager, even gave an interview to The Register four weeks ago explaining how Trellix helps take down ransomware operators.

On May 2, 2026, Trellix officially announced on its website that an unidentified actor had gained unauthorized access to a “portion” of its source code. Digital investigation experts mandated, authorities notified, investigation ongoing, standard phrases. It’s their own code that got lifted.

You can phrase it politely, or you can phrase it frankly: the security editor that hunts attackers for Europol got its repo visited. And if you think that’s embarrassing for Trellix, you’re not wrong. If you think it’s isolated, though, you haven’t been following the news for the past decade.

What we know, sourced

According to Trellix’s official statement published on May 2, 2026, an unidentified actor gained unauthorized access to a “portion” of its source code, with a deliberately vague perimeter. The company has mandated digital investigation experts and notified authorities. Details are picked up verbatim by The Hacker News, Security Affairs, and several other cybersecurity press sources. For context, Trellix is an industry partner of Europol for operations Endgame (November 2025, 1025 servers Rhadamanthys, Elysium, and VenomRAT dismantled) and Cobalt Strike detour (July 2025).

The story is confirmed but young. It’s a SIGNAL, not yet an ALERT.

What Trellix says, what nobody knows

Trellix makes two assertions in its statement: “no evidence that source code has been exploited” and “no impact on client products or distribution pipeline.” Take these two assertions as you would any company’s statement after a breach: it’s the victim’s version. Not necessarily a lie, but not a verified fact either. “No evidence” on day one means investigators haven’t had time to dig yet.

The rest is official fog.

Unanswered questions by Trellix as of 03/05/2026

Which products are affected (EDR, XDR, SIEM Helix, historic McAfee Enterprise or FireEye/Mandiant code)

When the intrusion started, how long it lasted

How it was detected (internal alert, external report, ransom demand)

What platform hosted the repo (GitHub Enterprise, GitLab self-hosted, Azure DevOps)

Attribution: no name, no group, nothing

Customer data: radio silence, Trellix only talks about code

None of these answers are mandatory on disclosure day, let’s be honest. The classic timeline for an incident like this takes weeks. But that’s precisely why we should trace the uncertainty now, not dilute it in a reconstructed timeline three months later, when everyone will have forgotten that no one knew anything on May 3.

What it reminds us of (and what it doesn’t)

To frame it: a top-tier cybersecurity editor getting its source code lifted is neither new nor anecdotal. FireEye in 2020 (Sunburst, Red Team tools exfiltrated). SolarWinds the same year (poisoned build chain). Kaseya in 2021 (REvil via supply chain). CrowdStrike in July 2024 (not an intrusion, but a botched push that crashed 8.5 million Windows machines). None of these incidents are strictly comparable to what’s happening to Trellix, and that’s the point: they don’t look alike, but they tell the same structural story. No cybersecurity editor is a sanctuary, including those that hunt attackers for states.

What it doesn’t remind us of, though: we don’t know if we’re looking at a Sunburst-type incident (compromised supply chain with persistence in client products) or just a repo lift (code out, no downstream impact). Trellix says the latter. The investigation will tell if that’s accurate. Until then, “Trellix says” and “confirmed” are not the same thing.

What you do now

1. If you have Trellix EDR or XDR on your fleet. Set an alert calendar for 30 days to monitor Trellix communications and ask your reseller or account manager for the exact list of affected products (response often vague at first, follow up). Use this window to plan that configuration review you’ve been putting off for six months. Don’t panic, don’t uninstall in the middle of the night.

2. If you have another EDR. Don’t switch vendors on a whim. The grass isn’t greener elsewhere, ask those who switched to CrowdStrike just before July 2024. Keep monitoring, and use this incident as a reminder that your security posture can’t rely on a single layer, no matter the vendor.

3. If you’re a Mac user. It doesn’t change anything about your daily life today. Trellix isn’t a consumer product for Apple. What concerns you is the reminder: your antivirus, your EDR, your VPN, your password manager are all vendors that can get breached. Defense in depth isn’t just a slogan. Your security is open-source self-hosted and multi-layered. We’ll revisit this soon.

This ransomware negotiator worked for the gang, so your backups are still your only guarantee.

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

An American ransomware negotiator pleaded guilty to secretly working for the gangs he was supposed to fight. This case highlights a structural issue: the entire post-incident ecosystem (negotiators, insurers, consultants) has an interest in you paying.

What this means for you

1. Your client-side encrypted backups (Kopia, zero-knowledge) and tested remain your only reliable guarantee, third-parties can be compromised.

2. Segment your network so ransomware can’t reach your backups. Tailscale mesh.

3. Document your response procedure BEFORE the incident, without relying on intermediaries.

The Deal

An American cybersecurity consultant has just pleaded guilty in a federal court. Their official job: negotiating with ransomware gangs on behalf of victim companies. Their real activity: secretly informing these same gangs about the negotiation status, victims’ payment capabilities, and sabotaging recovery attempts that could’ve avoided ransom payment.

The scheme is elegantly perverse. You call an “expert” to get you out of a mess, and this expert works against you from the start. They know your financial reserves, they know your backups are useless, and they’re playing both sides.

This isn’t an isolated case of a greedy individual. It’s a structural symptom of a market where everyone involved benefits from you paying. The negotiator (commission on the ransom), the cyber insurer (premium adjusted to perceived risk, not real), the gang (direct revenues). You’re the cash cow.

Why This Matters to You

If you’re reading MacSouverain, you probably already have an aversion to unverifiable third-party trusts. This case clinically confirms why.

The problem isn’t just that one guy was corrupt. The problem is that the ransomware business model creates incentives for everyone around you to prefer that you pay. Cyber insurance? It reimburses you (partially), so it doesn’t fight payment, it facilitates it. The negotiator? Paid by results, and “results” mean closing a paying deal (with commission) to restore your data.

When the entire ecosystem is aligned against you, the only tenable position is not to rely on it. No negotiator if you can restore alone. No cyber insurance as the main strategy if your backups are solid. Technical autonomy first, external recours as a last resort.

What You Do Now

1. Check that your backup strategy follows the 3-2-1-1 rule: three copies, two different media, one off-site, one offline (air-gapped). Kopia encrypts everything client-side before sending (zero-knowledge), destinations (B2, S3, NAS, SFTP) see only opaque, deduplicated blobs, indecipherable without your passphrase. If the server is compromised, your repo remains unreadable.

2. Test your restoration. A backup never tested is as good as none. Schedule a quarterly exercise where you actually restore a system from scratch.

3. Segment your network. A ransomware hitting your workstation shouldn’t have direct access to your backup NAS. Tailscale mesh wireguard + strict ACLs between segments.

4. Document your response procedure BEFORE the incident. Who you call (and why you trust them), which machines you isolate first, where your restore keys are. Not in Notes iCloud without ADP, nor in any shared doc in plaintext.

Apple Q2 Results: Behind the Hype, the Subscription Services Question

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

Apple posts a solid quarter with a healthy Mac and double-digit growth in Services. For those using Apple’s ecosystem as a sovereignty pivot, it’s a confirmation: hardware remains robust, but the cloud lock-in temptation grows stronger.

What this means for you

1. The Mac and iPhone remain strong long-term, Apple’s in great shape.

2. Services growth means more pressure to lock you into iCloud, Apple Music, Apple One.

3. Your sovereign stack (ADP + Proton + Etebase) becomes an active choice, not a compromise.

The Deal

Apple’s just dropped its Q2 FY2026 results, and as Jason Snell sums it up on Six Colors: “net-net over the moon”. Translation for non-accountants, Wall Street’s thrilled and Cook can sleep easy.

Macs keep cruising post-Apple Silicon with solid sales. iPhones hold their own despite a lackluster global smartphone market. iPads stay steady, which is almost a win given the tablet market’s state. But the real growth engine, the one making analysts’ eyes gleam, is Services.

This catch-all category (App Store, Apple Music, iCloud, Apple TV+, Apple One, Arcade, News+, Fitness+) now makes up a significant chunk of revenue and, more importantly, margins. Apple’s not just selling hardware anymore, it’s peddling a perpetual subscription to its ecosystem.

Why It Matters to You

Good news first, Apple hardware’s still a safe bet. If you’ve invested in a Mac Studio, MacBook Pro M3, or iPhone as your tech stack’s backbone, you’re not on a sinking ship. Apple’s financial health ensures your material investment won’t be orphaned in three years.

Now, the part that deserves your critical attention: this Services growth isn’t neutral. Every percentage point gained means Apple’s grip tightens.

As iCloud becomes more central, the path to Proton Drive looks like an off-road hike. The more Apple One seems “economic”, the more dependence you’re paying for with your euros.

For us practical sovereignty folks, these results are a reminder. Apple’s not your ideological ally, it’s your hardware supplier. An excellent one, but a supplier nonetheless.

Its Services growth is its strategy to keep you captive. Your counter-strategy? Enable Advanced Data Protection, use Proton for mail and calendar, Etebase for contacts, and be clear about what you’re voluntarily delegating versus what’s imposed by default.

What You Do Now

1. Check if Advanced Data Protection is enabled on your iCloud account (Settings > Apple ID > iCloud > Advanced Data Protection). It’s the bare minimum to keep your iCloud E2EE (we’ve explained why here).

2. Audit your Apple One subscription if you have one. Which services are you actually using? Apple Music might justify itself, but iCloud+ beyond 50GB deserves thought.

3. Identify your critical data (passwords, pro contacts, sensitive documents) and confirm they’re passing through your sovereign stack: Vaultwarden or Proton Pass for credentials, Etebase for contacts, Proton Drive for E2EE cloud files.

4. These results don’t change anything short-term. But they confirm the direction, Apple’s pushing Services, and your vigilance needs to keep pace.

Anthropic's MCP, A design flaw exposes 200,000 instances to remote code execution

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

**OX Security published on April 15, 2026 a architectural vulnerability in Anthropic’s Model Context Protocol (MCP): the STDIO interface of the official SDKs allows for the execution of arbitrary OS commands from the configuration. 7,000+ public servers, 150M+ downloads, and approximately 200,000 instances are exposed. On the Mac side: Cursor, Windsurf, and Claude Desktop are concretely affected via their MCP integrations. Anthropic refuses to patch: “by design”.

What you need to do

1. If you’re using Cursor, Windsurf, or Claude Desktop with installed MCP servers: audit the list of connected MCPs, disable ones you haven’t explicitly verified, and never load a MCP configuration from a third party (gist, forked GitHub repo, Slack share) without reading it entirely.

2. Update to the patched versions of the affected tools (LiteLLM, LangFlow, Windsurf, Flowise, DocsGPT, GPT Researcher, Bisheng, Agent Zero), at least 10 CVEs issued (CVE-2026-30615 Windsurf via malicious HTML, CVE-2026-30623 LiteLLM, CVE-2025-65720 GPT Researcher, etc.). Also update Cursor and Claude Desktop, which use the MCP SDKs without their own CVE.

3. If you’re hosting an exposed MCP server in a network: block public access, place it in a sandbox with restricted permissions, monitor invocations.

4. Consider all external MCP configs as untrusted by default: Anthropic considers sandboxing the responsibility of the developer, not the protocol.

You’ve installed Cursor or Windsurf on your Mac to develop with an LLM assistant. You’ve added a few MCP servers, one for your DB, one for your API, one for local files. This stack, which seems “home-made”, is actually built on a protocol whose main interface considers that any configuration can run any shell command. And according to OX Security, this isn’t a bug: it’s Anthropic’s official interpretation.

What’s Happening

On April 15, 2026, OX Security’s research team published a report titled “The Mother of All AI Supply Chains”. The finding: Anthropic’s Model Context Protocol (MCP) - the standard protocol for connecting tools, data, and services to an LLM - has an architectural flaw in its STDIO interface. Configurations can directly trigger the execution of arbitrary system commands, without control, without input sanitization, without default isolation.

The figures documented by OX:

7,000+ public MCP servers indexed
150 million+ downloads of the affected SDKs and servers
~200,000 instances estimated to be vulnerable
10 CVE emitted (status patched or pending)
Practical validation: commands executed successfully on 6 production platforms

Notable CVEs:

CVE-2026-30615 (Windsurf, pending) : prompt injection via malicious HTML leading to local RCE, CVSS 8.0 (HIGH).
CVE-2026-30623 (LiteLLM, patched) : authenticated RCE via JSON configuration.
CVE-2025-65720 (GPT Researcher, pending) : UI injection leading to reverse shell.
And others on LangFlow, Flowise, DocsGPT, Bisheng, Agent Zero, Fay Framework, Langchain-Chatchat, Upsonic.

OX describes four distinct attack families, all exploiting the same primitive: configuration → command without boundaries.

Anthropic’s position, as reported by OX and confirmed by other sources (THN, devops-daily): the behavior is “by design”. The STDIO execution model is considered “secure default” if the user does their job of sanitizing inputs. Anthropic refuses to modify the protocol.

Why It Matters to You

You’re not an LLM cloud operator, you don’t have 50,000 public MCP servers. But if you’re a MacSouverain reader, it’s very likely that:

You’re using Cursor, Windsurf, or Claude Desktop on your Mac, all of which have official MCP integrations written with the vulnerable Anthropic SDKs.
You’ve connected 1 or 2 MCP servers, typically an MCP filesystem, an MCP DB, an MCP shell, an MCP Notion. Each of them is a potential attack surface.
You’ve imported a shared MCP configuration, a GitHub gist, a claude_desktop_config.json file from a public repo, an export from a colleague. That’s exactly the primary vector: the config can trigger execution.

Anthropic’s “by design” argument is defensible technically (a protocol isn’t a sandbox). But Anthropic shifts the responsibility for sandboxing to downstream developers, in a context where:

General users are adopting Claude Desktop without devsecops training.
Official SDKs are published without pre-installed mitigation documentation.
Patches come from downstream tools (Cursor, Windsurf, etc.), not the protocol itself.

What You Need to Do

Immediate (this week):

Inventory your active MCPs. On Cursor: Settings → MCP. On Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json. On Windsurf: check the list from the IDE. Disable any MCP that you haven’t deployed yourself or validated by reading its source code.
Update Cursor, Windsurf, and all LLM-native tools to the patched versions (≥ April 2026). Check the release notes to ensure the relevant CVE is explicitly fixed.
Audit shared configurations: if you’ve retrieved an MCP config from a public repo, Slack, gist, Discord, read it entirely before activating it. The executable paths, commands, environment variables. An MCP configuration is a disguised shell script.

Within the week:

For the MCP filesystem or shell servers you keep: limit their scope to the bare minimum. No / or ~ paths. Give the precise project-specific subfolder.
For the MCP servers running as local HTTP servers: ensure the port isn’t bound to 0.0.0.0. It should be 127.0.0.1. Otherwise, a malicious web page via browser can trigger execution.

To monitor:

Anthropic’s position may evolve if community pressure increases. Monitor the official MCP SDK’s release notes (@modelcontextprotocol/sdk on npm, mcp on PyPI) for a potential “strict” or “sanitize-by-default” mode.
Downstream tools (Cursor, Windsurf, Claude Desktop) may add sandboxing layers, check their security documentation in the coming weeks.

Sources

OX Security, “The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of Anthropic’s MCP”, April 15, 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”, April 15, 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”, April 20, 2026, https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html
DevOps Daily, “The MCP Design Flaw That Exposes 150M Downloads to RCE”, April 15, 2026, https://devops-daily.com/posts/mcp-design-flaw-rce-supply-chain-risk

Mythos, the model that finds bugs on its own, just leaked

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

Anthropic keeps a model, Mythos, under lock and key, capable of finding zero-day flaws on its own across iOS, macOS, Windows, and browsers. An unauthorized group, including an Anthropic subcontractor employee, gained access to it after the program’s announcement, via a guessed URL.

What you need to do

1. Install pending updates on your Mac and iPhone, and enable automatic updates.

2. Filter unknown senders in iMessage and block unknown callers on your iPhone.

3. Be wary of links and attachments, permanently.

Anthropic Locks Away Model Capable of Finding Zero-Day Flaws on Its Own

Anthropic has kept under lock and key a model capable of finding zero-day flaws all by itself. An unauthorized group gained access to it after the program’s announcement, simply by guessing the URL. The day this capability goes from defensive to offensive, it’s no longer a movie scenario.

What’s Happening

Mythos is the name of the model Anthropic deemed too dangerous for public access. Its specialty: discovering zero-day vulnerabilities on major OSes and browsers independently, chaining multiple bugs into full exploits, conducting complex cyber ops with minimal human intervention. In internal tests, Mythos unearthed “thousands” of major vulnerabilities. Bloomberg sums it up: Mythos is far ahead of any other AI model in cyber capabilities.

Access was supposed to be locked down. A limited program called “Project Glasswing” was opened to Apple, Amazon, Microsoft, and Nvidia. Some U.S. government agencies have access, but not CISA. TechCrunch and Bloomberg reported on April 21 that a small group of unauthorized users found the endpoint by guessing the URL based on Anthropic’s usual naming conventions.

One of them works for a third-party subcontractor of Anthropic. The exchanges happen in a private Discord dedicated to tracking unpublished models. Regular access since the day of the announcement. No offensive use detected yet. Anthropic confirms the investigation and sees “no evidence of impact” on its systems.

Why It Matters to You

This is the first time a publicly documented model capable of finding flaws in series has escaped its intended perimeter. For now, the intruders are just keeping watch. But the capability is in hands that shouldn’t have it, with a third-party subcontractor employee in the loop. The history of digital weapons has a constant: they start with state targets and end up on crypto phishing sites targeting individuals. An AI that finds zero-days on its own, that was worth billions five years ago. It just leaked onto a Discord.

Practically, the tech that can secure macOS tomorrow can also produce an exploitable iOS exploit for an actor without an NSA budget. Anthropic finds “thousands” of vulnerabilities internally, so the stock isn’t a problem. CISA, which coordinates cyber response in the U.S., isn’t in the loop. Australia’s regulatory authority is monitoring the situation. Bloomberg even titled a podcast episode about it: “Will Mythos Save or Break the System?”

What You Need to Do

1. Now: Update your Mac, iPhone, and Safari. Mythos targets major OSes and browsers, deployed patches close doors an AI might push. It’s not paranoia, it’s hygiene.

2. Turn on automatic updates: Settings → General → Software Update → check all (download + install + Quick Security Responses). On Mac and iPhone. The next critical patch might drop on a Tuesday at 11 PM, you don’t want to rely on it.

3. Filter invisible vectors on iPhone: Settings → Messages → “Filter Unknown Senders”. Settings → Phone → “Filter Unknown Callers”. That neutralizes doors exploits like Pegasus use to reach a phone: an iMessage or FaceTime call from an unknown number.

4. Be wary of links and attachments: Not just for the next few weeks, but from now on. An “outstanding invoice” email pushing a boobytrapped attachment doesn’t need an expert developer anymore.

5. Keep an eye on: Anthropic’s investigation progress, any potential iOS/macOS CVEs without claimed authors in the next few weeks, CISA’s statements when they break their silence.

Sources

TechCrunch, April 21, 2026
Bloomberg, April 21, 2026
Axios, April 21, 2026
Bloomberg, Mythos Background, April 16, 2026

GPT-5.5 ups the ante in cybersecurity capacity-class. OpenAI tightens access.

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

OpenAI officially classifies GPT-5.5 as “High” cybersecurity capability. The model can run multi-day vulnerability research campaigns, produce basic exploit memory blocks on hardened systems, and saturate professional hacking competitions. OpenAI has tightened its input filters and restricted access to modes where AI can chain multiple vulnerabilities on its own.

What you need to watch out for

1. Keep your Mac and iPhone strictly up-to-date. The window between bug publication and AI-assisted exploitation is closing.

2. Reduce your browser attack surface (Safari, minimum extensions, no Chrome on the main Mac).

3. On exposed devices (frame, journalist, activist), enable Lockdown Mode, not just for GPT-5.5, but for the class of tools it represents.

4. Keep an eye on the next two major system cards (OpenAI, Anthropic). That’s where we’ll see if the Critical cybersecurity bar drops in 2026.

OpenAI has released GPT-5.5 on April 23rd and published its system card at the same time. This document formalizes what Mythos had opened the door to: large models have entered the “High” cybersecurity class. They haven’t quite reached “Critical” yet, but the gap is closing fast.

Here’s what’s happening:

In OpenAI’s Preparedness taxonomy, cybersecurity is divided into three tiers. “Medium” is a model that helps an attacker move faster. “High” is a model that amplifies existing severe attack paths. “Critical” is a model that opens paths no human could traverse alone, like producing functional zero-day exploits autonomously on hardened production systems.

GPT-5.5 crosses the “High” threshold. The system card details why: on VulnLMP (OpenAI’s internal vulnerability testing bench), the model runs multi-day vulnerability hunting campaigns, finds exploitable memory bugs in supposedly locked-down systems, and builds the basic blocks of a functional exploit. What keeps it from “Critical” isn’t the scale of the search, but the judgment, knowing which of the thousand crashes is worth spending a week on.

On closed playing fields, GPT-5.5 dominates pro hacking competitions, solves 7 out of 11 CyScenarioBench scenarios (compared to GPT-5.4’s 5), and achieves 93.33% success on cybersecurity training grounds. OpenAI’s cost per success is divided by 2.7 to 3. For OpenAI, this justifies toughening up, stricter input filters, more cybersecurity request denials, and restricted access to modes where AI chains multiple vulnerabilities together.

Why this matters to you:

The general public sees GPT-5.5 as a marketing update. But with the right glasses on, it’s an offensive capability milestone. In six months, we’ve gone from “AI helps a human write an exploit” to “AI runs multi-day vulnerability hunting campaigns and produces usable exploit building blocks.” The system card is explicit: this isn’t theoretical anymore, it’s measured.

The model itself remains contained. What’s less contained are open-source competitors advancing in parallel and their tweaked versions circulating weekly on community platforms. For an amateur downloading an open-source model of equivalent level with removed filters, the bar is lower than you might think.

On Anthropic’s side, what we know about Mythos suggests it’s already in this zone, just under lock and key (well, when it doesn’t leak. Oops, it did!). On OpenAI’s side, GPT-5.5 is still a step below, but the gap is narrowing. The threshold should be crossed in the next public system card, in six to nine months.

Apple’s direct consequence is obvious. A model capable of tracking memory bugs in supposedly locked-down systems is interested, by definition, in what Apple does for iOS hardening (memory protected against manipulations since iPhone 15 Pro and Mac M2, app isolation on macOS, system locked in read-only). As long as Apple maintains its lead on the attack surface, your up-to-date Mac is very hard to compromise, but the gap is now measured in weeks, not months.

What you need to do:

1. Immediately: Update macOS, iOS, Safari, and all your third-party browsers. The gap between CVE publication and IA-assisted exploitation has shrunk, each patch counts more than it did six months ago.

2. Reduce your browser attack surface: Use Safari in strict mode, minimize extensions, and especially don’t use Chrome on your main Mac.

3. If you’re exposed (journalist, activist, executive, crypto holder): Enable Lockdown Mode on iPhone and Mac.

4. Keep an eye on: The next OpenAI and Anthropic system cards. If either of them crosses into “Critical” cybersecurity in a public system card, it’s time to re-evaluate your update and backup practices, not panic, but tighten the screws.

Sources:

OpenAI, GPT-5.5 System Card, April 23, 2026
OpenAI, GPT-5.5 System Card (main hub), April 23, 2026
CNBC, OpenAI announces GPT-5.5, April 23, 2026
TechCrunch, GPT-5.5 superapp, April 23, 2026

See also:

The model that finds bugs all by itself just leaked, April 21, 2026
Claude Opus turns a bug into an exploit for $22, April 2026

A consumer-grade AI cooked up a Chrome exploit for $2,283.

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

A researcher asked Claude Opus 4.6, the same model accessible to anyone for a monthly subscription, to create code to exploit a fixed Chrome bug. Result: Discord opens your Mac’s calculator without your permission. Researchers’ security convention: if calc opens without asking, anything can open. Discord, Slack, Teams, Notion all run on Chrome under the hood and patch late. Operation cost: $2,283.

What you need to do

1. Update Chrome, Safari, Firefox, Edge on your Mac tonight.

2. Open Discord, Slack, Teams and check they’re running the latest version.

3. Uninstall any abandoned app (no update in over 6 months).

What’s happening

Starting point: a bug in Chrome, fixed and made public. In the security world, “fixed publicly” means the exact nature of the problem is now accessible to everyone, in Google’s official database. Not a secret, a known flaw, documented, with the fix readable by anyone.

Mohan Pedhapati, a security researcher at Hacktron, submitted this bug to Claude Opus 4.6 with a simple question: build me the code to exploit it.

After 20 hours and 1,765 exchanges with the model: a program that runs in Discord and opens your Mac’s calculator. No data theft, no destruction. The calculator. That’s the security researchers’ tradition: when they want to prove a vulnerability lets someone run a program on your machine without your permission, they prove it by opening calc. Harmless, but eloquent: if someone can open the calculator without asking, they can just as well run anything else.

Total bill: $2,283. The model that counts calories in your recipes can also, with guidance and patience, write a browser exploit.

Why it’s important for you

“In Discord” isn’t incidental. Discord, Slack, Teams, Notion, Spotify, VS Code: none of these apps are native. They’re web apps disguised, built on Chrome’s engine. Result: when Chrome fixes a bug, these apps keep running on the old version until they update on their own. Discord was still running on a vulnerable Chrome version when Pedhapati published his exploit. The official fix had been available for weeks.

The implications are wide. Before this study, turning a fixed bug into a functional exploit took years of specialized expertise. Now, it takes $2,283 and someone who knows how to ask the right questions to a model. The list of fixed Chrome bugs is public. The list of apps lagging in patches is too.

It’s exactly what Schneier described as inevitable about Mythos, and it’s happening, not with a military model.

What you need to do

→ Immediate: update Chrome, Safari, Firefox, Edge on your Mac tonight. The latest Chrome version fixes the exact bug used in the study, but the point is there will be others like it. Otherwise, do what I do: uninstall Chrome and switch to Safari. But that’s another conversation.

→ This week: review the “web disguised” apps on your Mac. Discord, Slack, Teams, Notion, Spotify, VS Code, 1Password desktop if you still use it. For each, check preferences to ensure automatic updates are on and you’re running the latest version. An app that’s abandoned or rarely updated becomes a prime target.

→ To watch: the reaction of Discord, Slack, and others to the update frequency of their internal engine. The arrival of commercial services packaging this kind of experimentation, today a researcher in a lab, tomorrow a product on the darknet. The first real campaigns using AI-assisted browser exploits against poorly maintained apps. If it happens, that’ll be another conversation.

Sources

Security Affairs - April 20, 2026
Hacktron Study - Pedhapati - April 20, 2026
Schneier on Mythos - April 13, 2026 (context)

Also see

[[radar-extensions-chrome-malveillantes-avril-2026|Malicious Chrome Extensions]]
[[radar-tcc-macl-avril-2026|TCC macOS: Permission Bypass]]
[[radar-agents-ia-anssi-avril-2026|AI Agents: ANSSI Risks]]

Mastodon Post

🚨 Claude Opus 4.6 (public subscription) has fabricated a functional Chrome exploit.

Security researchers’ convention: prove a vulnerability by opening the target machine’s calculator without permission. If calc opens without asking, anything can open.

Result here: Discord opens your calculator without authorization. 20 hours of work, 1,765 model exchanges, for $2,283.

Discord, Slack, Teams, Notion run on Chrome under the hood. They patch late.

1️⃣ Update Chrome, Safari, Firefox, Edge tonight 2️⃣ Update Discord, Slack, Teams, Notion, VS Code 3️⃣ Uninstall abandoned apps

Not the NSA’s Claude Mythos. Your recipes’ Claude, that’s scary.

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

AI #security #Chrome #Mac

Age verification EU, hacked in 2 minutes, poorly coded surveillance

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

The EU’s Age Verification App, launched on April 14th, was bypassed in under two minutes. Editable config, boolean for biometry, PIN not linked to identity vault. The EUDI Wallet standard had zero-knowledge (SD-JWT VC, IRMA/Yivi, AnonCreds) in mind. Yet, the implementation ignored it.

The Real Scandal

The EU wrote the right standard. The reference app betrayed it.

Keep an Eye On, same EUDI architecture set to be used tomorrow for IDs, prescriptions, taxes, 450 million Europeans.

The EU’s age verification app, launched on April 14, 2026, was bypassed in under two minutes. The real scandal isn’t the bug, it’s the implementation choice.

The Facts

On April 14, the Commission unveils its age verification app, a cornerstone of the online child protection system across the 27 member states. Three days later, British consultant Paul Moore publishes a demo, completely bypassing it in under two minutes. French cryptographer Olivier Blazy confirms the diagnosis. A moratorium signed by 400+ researchers had already warned in March. No one listened.

The Three Flaws

Editable config, the encrypted PIN is stored in eudi-wallet.xml, locally modifiable.
Boolean biometrics, a true/false flag governs biometric auth. Flip, skip.
PIN not linked to the vault, an attacker redefines the PIN by reusing previous profile credentials.

The Alternative Existed, Within the Standard Itself

The EUDI Wallet standard allows for selective disclosure via SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credentials), proving one’s age without revealing birthdate or linking sessions, using zero-knowledge proofs. Implementations like IRMA/Yivi (Radboud University), AnonCreds (Hyperledger), and Google ZK age assurance already exist.

The EU wrote the right standard. The reference app betrayed it by storing the PIN in an editable XML.

The Pattern

Same logic as Chat Control / CSAR, Brussels pushes a surveillance infrastructure, no one audits it upfront, beginner-level flaw. The EUDI Wallet will soon manage IDs, prescriptions, fiscal signatures for 450 million Europeans. A trivial flaw today isn’t just an incident, it’s a warning.

Digital sovereignty means the right to not prove one’s age at every click. And if we must, then via ZKP, not via a finger-in-the-dyke XML.

To Read on MacSouverain

Read: Chat Control 2, the mass surveillance that doesn’t say its name

Read: NIS2 vs CSAR, two opposing security logics

The FBI got their hands on deleted Signal messages. Cheers, iPhone notifications.

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

The FBI rebuilt deleted Signal messages via iPhone push notifications. Apple keeps these metadata and hands them over on demand. End-to-end encryption in Signal doesn’t matter because the leak happens elsewhere.

What you need to do

1. Signal: Settings → Notifications → “No Name or Content”, the app won’t inject anything into the push payload anymore.

2. iOS: Settings → Notifications → Previews → Never, you cut content for all apps at once.

3. Check other messaging apps (Messages, WhatsApp), apply the same settings.

An American judicial document confirms what privacy researchers have been saying since 2023: iPhone push notifications are a backdoor for accessing encrypted message content, even after it’s been deleted by the user. Signal is doing its job correctly. Apple is too, technically. It’s the combination of the two that betrays you.

What’s happening

In early April 2026, 9to5Mac reported on a federal American case. The FBI was investigating an individual, requested iCloud push notification data from Apple, and was able to reconstruct the content of received Signal messages that the target had deleted from their device.

The mechanism is simple. When a message arrives on Signal, the app triggers a push notification. This notification passes through APNs, Apple’s notification service. If the user has the default preview setting, the message content is sent in plaintext within the notification payload. Apple stores these metadata for an unspecified duration and, upon judicial order, hands them over to authorities.

The EFF published an in-depth analysis on April 16. The conclusion is clear: it’s not a bug in Signal, nor is it a bug in Apple; it’s the very architecture of the notification system that creates a blind spot. Signal encrypts messages end-to-end. Apple delivers the notification. In between, there’s a server relay that sees the content if you haven’t locked it at the source.

Senator Ron Wyden had already raised the alarm in December 2023, revealing that the US government regularly requests this data from Apple and Google. Three years later, we finally have proof that the technique has been used to access Signal conversations. And it works even after user-side deletion.

Why this matters to you

You can have the best end-to-end encryption in the world. If the notification that lands on your lock screen contains the phrase “Meet at 9 PM at the usual address,” that phrase exists somewhere on an Apple server before it reaches you. And that “somewhere” is accessible via a warrant.

This isn’t a scenario for dissident journalists or activists. It’s how your iPhone works by default today. Notifications have previews, sender names are displayed, and the first line of the message is readable from the lock screen. Convenient, very convenient. As convenient for you as it is for any institutional actor.

The kicker: it survives deletion. You delete the conversation on Signal, it disappears from your phone, and it never existed on Signal’s servers. Perfect.

But the notification announcing that message? It left a trace with Apple. That trace is more ephemeral than your emails, but it’s sufficient to reconstruct a conversation if the request comes within the right time window.

The 9to5Mac case involves the FBI and an individual pursued in the US. But the mechanism is universal. Any authority that can compel Apple to hand over iCloud data can, in principle, access these metadata. American jurisdiction, CLOUD Act, no need for a schema.

The irony is cruel. You chose Signal for maximum privacy. You enabled ephemeral messages. You were diligent. And you’re betrayed by an iOS setting that no one ever presented to you as a security issue.

What you need to do

Two settings, five minutes, and the leak is plugged.

1. Immediately: Signal > Settings > Notifications > “No Name or Content”. The app stops injecting the sender’s name and content into the notification. You know a Signal message has arrived, but you don’t know who it’s from or what it says until you open the app.

2. Within the week: iOS > Settings > Notifications > Previews > Never. You disable content previews for all apps at once, including Messages, Mail, WhatsApp, and the rest. Slightly degraded convenience, massively reduced exposure surface.

3. If you want to go further: spend thirty minutes going through the privacy settings on macOS and iOS. Most blind spots can be addressed once and last for years.

Read: Privacy macOS, the settings to change immediately

Need tech terms explained? Check the glossary.

Your Mac says "No Access" for an app, but it's still reading your files. Since 2019.

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

macOS keeps a permanent access to your files when an app uses the native Open/Save dialog. This access is separate from the Privacy & Security settings. You revoke the app’s access in the settings, it disappears from the list, but it still reads your files. Since 2019.

What you need to do

1. Check which apps have accessed your protected folders via Terminal: xattr -l ~/Desktop | grep com.apple.macl

2. To revoke ghost access: copy the file to another volume, delete the original, then copy it back, the attribute doesn’t follow.

3. Review your Mac’s privacy settings with our dedicated guide, keeping in mind that these settings don’t cover this mechanism.

When you open a file via the native selector of an app, macOS writes an attribute directly to the file. This attribute grants the app permanent access, independent of the Privacy & Security settings. You can revoke the app in the System Preferences, the interface will display “No Access”, and the app will continue to read. Since 2019. Without you knowing.

What’s Happening

Howard Oakley, a renowned macOS researcher and author of the blog Eclectic Light, published a demonstration in early April 2026 that sums up the situation in one sentence: the Privacy & Security interface of macOS lies about the real access of applications to your files.

The mechanism is called com.apple.macl. It’s an extended attribute, a small marker that macOS sticks directly onto the targeted file or folder. It’s created automatically when you use the Open/Save selector of an app, when you drag and drop from the Finder, or when you double-click on a file to open it with an app.

This attribute contains two identifiers: one for the app, one for the file. Once set, the app can access the file without passing through the permission checkpoint. It’s managed by the kernel (Sandbox.kext), not the classic TCC system that feeds the settings you see in System Preferences.

And that’s where it gets sticky. System Preferences > Privacy & Security only reads the TCC database. It doesn’t see the com.apple.macl attributes. Result: you revoke an app’s access in the settings, the interface displays “No Access”, and the app keeps its access via the xattr. Oakley demonstrated this with his test tool Insent, notarized by Apple, reproducible by anyone.

Why It Matters to You

This isn’t a bug. Apple introduced this mechanism at the WWDC 2019 (Session 701) under the name “User Intent”, opposed to the classic “User Consent” of the TCC system. The idea: when you explicitly choose a file in the selector, your action is a permanent authorization. No need to ask again.

The problem isn’t the principle. It’s that the interface supposed to show you who has access to what completely ignores this channel. You think you have a faithful dashboard of your authorizations. In reality, you’re looking at half the picture.

And this mechanism has been active since macOS Catalina (2019). Seven years. Confirmed functional on Tahoe (macOS 26). Never publicly documented by Apple in a complete manner. Jeff Johnson, a macOS developer, wrote in 2019: “there’s no documentation of this important privacy protections change.”

In practical terms, it means that every time you’ve used Open/Save, drag and drop, or double-click to access a file in Desktop, Documents, or Downloads, the app potentially received a persistent access that the macOS settings don’t reflect.

A Hacker News thread with 511 points confirms the surprise in the technical community. Several developers report that Apple classified the behavior as “expected behavior” when it was reported.

What You Should Do

Practically:

1. Check if your protected folders have macl attributes. Open Terminal and type: xattr -l ~/Desktop | grep com.apple.macl Repeat for ~/Documents and ~/Downloads. If you see results, apps have a persistent, invisible access in the settings.

2. To revoke a macl access on a sensitive file, the most accessible method: copy the file to another volume (USB key, external disk, other partition), delete the original, recopy the file. The copy doesn’t inherit the com.apple.macl xattr. It’s artisanal, but it works.

3. The technical alternative: boot in Recovery mode and run xattr -d com.apple.macl <file_path>. This requires temporarily disabling SIP, which isn’t trivial. Reserve for users who know what they’re doing.

4. tccutil reset All <bundle_id> followed by a reboot doesn’t suffice. This command resets the TCC database, not the macl xattrs. Oakley himself acknowledges this in his article. The reboot alone doesn’t change anything either, the attribute is embedded in the file system, it survives the reboot.

5. Review the privacy settings on your Mac. They remain useful for controlling the TCC channel (location, microphone, camera, contacts). But keep in mind that they don’t cover this second access channel.

Article #16 guides you through the settings you control. This Radar shows you the ones you don’t control, at least not through the intended interface.

Read: macOS Privacy: The Settings to Change Immediately

Technical terms? Check the glossary.

Sources

Eclectic Light, Why you can’t trust Privacy & Security, Howard Oakley, 10 April 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), April 2026
lapcatsoftware, Persistent File Access via com.apple.macl xattr, Jeff Johnson, 2019

108 Chrome extensions trapped, your Google and Telegram too

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

108 malicious extensions identified in the Chrome Web Store, with around 20,000 cumulative installations. They steal Google and Telegram tokens and install backdoors. Google was notified but the extensions were still online at the time of the report. If you’ve installed a Chrome extension recently, the damage may already be done.

What you need to watch out for

1. Audit your Chrome extensions and uninstall anything you don’t use regularly.

2. Log out of active Google sessions from myaccount.google.com, under Security.

3. Revoke Telegram sessions from Settings, Devices, on any client.

4. Seriously consider using Safari as your default browser on Mac.

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

Mid-April 2026, Socket researchers identify 108 malicious Chrome extensions in the Chrome Web Store, with around 20,000 cumulative installations. Google OAuth theft, universal backdoors, Telegram exfiltration. Extensions were still online at the time of public disclosure. If you’re using Chrome on Mac, and most Mac users are, you’re directly affected.

What’s happening

Socket researchers found 108 extensions published in the Chrome Web Store under five different publisher aliases (Yana Project, GameGen, SideGames, Rodeo Games, InterAlt) to throw off suspicion. Public disclosure on April 13, 2026. Extensions remained online despite Google’s notification.

The haul is varied and precise enough for mass work. 54 extensions retrieved Google OAuth tokens, those little keys that let a third-party service access your Google account without you re-entering your password.

Another 45 contained a universal backdoor that opens arbitrary URLs upon browser launch, perfect for pushing phishing or malicious content on demand.

And one dedicated extension exfiltrated Telegram Web session tokens every 15 seconds, draining localStorage to a command server. Enough to steal a messaging account without you even noticing.

Around 20,000 cumulative installations. That’s industrial-scale harvesting.

Why it matters to you

No macOS 0-day in this case. No Apple Silicon flaw, no Gatekeeper bypass. The vector is Chrome, and the extensions ecosystem running on it.

And Chrome, on Mac, is the default browser for a significant portion of users, including professionals who keep Safari for the rest. You sync your tabs with Google, let Chrome handle your autofill, install three extensions for your workflow, and forget about it.

Extensions have access to your tabs, cookies, and form data. When one becomes malicious, it can read what you’re reading. Here, the domino effect is brutal.

A stolen Google OAuth token means potential access to Gmail, Drive, Photos, Calendar, depending on the granted scopes. An exfiltrated Telegram token means access to your conversations, groups, channels, shared files. No need for your password: the token is the session, and the session opens the door.

The Chrome Web Store isn’t the App Store. Google reviews extensions, but not with the same level of rigor as Apple. Bad extensions slip through, and they often slip through often.

What you need to do

Practically:

1. Open Chrome, go to chrome://extensions, and disable everything you don’t use daily. Extensions that have been lying around for two years are exactly the attack surface you want to reduce.

2. Log in to myaccount.google.com, Security section, then Your Devices. Sign out any sessions you don’t recognize. While you’re at it, check the third-party apps accessing your Google account and revoke any you don’t recognize.

3. On Telegram, go to Settings then Devices (or Active Sessions depending on the client). Close all sessions except the one you’re using. If you see a session from a country or device you don’t recognize, it’s already too late for that session, but you can still cut off the flow.

4. Think about making Safari your default browser on Mac. Fewer extensions available means less attack surface. Safari doesn’t magically protect you, but its extension model is more restrictive, and Apple controls distribution via the Mac App Store for most of them.

And the bottom line, beyond this incident: a browser extension sees everything your browser sees. Install them like you’d install a system app, that is, with caution and restraint.

Read: Privacy macOS, the settings to change immediately

Technical terms? Check the glossary.

Sources

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

Google hands over your data to ICE, without telling you

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

Google Promised to Warn You Before Handing Your Data to Authorities. It Didn’t. On a simple administrative subpoena from ICE, without a warrant or a judge, it handed over a student journalist’s info. Notification came later. The file was already gone.

What You Need to Watch Out For

1. Any Google account linked to your real identity is vulnerable to government requests without a warrant or prior notice

2. An administrative subpoena is enough: no judge, no chance to challenge before disclosure

3. Switching to Proton Mail gets you out of this equation, complete guide here

Sources: EFF Deeplinks · The Intercept

AI Agents on Mac: ANSSI flags Claude Cowork and OpenClaw

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

ANSSI has just published an official alert about autonomous AI agents: OpenClaw and Claude Cowork are named, along with other open-source solutions. These tools run commands, read your files, send emails, and a malicious webpage could manipulate them without your knowledge. In other words: AI assistants on your Mac are also attack surfaces.

What you need to do

1. Disable access to sensitive apps (email, calendar, work files) for your AI agents in their respective settings.

2. Don’t use Claude Cowork, OpenClaw, or any autonomous agent on a machine containing client or financial data without proper supervision.

3. Check which applications each AI agent installed on your Mac has access to.

4. I’m preparing a complete guide to reduce risks: automatic filters, access segmentation, what you can disable without losing the tool’s usefulness: Coming soon in a tutorial

ANSSI issued an official warning on April 13, 2026, about autonomous AI agents on workstations. OpenClaw and Claude Cowork are specifically called out. These tools can run commands, read and write files, send emails - and a simple prompt injection can turn them against you.

I’m cooking up a comprehensive guide to reduce risks: automatic filters, access segmentation, what you can disable without losing functionality. Stay tuned.

Mac Souverain — Radars (English)

A fake Zoom update empties your iCloud Keychain

What’s really happening mid-call

The third ClickFix on macOS in six weeks

What you do now

Sources

Claude Cowork in local mode, the agent walks out of the sandbox

What Cowork actually mounts

The VM looks like a wall

What you do now

Sources

Hugging Face compromised, and your local model?

What happened

Your local model hasn’t budged

The twist, the attacker wasn’t a hacker

The lesson nobody meant to teach

What to do now

Sources

Apple-notarized malware slips past Gatekeeper

The fact

Why Gatekeeper saw nothing

What it changes for you

What you do now

Sources

Chat Control 1.0: Adopted by Those Who Voted Against

What Happened on July 9th

Debunk Express

Why It Concerns You

What You Can Do

Wazuh 5.0 lands, your home SIEM evolves

The Deal

Why It Matters to You

What It Changes for You

Sources

Chat Control: The EU's playing with your encryption's fate.

What Happened on June 29th

Why It Matters to You

What You Can Do

Your stance is leaking through the network, not through your iPhone.

The Fact

Why This Matters to You

What You Do Now

Sources

Siri AI blocked in EU, privacy signed Google

Apple Unveils Siri AI at WWDC

The Fact

Why It Matters to You

What It Changes for You

OpenAI Certificate Compromised, Update ChatGPT Mac Before June 12th

Domestic stalkerware, the jealous partner's malware

The Deal

Why This Matters to You

What You Do Now

Sources

The U.S. cyber regulator let its AWS keys slip six months ago.

Why it matters to you

What you do now

Sources

See also

Five years of defending memory M5 down in five days

Why it matters to you

What you do now

Sources

Also see

Google Ads and real cat Claude share your credentials

The Fact

Why This is a Game-Changer

Why This Matters to You

What You Do Now

Sources

See Also

Apple patches iOS and macOS CVE vulnerabilities: fixes, then tweaks Safari profiles

Why Lockdown Mode All the Time is Too Much

What are Safari Profiles?

What to Do Now

When to Switch to the “Sensitive” Profile

What It Doesn’t Replace

Sources

See Also

Proton Mail switches to post-quantum encryption (and it's free)