Temporal Security Discontinuity: The Vulnerability Class Hiding in Every Cache

Every modern computing device relies on cached executable content. WebAssembly modules compiled once and stored for reuse. Service Workers running in the background across browser sessions. JavaScript bundles preserved to shave seconds off load times. Machine learning inference engines cached to avoid reloading multi-gigabyte model weights. This caching is not a flaw — it is a foundational optimization that makes modern software usable.

Every modern computing device also supports multiple security states. A smartphone has standard mode and Lockdown Mode. A browser has standard browsing, private mode, and enterprise-managed configurations. An AI platform has permissive development contexts and restricted production governance modes. An enterprise laptop shifts between baseline policies and threat-elevated restrictions pushed by MDM administrators responding to active incidents.

The vulnerability class I am describing here exists at the intersection of these two realities.

The Gap Nobody Checked

When a system transitions from a permissive security state to a restrictive one, something happens to the active security policy. Restrictions are added. Permissions are removed. Features are disabled. The system's security posture hardens.

But something does not happen to the cache.

Executable content that was stored under the permissive policy — content that was perfectly legitimate when it was cached — remains sitting in storage. It does not know the security policy changed. It was not designed to know. No mechanism exists to inform it. No process runs to re-evaluate it. No system checks whether it should still be allowed to execute.

When that content is subsequently loaded and run, it executes with the capabilities it had when it was cached, not the capabilities permitted by the current security policy. The old policy authorized it. The new policy would prohibit it. But the new policy never gets a chance to weigh in, because nobody asks.

I call this vulnerability class temporal security discontinuity — a mismatch between the security context at the time of content caching and the security context at the time of content execution. The word "temporal" is critical. This is not a privilege escalation across user boundaries. It is not a sandbox escape across process boundaries. It is a security bypass across time — content authorized at time T₁ executing at time T₂ under a policy that would have rejected it.

Why It Went Undetected

The most revealing fact about temporal security discontinuity is how long it survived in plain sight. I discovered a specific instantiation of this vulnerability class — designated LDB-01 — affecting Apple's iOS and iPadOS platforms. The vulnerability involved WebAssembly modules and Service Worker scripts cached by Safari during standard operation continuing to execute after the user enabled Lockdown Mode, Apple's highest-security state designed for individuals facing targeted cyber-attacks.

Apple introduced Lockdown Mode in iOS 16 in September 2022. I discovered LDB-01 in early 2025 and responsibly disclosed it to Apple through their Security Research Program in May 2025 (Report ID OE11022074757). Apple acknowledged the vulnerability under internal tracking reference webkit-294380 and deployed a fix in Safari 26, iOS 26, and iPadOS 26 (build 23A635 and later). Apple credited my contribution in their public security advisory at support.apple.com/125113.

That is a three-year window. From September 2022 to September 2025, one of the world's most sophisticated technology companies shipped a hardened security mode that did not retroactively validate cached executable content upon activation. This was not a failure of engineering talent — Apple employs some of the best security engineers in the world. It was a failure of conceptual framing. The assumption embedded in every cache management system I have examined is that security validation happens at caching time and does not need to happen again. Cache management and security policy management operate as independent subsystems. Neither knows what the other is doing.

This assumption — what I call "forward-only validation" — is the root cause. Content is validated when it enters the cache. If it passes, it is marked safe. That mark persists indefinitely, regardless of how the security landscape changes after caching. The mark is a statement about the past ("this content was compliant when we checked") being treated as a statement about the present ("this content is compliant now"). In a world of static security policies, the distinction does not matter. In a world where security policies evolve — where users enable hardened modes, where enterprises push policy updates, where AI governance frameworks activate new restrictions — the distinction is everything.

The Scope of the Problem

LDB-01 is one instantiation. The vulnerability class is general.

Consider an enterprise that pushes an MDM policy update blocking a specific content delivery network flagged by threat intelligence as a supply chain compromise risk. JavaScript bundles cached from that CDN before the policy update remain in every managed device's browser cache, executable and unvalidated against the new restriction.

Consider an AI governance platform that activates GDPR-enhanced privacy restrictions prohibiting biometric data processing by cached inference models. Neural network weights and prompt templates cached under the prior, permissive policy remain loaded and ready to execute biometric operations that the current policy explicitly forbids.

Consider a browser transitioning from standard mode to private mode and back. Content cached during standard browsing may persist into and beyond the private session, depending on implementation. The security boundaries that private mode is supposed to enforce are undermined by cache state that predates them.

In every case, the pattern is identical: cached executable content authorized under Policy A continues executing after transition to Policy B, which would prohibit it. The cache does not participate in security transitions. It is a temporal island — frozen in the security context of the moment it was written, indifferent to everything that happens afterward.

Why This Matters Now

Three converging forces make temporal security discontinuity an urgent problem rather than a theoretical curiosity.

First, the surface area of cached executable content is expanding. WebAssembly adoption is accelerating across performance-critical web applications. Service Workers power the offline capabilities of Progressive Web Apps used by hundreds of millions of people. Machine learning inference is moving to the edge, with model weights and inference engines cached on-device for latency and privacy reasons. Every new category of cached executable content is a new category of content that can persist across security transitions unvalidated.

Second, security policies are becoming more dynamic. Static, rarely-changing security configurations are giving way to adaptive, context-sensitive policies that shift based on threat intelligence, user behavior, regulatory requirements, and operational context. The EU AI Act's 2026 enforcement timeline, the NIST AI Risk Management Framework's governance requirements, and enterprise zero-trust architectures all assume that security policies will evolve frequently. Each policy evolution is a potential temporal security discontinuity event if cached content is not re-evaluated.

Third, the stakes are highest for the people who need protection most. Lockdown Mode exists for journalists, human rights activists, and government officials facing targeted cyber-attacks from nation-state adversaries. These are individuals who activate hardened security precisely because they are under threat. A vulnerability class that allows pre-positioned cached content to execute despite hardened protections is a vulnerability class that directly undermines protections designed for the most vulnerable users.

What the Industry Needs to Recognize

I am not going to describe a solution in this post. What I want to establish is that the problem exists, that it is general, and that it is not addressed by any existing security mechanism.

Content Security Policy does not retroactively validate cached content when policies change. MDM frameworks do not enumerate and re-evaluate cached executables across browser storage layers after a policy push. HTTP cache-control directives govern freshness based on content age, not security policy compatibility. Browser private modes create ephemeral sessions but do not invalidate content cached during prior standard sessions. Trusted Platform Module attestation operates at the platform level and does not reach into application-layer caches.

Every one of these mechanisms validates content going forward. None of them look backward. None of them ask: "Given that the security policy just changed, is the content we already cached still allowed to run?"

That is the question that temporal security discontinuity forces the industry to confront. The answer, today, for every major platform I have examined, is that nobody is asking it.

Apple's fix for LDB-01 addresses the specific instantiation in Safari on iOS and iPadOS. It is a vendor-specific patch for a single product on a single platform. The general problem — cached executables persisting unvalidated across security policy transitions in any computing environment — remains open.

Three years of undetected exposure on a platform used by over a billion people should be sufficient evidence that this is not a problem the industry will solve by accident.