Apple M1 Vulnerability Research Was Lagging. MIT’s Fractal OS Changes That

132

For years, security professionals accepted that Apple M1 vulnerability research was behind where it should be. Intel and AMD chips had received years of adversarial scrutiny. Apple Silicon, launched in 2020, had not. MIT researchers may have just changed that. Their Fractal OS, presented at the IEEE Symposium on Security and Privacy in San Francisco in June 2026, found three previously undocumented security behaviours in the M1 in a single study. Among them was the first confirmed evidence of Phantom speculation on Apple Silicon.

Mapping the Apple M1 Vulnerability: What Fractal Found

Joseph Ravichandran, a PhD student at MIT CSAIL, built Fractal alongside Professor Mengjia Yan. The goal was to study chips without the noise that standard operating systems introduce. Thread migrations move workloads between cores mid-test. Preemptive scheduling interrupts experiments. Memory mappings shift between privilege levels. All of this hides the behaviour researchers are trying to observe.

Fractal removes that noise. Multi-privilege concurrency lets a single task run threads at user and kernel privilege simultaneously, under identical conditions. A cooperative scheduler eliminates preemptive interruptions. A dedicated memory subsystem keeps virtual-to-physical mappings stable. Ravichandran spent six months in 2024 writing its 31,000 lines of code in assembly, C and C++. He called it “the electron microscope of operating systems.”

Three New Findings in the Apple M1

First, Apple’s CSV2 protection has a gap. CSV2 is designed to block user code from steering speculative execution in kernel mode via the indirect branch predictor. The M1 still fetches branch targets into the instruction cache before the privilege check completes, because the fetch begins before the check runs. User code can observe those fetches through cache timing. That creates a cross-privilege side channel that CSV2 does not prevent.

Second, an earlier published finding about the M1’s conditional branch predictor was wrong. Prior research had suggested the performance cores isolated the predictor between privilege levels. Fractal showed this was a measurement artefact. macOS was moving threads between cores during testing, giving the appearance of isolation where none existed. Both the performance and efficiency cores lack predictor isolation across privilege levels and address-space identifiers.

Third, and most significantly, Fractal documented Phantom speculation in the M1 for the first time. This is an Apple M1 vulnerability where ordinary instructions, including no-operations, are briefly misread by the processor as branch instructions. The CPU then speculatively executes across privilege or address-space boundaries in a direction the attacker can influence. This behaviour had been confirmed in AMD and Intel processors. Nobody had found it in Apple Silicon before this study.

The Research Gap Problem

All three behaviours almost certainly existed in the M1 from its November 2020 launch. The chip didn’t change. The tools to see it clearly didn’t exist yet, though. That’s worth understanding separately from the severity of the individual findings.

Apple’s transition to its own silicon was presented as a security step forward in many quarters. CSV2 was framed as a meaningful barrier against Spectre-style attacks. Security comparisons between Macs and Intel-based machines often treated the M1’s architecture as an advantage. Some of that was warranted. But some of it confused “nobody has found a problem yet” with “there isn’t one.”

This pattern recurs across security. Monitoring tools can report a clean system while a threat runs underneath, because they were not built to detect that class of problem. So the same applies to hardware research: absence of findings is not evidence of safety. It may simply be evidence of missing tools.

Intel and AMD both faced extensive research before Spectre and Meltdown became public in 2018. Years of accumulated scrutiny gave researchers a foundation to build from. Apple Silicon launched in 2020 without that history. Fractal is one of the first serious attempts to close the methodological gap with purpose-built tooling.

What Changes Going Forward

Fractal is open-source under the MIT licence and is available on GitHub and Zenodo. It supports Intel, AMD, Raspberry Pi, and Apple Silicon hardware. Any researcher can now apply the same controlled, low-noise methodology Ravichandran used on the M1. That’s the meaningful development here, not just the three specific findings this single study produced.

The Apple M1 vulnerability picture will look different in two to three years. More researchers with purpose-built tooling will run more iterations. Findings will accumulate into a clearer picture of Apple Silicon’s actual security posture, much as they did for Intel and AMD after Spectre.

Mengyuan Li of the University of Southern California, reviewing the work independently, described Fractal as turning “an often ad hoc microarchitectural reverse-engineering workflow into reusable research infrastructure.” That is the point. Individual findings age. Better methodology doesn’t.

What Organisations Should Do

The immediate practical risk from these specific Apple M1 vulnerability findings is limited. Fractal confirmed that Phantom speculation fetches happen on the M1, but the misspeculated instructions are never executed. That limits what an attacker can achieve compared to a full Spectre exploit. MIT disclosed all three findings to Apple’s product security team before publishing. Apple engineers reviewed Fractal itself. There is no active exploitation to respond to.

For most organisations, the near-term action is routine: keep macOS and firmware updated. Apple delivers microarchitectural mitigations through standard operating system updates. Patching covers the main available control.

Some environments deserve a closer look. Regulated sectors, financial services and legal work in particular, carry higher exposure from hardware-level side-channel threats. Shared machines, where multiple users or services run on the same physical hardware, are more vulnerable than single-user workstations. Developer build servers and shared Mac Pros are worth reviewing against this context.

Watch for any Apple security advisories that reference these findings. The CSV2 gap is the most relevant of the three, because Apple built that protection specifically to address known attack patterns. Any update targeting it should be prioritised.

The broader point is about assumptions. Every Apple M1 vulnerability finding so far has existed in the chip since launch. We are only now getting accurate data because better tools became available. That should give some pause about how well we understand the M3 and M4, because the same research lag applies to them too.