Apple M5 Kernel Cracked in Five Days With Claude Mythos: The SMB Mac Hardening Playbook

On May 14, 2026, three researchers from a firm called Calif walked into Apple Park and hand-delivered a 55-page report describing the first public kernel exploit on Apple M5 silicon. Bruce Dang, Dion Blazakis, and Josh Maine chained two macOS bugs into a working local privilege escalation that takes an unprivileged user to root on a fully patched macOS 26.4.1 machine — with Apple's brand-new Memory Integrity Enforcement (MIE) hardware mitigation fully enabled. Dang found the first bug on April 25. By May 1, the chain was running. Six days from discovery to root shell, on the platform Apple spent five years and roughly a billion dollars hardening.

What changes the math is not the bugs. It is the assistant that helped find them. Calif used Anthropic's Claude Mythos Preview, the unreleased frontier model the UK AI Security Institute described last month as a "significant capability leap" over anything else they have tested. Mythos did not invent the attack primitives. Calif says the hardest part — actually bypassing MIE — was still human work. What Mythos did was recognize bug classes the team had generalized from prior research, write and iterate exploit code on demand, and compress what would normally be months of manual reversing into one week.

The bugs do not have CVEs yet. There is no patch yet. Apple has the report, the report is detailed, and a fix is coming. In the meantime every Mac in your environment running macOS 26.4.1 on M5 hardware is sitting in a window where a future leak of those bugs, or a parallel rediscovery by someone less polite than Calif, turns into a local-privilege-escalation primitive against your fleet. This article is the SMB playbook for that window.

Why this is an SMB story, not just an Apple story

The instinct on a story like this is to file it under "Apple problem, Apple fix, wait for the patch." That instinct is wrong for three reasons.

First, the SMBs we work with are mac-heavy in exactly the places it matters. Founders, executives, designers, marketing leaders, and senior engineers tend to run Macs. Those are also the accounts with the most email, the most SaaS sessions, the most cloud credentials, and the most check-signing authority. A local privilege escalation on a CFO's MacBook is not a workstation incident. It is an everything-the-CFO-can-touch incident.

Second, the framing of "you need physical access" does not apply here. Calif's chain starts from an unprivileged local account using only standard system calls. Translated for a CEO: anyone who lands code on a Mac through phishing, a malicious browser session, a compromised npm package pulled by a developer, or a bad Homebrew install can walk that foothold up to root. The kernel exploit is the second stage. The first stage is the same as every other Mac compromise of the last decade.

Third, this is not a one-off. Mythos found 271 zero-day vulnerabilities in Mozilla Firefox in a single research run. OpenAI announced a commercial counterpart called Daybreak two weeks ago. The bar for "interesting bug, working exploit" just dropped, and it is going to drop again. Plan for kernel-class LPEs to land faster, more often, against every operating system you run.

What Calif actually did

The technical summary that is publicly available is short, and worth understanding before we get to the playbook. The exploit is a data-only kernel local privilege escalation. The chain manipulates kernel data structures — not code — which is the whole point of why MIE was supposed to stop this class. MIE is Apple's hardware-backed memory tagging mitigation; the tag checker is supposed to catch corruption attempts at allocation boundaries. Calif evaded that check by abusing timing and allocation patterns, fooling the tag checker at the critical moment, then walking kernel credential structures to grant root.

The exploit needs no kernel extensions, no physical access, no external devices, and no special entitlements. It uses standard system calls. It runs on bare-metal M5 hardware on the current shipping macOS release. The Calif team's stated reason for hand-delivering the report rather than filing through normal channels was to make sure it landed at the top of the queue at Apple Security Engineering instead of in a triage backlog. That tells you how seriously the discloser is taking it.

What is missing from public reporting is also instructive. No syscall names, no kernel structure names, no proof-of-concept code. The 55-page report is embargoed pending Apple's fix. That embargo is the only thing standing between your environment and a working public exploit, and embargoes have leaked before.

The SMB Mac hardening playbook for this week

Five steps. The first three are mechanical and can be done by whoever owns IT at your company in an afternoon. The last two need an hour of leadership time to define policy.

1. Inventory every Mac that touches corporate identity

Before you can defend the fleet, you need to know what is in it. Pull an inventory from your MDM (Jamf, Kandji, Mosyl, Microsoft Intune, JumpCloud) of every Mac currently checking in. For shops without MDM, query the directory provider — Google Workspace, Microsoft Entra, Okta — for sessions from Macintosh user agents in the last 30 days. Note model, OS version, and the user.

From a terminal on each Mac, the local triage commands are:

# Identify silicon family (M1/M2/M3/M4/M5) and OS build
sysctl -n machdep.cpu.brand_string
sw_vers
# Check that automatic updates and rapid-security-response are on
sudo softwareupdate --schedule
defaults read /Library/Preferences/com.apple.SoftwareUpdate \
    AutomaticallyInstallMacOSUpdates
# Confirm MIE is reported as active on M5 hardware
sysctl -a 2>/dev/null | grep -iE "mie|memory.integrity" || true

Cluster the result by silicon. M5 machines on 26.4.1 are the exact configuration Calif targeted. M4 and earlier are not affected by this specific chain but inherit the same patching discipline gaps. Anything more than two minor versions behind shipping is its own problem and needs to be remediated first.

2. Turn automatic updates on, and prove it

Apple ships rapid security responses out-of-band. For this class of bug, that mechanism is the thing that closes the window in hours rather than weeks. Confirm three settings are on for every Mac, ideally enforced through MDM rather than left to user discretion:

• Install macOS updates automatically. System Settings > General > Software Update > Automatic Updates > Install macOS updates.
• Install Security Responses and system files. Same menu, the toggle directly below. This is the one that delivers RSR patches.
• Download new updates when available. Same menu. Without this, the automatic install toggle has nothing to install.

The MDM payload for Jamf is com.apple.SoftwareUpdate with AutomaticDownload, AutomaticallyInstallMacOSUpdates, and CriticalUpdateInstall all set to true. Kandji and Intune have equivalent profiles. Push the profile, then verify with the defaults read command above on a representative sample. If anyone has these disabled for "stability," the policy conversation is overdue.

3. Add or validate EDR on Macs specifically

Most SMBs we audit cover their Windows endpoints with EDR and let the Macs run on built-in protection alone. That gap closes today. The kernel LPE chain itself runs deep enough that EDR will not see the privilege escalation directly — but the first stage, the unprivileged foothold that gets the attacker to a shell, is exactly what EDR is supposed to catch.

Whatever you run on Windows (CrowdStrike, SentinelOne, Defender for Business, Huntress, ThreatDown) needs to be on every Mac with the same enrollment posture: tamper protection on, full disk access granted, system extension allowed via MDM, and the cloud console alerting to a human who reads it. For shops without an EDR contract, the realistic SMB path is Huntress Managed EDR on the Mac fleet plus the built-in macOS XProtect and Gatekeeper, never just the latter.

4. Write a kernel-CVE patch SLA, then commit to it

When the Calif report drops and Apple ships the fix, the only thing that matters is how fast it lands on every Mac in your environment. Write that number down before the patch is out. Realistic SMB targets:

• 24 to 72 hours for any Mac that holds production credentials, admin SaaS access, or AWS/GCP/Azure console sessions.
• Seven days for general end-user Macs.
• Fourteen days for kiosk, lab, and back-office Macs.

The SLA is not a wish. It is a tracked metric. Pull a weekly report from MDM that lists every Mac more than seven days behind shipping; circulate it to whoever owns the IT budget. The companies that survive accelerated-disclosure cycles are the ones that turned patching into a number on a dashboard, not a quarterly project.

5. Re-segment privilege on the people most likely to be targeted

The CFO's MacBook and the lead developer's MacBook are the two most expensive endpoints in any SMB. Both are typically also the two most over-privileged. Use the next 30 days to fix that.

Separate "admin work" from "everyday work" with two accounts on the same Mac. Daily use runs under a standard account with no sudo entitlement. Administrative work, including software installs and configuration changes, runs under a separate admin account that you log into only when needed. Tie privileged SaaS access — production AWS, the Stripe dashboard, GitHub org admin, the Microsoft 365 global admin role — to a Yubikey or platform passkey, not to a password and a TOTP. The kernel LPE makes any single-account compromise much worse. Splitting the account splits the blast radius.

What to watch for over the next 30 days

Three things, in order of likelihood. First, Apple will ship a fix, probably as a rapid security response and probably without much detail in the release notes. Second, Calif will publish the 55-page technical report once the fix is widely deployed; that document will accelerate copycat discovery against other operating systems, because the data-only-against-tagged-memory technique generalizes. Third, the next AI-augmented disclosure will arrive faster than this one did, and it will probably target a system you also run.

The pattern to internalize is not "Apple is broken." Apple is not broken. The pattern is that the asymmetry between attacker discovery and defender patching just shrank by a factor of about ten, and the defenders who survive are the ones whose patch pipeline already runs in days rather than weeks. Mac fleets are part of that pipeline now, whether the security team treats them that way or not.

If your environment cannot answer the question "how long does it take a kernel patch to reach the last Mac" in a single number, that is the gap to close this week. Inventory first, automatic updates second, EDR third, SLA fourth, account separation fifth. None of these steps require the CVE to be published. All of them get easier if you start before the technical report drops.