Three Years in Plain Sight: What LDB-01 Reveals About Security Assumptions

In September 2022, Apple introduced Lockdown Mode to iOS 16. It was positioned as an extreme security measure for a narrow population: journalists, activists, diplomats, and others who face sophisticated, targeted cyber-attacks. When enabled, Lockdown Mode disables JIT JavaScript compilation, blocks most attachment types, restricts web fonts, limits complex web technologies including WebAssembly, disables link previews, and restricts network protocols. It is, by design, the most restrictive security state available on a consumer device.

In May 2025, I submitted a vulnerability report to Apple documenting that WebAssembly modules and Service Worker scripts cached by Safari during standard operation persisted and remained executable after Lockdown Mode activation. Apple assigned the report ID OE11022074757, tracked the issue as webkit-294380, and deployed a fix in Safari 26 and iOS 26 (build 23A635 and later), released September 2025. My contribution is credited in Apple's public security advisory at support.apple.com/125113.

This post is not about criticizing Apple. Apple responded to the disclosure through their established Security Research Program, confirmed the vulnerability, and remediated it in a major release. That is responsible vendor behavior. This post is about what the three-year window between Lockdown Mode's introduction and the vulnerability's discovery tells us about assumptions built into the security architectures we depend on.

The Forward-Only Assumption

Every cache management system I have examined operates on an implicit assumption: security validation is a point-in-time event that occurs when content enters the cache. Once content passes validation and is stored, its security status is considered settled. The cache treats stored content as inherently authorized, because it was authorized at the moment it was cached.

This assumption is so deeply embedded that it does not appear as an explicit design decision in any specification I have reviewed. It is not documented as a tradeoff. It is not flagged as a known limitation. It is simply the way caches work — and have always worked — because cache management evolved to solve performance problems, not security problems. The metadata that caches track reflects this origin: content size (for storage management), expiration timestamps (for freshness), access frequency (for eviction decisions), and cache priority (for replacement policies). Nowhere in this metadata is there a record of what security policy was active when the content was stored.

When Lockdown Mode activates, the operating system transitions to a hardened security state. Active processes are notified. New content requests are evaluated against the restrictive policy. But the cache — containing potentially thousands of previously stored executable items — is not re-evaluated. It exists outside the security transition. It is a remnant of the prior security state, persisting into and through the new one.

What the Attack Looks Like

The attack model enabled by this gap is patient and precise. A sophisticated adversary — the exact kind of adversary Lockdown Mode is designed to defend against — does not need to attack a target while Lockdown Mode is active. The adversary compromises a website or deploys malicious content on a legitimate site that the target is likely to visit during normal (non-Lockdown) browsing. The target visits the site. Safari caches WebAssembly modules and registers Service Workers as part of normal browsing behavior. The content appears entirely benign under standard security policies, because it is — standard policies permit WebAssembly execution and Service Worker registration.

Days, weeks, or months later, the target enables Lockdown Mode — perhaps after receiving a threat notification, perhaps before traveling to a high-risk region, perhaps as a precautionary measure following a security incident. The target believes they are now operating under maximum security protections.

But the cached content from the pre-Lockdown browsing session remains. When the target revisits the associated website, or when a Service Worker activates in response to a background event, the cached executable content runs with the capabilities it possessed under the prior, permissive policy. WebAssembly modules that Lockdown Mode is specifically designed to block execute normally. The security transition that the user initiated — the transition that was supposed to eliminate these exact attack surfaces — did not reach the cache.

The vulnerability window for pre-positioning content is essentially unlimited. An adversary who plans months ahead can establish cached footholds long before a target even considers enabling hardened security.

The Broader Pattern

The instinct is to treat this as an Apple-specific implementation bug. That framing is incorrect and, more importantly, dangerous. The vulnerability exists because of a structural gap in how the entire computing industry conceptualizes the relationship between caching and security policy.

I have examined, at a conceptual level, the cache architectures of multiple browsers, operating systems, and application frameworks. The pattern is consistent: cache management operates independently of security policy management. They are separate subsystems with separate concerns, separate metadata, and separate lifecycle management. When security policies change, no signal propagates to the cache layer. When cached content is loaded for execution, no check occurs to determine whether the security context has changed since caching.

This is not negligence. It is architectural inertia. Caches were designed in an era of static security configurations, where the assumption that "validated once means validated forever" was approximately true. That era is over. Security policies now change in response to user actions (enabling hardened modes), administrative commands (enterprise policy pushes), threat intelligence (dynamic risk elevation), regulatory requirements (governance framework activations), and AI governance contexts (model permission transitions). Each of these transitions creates a potential temporal security discontinuity if cached content is not reassessed.

The Scale Question

Apple's Lockdown Mode affects a subset of iOS users who choose to enable it. But the temporal security discontinuity vulnerability class is not limited to opt-in hardened modes. It applies to any security policy transition that affects cached executable content.

Enterprise MDM policy updates affect millions of managed devices. Browser private mode transitions occur billions of times per day across all browser platforms. AI governance framework activations will affect every organization deploying AI models under the EU AI Act's 2026 enforcement timeline. Cloud container security policy updates affect every microservice deployment in every cloud environment.

The question is not whether other instantiations of this vulnerability class exist. The question is how many exist, across how many platforms, affecting how many users, and how long they will persist before being individually discovered and individually patched — one vendor-specific fix at a time, each addressing a single product on a single platform, while the general problem remains unaddressed.

Three years of undetected exposure on Apple's platform is data. It is reasonable to infer that analogous exposure windows exist elsewhere.