TOCTOU Races: Timing Vulnerabilities

• TOCTOU races are timing vulnerabilities where a system checks a condition at one time and assumes it remains valid at use time, risking security breaches.
• They appear across diverse domains such as operating systems, remote attestation, in-memory malware, and agent-based applications, highlighting their broad impact.
• Mitigation strategies include enforcing atomic check-and-use operations, binding state to actions, and using hardware-assisted solutions to confirm state freshness.

Searching arXiv for the provided TOCTOU-related papers to ground the article in current literature. Time-of-Check-to-Time-of-Use (TOCTOU) races are timing vulnerabilities in which a system validates some resource or state at one moment and later uses that resource under the assumption that the validated property still holds, even though the state may have changed in the interim. In the supplied literature, this pattern appears across operating systems, remote attestation, in-memory malware detection, browser and desktop GUI agents, AI coding-agent harnesses, private blocklisting, and concurrent resource management. A common formulation is that a check occurs at time $t_{\text{check}}$ and a use occurs at time $t_{\text{use}}$; the vulnerability arises when the relevant state differs between those moments, so that the action is performed on stale assumptions (Juneja, 5 Aug 2025, Rashidi, 7 Jul 2026, Jiang et al., 28 Feb 2026, Zhang et al., 17 Apr 2026, Zhang et al., 17 Apr 2026). The surveyed work also makes clear that TOCTOU is not restricted to classic pathname and permission bugs: it recurs wherever validation is separated from action without an enforceable freshness or atomicity guarantee (Rashidi, 7 Jul 2026, Lilienthal et al., 23 Aug 2025).

1. Definition and formal structure

TOCTOU is described as a race condition in which a program or system checks a condition, assumes it remains true, and then acts later after the checked state may already have changed (Juneja, 5 Aug 2025, Jiang et al., 28 Feb 2026, Zhang et al., 17 Apr 2026, Zhang et al., 17 Apr 2026, Lilienthal et al., 23 Aug 2025). The supplied material repeatedly characterizes the defect as a mismatch between validation time and action time. One source states that the system “checks a condition, assumes it is still true, but the condition changes before the system takes action” (Lilienthal et al., 23 Aug 2025). Another states that TOCTOU vulnerabilities “describe inconsistencies that occur when a resource is validated as safe for use but, when actually used later, would have been discovered as unsafe if checked at that time” (Zhang et al., 17 Apr 2026).

Several papers render this pattern explicitly in timing notation. In the RX-INT threat model, a periodic memory scanner inspects a module at $t_{\text{check}}$, an attacker alters and executes code at $t_{\text{attack}}$, restores the original bytes at $t_{\text{cleanup}}$, and the next scan occurs at $t_{\text{next}}$; the attack succeeds if

$$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$

because the detector never observes the malicious state (Juneja, 5 Aug 2025). In agent security, the desired invariant is expressed as

$$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$

and a TOCTOU violation as

$$\text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c)$$

with $t_u > t_c$ (Rashidi, 7 Jul 2026). Browser-use agents are modeled similarly by defining page state at observation time $t_{\text{use}}$0, page state at action time $t_{\text{use}}$1, and a target-binding function $t_{\text{use}}$2; the vulnerability condition is

$t_{\text{use}}$3

so that an action selected against one page state resolves to a different target when executed later (Jiang et al., 28 Feb 2026).

A recurring abstraction in the literature is that TOCTOU is a broader “state-validation problem” rather than merely a low-level bug class (Rashidi, 7 Jul 2026). One survey summarizes the root cause as “authorization is checked once and trusted forever,” and applies that description to permissions, validated files, tool metadata, project trust decisions, and web state (Rashidi, 7 Jul 2026). This suggests that TOCTOU is best understood as a temporal invalidation of a previously accepted predicate.

2. Classical systems roots and concurrent resource races

The traditional systems understanding of TOCTOU centers on mutable references, especially file-system names, permissions, and path resolution (Jiang et al., 28 Feb 2026, Hristozov et al., 2022, Lilienthal et al., 23 Aug 2025, Zhang et al., 3 Mar 2026). The standard pattern is that a process checks a pathname or file property and later performs open(2), unlink(2), or another operation assuming the same object is still being referenced; symlink substitution, directory renaming, or other concurrent changes can redirect the operation to a different object (Jiang et al., 28 Feb 2026, Zhang et al., 3 Mar 2026). The browser-agent work explicitly frames this as “check-then-use” on a mutable reference and notes that the web platform lacks an atomic check-and-act primitive, making the browser analogue structurally similar to OS pathname races (Jiang et al., 28 Feb 2026).

Concurrent shared-memory systems exhibit an analogous form in “read–destruct races,” where one process reads and then uses a resource while another concurrently overwrites and destructs it (Blelloch et al., 2020). The paper “Concurrent Reference Counting and Resource Management in Wait-free Constant Time” (Blelloch et al., 2020) treats these races as a specific TOCTOU form and introduces an acquire–retire interface with acquire, release, retire, and eject primitives. Its stated guarantee is that if an acquire is linked to an eject, then all matching releases occur before eject, so that destruction after eject cannot overlap the protected use (Blelloch et al., 2020). The same work applies this to memory reclamation, reference-counted objects, and ownership-managed objects, precisely to prevent a thread from reading a pointer, file stream, or object and then having another thread free or destroy it before use completes (Blelloch et al., 2020).

The short-race literature further connects TOCTOU to predictive race analysis. “Efficient Dynamic Algorithms to Predict Short Races” (Zhang et al., 3 Mar 2026) distinguishes semantic TOCTOU races from lower-level data races but notes that TOCTOU patterns often manifest as predictive races over shared state. It defines short races by a span bound $t_{\text{use}}$4, where a race pair $t_{\text{use}}$5 is short if the subtrace from $t_{\text{use}}$6 to $t_{\text{use}}$7 contains at most $t_{\text{use}}$8 events (Zhang et al., 3 Mar 2026). A plausible implication is that TOCTOU bugs are often operationally short because checks and uses are usually close in program order, making short-race detectors a natural fit for prioritizing actionable TOCTOU findings.

3. Remote attestation and integrity-checking TOCTOU

Remote attestation research treats TOCTOU as a mismatch between when software state is measured and when that measurement is relied upon (Nunes et al., 2020, Hristozov et al., 2022, Frolikov et al., 10 Feb 2025). In “On the TOCTOU Problem in Remote Attestation” (Nunes et al., 2020), the core issue is that conventional remote attestation reveals only the state of the binary at attestation time. Malware can install itself, execute, and erase itself between attestations, or detect an incoming request and restore a clean image before the measurement begins (Nunes et al., 2020). That work formalizes a TOCTOU-security game in which a verifier accepts if $t_{\text{use}}$9 even though there exists $t_{\text{check}}$0 between a reference time $t_{\text{check}}$1 and attestation time $t_{\text{check}}$2 such that $t_{\text{check}}$3 (Nunes et al., 2020).

RATA addresses this by storing a protected Last Modification Time $t_{\text{check}}$4 within the attested range $t_{\text{check}}$5, updating it whenever executable memory changes, and including it in the attested token (Nunes et al., 2020). Two constructions are given: RATAa for devices with real-time clocks and RATAb for devices without them (Nunes et al., 2020). In RATAa, the verifier accepts only if $t_{\text{check}}$6 and the attestation MAC matches the expected memory image $t_{\text{check}}$7 (Nunes et al., 2020). In RATAb, challenge values themselves serve as modification markers, and the verifier tracks them across rounds (Nunes et al., 2020). The paper states that, compared with current remote attestation architectures that “offer no TOCTOU protection,” RATA incurs no extra runtime overhead and “substantially reduces computational costs of RA execution” (Nunes et al., 2020).

A complementary attack on DICE shows the opposite direction: a clean boot-time measurement can be reused after compromise (Hristozov et al., 2022). “A TOCTOU Attack on DICE Attestation” (Hristozov et al., 2022) describes a layered architecture in which boot logic measures firmware and derives an alias attestation key, but that key is later handed to application code. The attack installs malware during application runtime, copies the valid attestation key to flash, and after reboot overwrites the newly derived key in RAM with the previously stored clean key, so that later attestations continue to validate even though the application image now contains malware (Hristozov et al., 2022). This is explicitly a check-at-boot, use-at-runtime discrepancy.

At network scale, TRAIN splits TOCTOU into intra-device and inter-device windows (Frolikov et al., 10 Feb 2025). The intra-device window is the period between successive attestation instances for one device; the inter-device window is the variance between the earliest and latest attestation across devices in the network (Frolikov et al., 10 Feb 2025). TRAIN uses synchronized attestation, constant-time per-device reports, and hybrid roots of trust derived from RATA or CASU plus GAROTA’s NetTCB and TimerTCB (Frolikov et al., 10 Feb 2025). The paper gives the scheduling equations

$t_{\text{check}}$8

and

$t_{\text{check}}$9

for the RTC-based variant (Frolikov et al., 10 Feb 2025). It reports request verification time of approximately $t_{\text{attack}}$0 ms and report generation time of approximately $t_{\text{attack}}$1 ms at $t_{\text{attack}}$2 MHz, both constant in the size of program memory (Frolikov et al., 10 Feb 2025). This suggests that minimizing the time and skew of attestation itself is a direct TOCTOU mitigation strategy.

4. In-memory malware, fileless threats, and memory-forensics races

The RX-INT work frames TOCTOU as central to in-memory threat detection (Juneja, 5 Aug 2025). In that setting, a periodic scanner inspects process memory, while an attacker performs manual mapping, module stomping, or other fileless injection techniques entirely in address space and then restores the original bytes before the next scan (Juneja, 5 Aug 2025). The paper describes this explicitly: “An adversary can perform a module stomp, execute their payload, and restore the original bytes of the legitimate module in a window of opportunity that is shorter than the polling interval of a periodic scanner” (Juneja, 5 Aug 2025).

The threat model includes manual PE mapping, often followed by erasing PE headers so that the payload becomes executable MEM_PRIVATE memory with no standard PE metadata; module stomping, in which .text of an existing DLL is made writable and overwritten; remote thread creation by CreateRemoteThread or NtCreateThreadEx; thread hijacking; QueueUserAPC; and post-injection cloaking tactics such as fake start addresses and suppressed DLL_THREAD_ATTACH notifications (Juneja, 5 Aug 2025). The paper emphasizes that “private, executable memory is not inherently suspicious,” because JIT runtimes and browsers also generate executable MEM_PRIVATE regions (Juneja, 5 Aug 2025). This ambiguity makes selective or periodic scanning attractive, and therefore TOCTOU-prone.

RX-INT’s architecture combines a kernel-mode driver, a real-time thread-creation callback via PsSetCreateThreadNotifyRoutine, and a stateful VAD scanner that baselines committed memory regions and hashes executable MEM_IMAGE regions using XXH64 (Juneja, 5 Aug 2025). The key claim is that “a suspicious event from the thread monitor immediately triggers an out-of-band scan from the VAD scanner, mitigating the TOCTOU race condition” (Juneja, 5 Aug 2025). When a new thread starts in a MEM_IMAGE region, the callback treats this as a “stomp hint,” signals the scanner via KeSetEvent, and the scanner compares current hashes against its baseline (Juneja, 5 Aug 2025). For executable image region $t_{\text{attack}}$3, the baseline and current hashes are

$t_{\text{attack}}$4

and a mismatch indicates module stomping or inline modification (Juneja, 5 Aug 2025).

The evaluation contrasts RX-INT with PE-sieve. In a module-stomping test that “simulated an adversary stomping the Beep function in kernel32.dll, executing a payload, and immediately restoring the original bytes,” PE-sieve “was unable to detect the fast cleanup attack” and “lost the TOCTOU race,” whereas RX-INT’s OnThreadNotify callback triggered an immediate VAD scan that detected the content hash mismatch before restoration (Juneja, 5 Aug 2025). Additional reported figures include idle monitoring below $t_{\text{attack}}$5 kernel CPU, active detection in Chrome at approximately $t_{\text{attack}}$6 CPU in release build, non-paged pool footprint around $t_{\text{attack}}$7 KB, and paged pool around $t_{\text{attack}}$8 MB for complex processes (Juneja, 5 Aug 2025). The paper’s larger point is that event-driven detection tied to the time of execution can succeed where periodic user-mode snapshots fail.

5. TOCTOU in AI agents, browser agents, and GUI agents

Recent work extends TOCTOU from OS resources to agent pipelines, web interfaces, and desktop GUIs (Rashidi, 7 Jul 2026, Lilienthal et al., 23 Aug 2025, Jiang et al., 28 Feb 2026, Xu, 20 Apr 2026). The 2026 survey on execution security for AI coding agents classifies TOCTOU as Category 5 and defines it as a race where an agent validates a file, webpage structure, policy, project trust state, or tool metadata and later acts on a stale copy after that state changes (Rashidi, 7 Jul 2026). The survey explicitly equates TOCTOU with “checked once, trusted forever” and argues that TOCTOU and Model Context Protocol threats are structurally the same validate-then-act problem (Rashidi, 7 Jul 2026).

“Mind the Gap: Time-of-Check to Time-of-Use Vulnerabilities in LLM-Enabled Agents” (Lilienthal et al., 23 Aug 2025) studies this pattern in tool-using agents built with LangGraph and GPT‑4o over AgentDojo environments spanning Banking, Slack, Travel, and Workspace (Lilienthal et al., 23 Aug 2025). The benchmark, TOCTOU-Bench, contains $t_{\text{attack}}$9 realistic user tasks derived from $t_{\text{cleanup}}$0 original tasks after excluding injection tasks and tasks with fewer than two tool calls; $t_{\text{cleanup}}$1 tasks are labeled as containing a possible TOCTOU vulnerability (Lilienthal et al., 23 Aug 2025). The paper reports that combining prompt rewriting, state-integrity monitoring, and tool-fusing reduces vulnerabilities in executed trajectories from $t_{\text{cleanup}}$2 to $t_{\text{cleanup}}$3, achieves up to $t_{\text{cleanup}}$4 detection accuracy using automated detection methods, produces a $t_{\text{cleanup}}$5 decrease in vulnerable plan generation, and reduces the attack window by $t_{\text{cleanup}}$6 (Lilienthal et al., 23 Aug 2025). In the Slack and combined experiments, the attack window falls from roughly $t_{\text{cleanup}}$7 seconds to $t_{\text{cleanup}}$8 seconds after tool fusion (Lilienthal et al., 23 Aug 2025).

Browser-use agents instantiate TOCTOU at the interface level (Jiang et al., 28 Feb 2026). The agent loop is observation $t_{\text{cleanup}}$9 planning $t_{\text{next}}$0 action, with planning latency often taking seconds while the webpage remains live and mutable (Jiang et al., 28 Feb 2026). The benchmark spans synthesized and real-world sites and evaluates $t_{\text{next}}$1 popular open-source agents, including structured text agents, screenshot-based agents, and multimodal hybrids (Jiang et al., 28 Feb 2026). The paper states that all $t_{\text{next}}$2 agents exhibit TOCTOU vulnerabilities on at least one manipulation type, and most are vulnerable across UI changes, data changes, and expiring state (Jiang et al., 28 Feb 2026). Its mitigation uses MutationObserver and ResizeObserver to validate DOM and layout state immediately before action execution; on the OpenAI CUA Sample App, the unmitigated and prompt-only systems show a $t_{\text{next}}$3 trigger ratio across Types I–III, while pre-execution validation shows $t_{\text{next}}$4 trigger ratio in the tested cases (Jiang et al., 28 Feb 2026). The remaining vulnerable gap is approximately $t_{\text{next}}$5 s per action, compared to around $t_{\text{next}}$6 s planning latency, a reduction factor of about $t_{\text{next}}$7; stress tests report $t_{\text{next}}$8 and $t_{\text{next}}$9 successful triggers in contrived schedules (Jiang et al., 28 Feb 2026). Additional latency is reported as below $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$0 s per plan–validate–act loop (Jiang et al., 28 Feb 2026).

Desktop GUI agents face a closely related “observation-to-action gap” (Xu, 20 Apr 2026). The paper measures this gap across OSWorld tasks and reports mean $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$1, standard deviation $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$2, minimum $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$3, and maximum $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$4 (Xu, 20 Apr 2026). It formalizes the resulting failure as a Visual Atomicity Violation: an intended click at coordinate $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$5 targets element $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$6 at $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$7, but a distinct attacker-controlled element $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$8 occupies $$t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}}$$9 at $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$0 (Xu, 20 Apr 2026). Three primitives are evaluated: Notification Overlay Hijack, Window Focus Manipulation, and Web DOM Injection (Xu, 20 Apr 2026). Primitive B achieves $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$1 spatial and trigger success over $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$2 trials for Claude 4.6; Primitive C yields $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$3 spatial attack success and $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$4 behavioral success for Claude and Qwen, with $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$5 for GPT-4o (Xu, 20 Apr 2026). The proposed PUSV defense combines masked pixel SSIM, global screenshot diff, and X Window snapshot diff, reaches $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$6 Action Interception Rate across $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$7 adversarial trials for Primitives A and B with zero false positives and less than $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$8 s overhead, but has approximately $$\text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c)$$9 AIR against Primitive C because DOM-only changes can leave screenshots pixel-identical (Xu, 20 Apr 2026). This demonstrates that purely visual TOCTOU defenses have structural blind spots when semantic state changes have zero visual footprint.

The AI-agent survey also ties TOCTOU to real CVEs, including Claude Code startup-trust and project-load issues, framing them as trust-boundary races where execution occurs before a user’s trust decision takes effect (Rashidi, 7 Jul 2026). That placement broadens TOCTOU from interface dynamics to authorization sequencing in agent harnesses.

6. Mitigation patterns, design principles, and unresolved issues

Across the supplied literature, TOCTOU mitigations fall into a small number of recurring patterns. The first is to shrink or eliminate the gap between validation and action. In systems security this appears as atomic system calls, stable object handles, and lock-based synchronization (Jiang et al., 28 Feb 2026, Blelloch et al., 2020, Zhang et al., 3 Mar 2026). In agent systems it appears as prompt rewrites that require revalidation at use time, tool-fusing that collapses read–write pairs into one operation, and pre-execution validation immediately before click dispatch (Lilienthal et al., 23 Aug 2025, Jiang et al., 28 Feb 2026). In RX-INT it appears as binding memory checks to thread-creation events rather than periodic polling (Juneja, 5 Aug 2025). In TRAIN it appears as synchronized attestation so that network state is measured at nearly the same time across devices (Frolikov et al., 10 Feb 2025).

The second pattern is to maintain protected or persistent state across time. RX-INT baselines VAD regions and hashes executable image content (Juneja, 5 Aug 2025). RATA stores a protected last-modification marker inside the attested memory region (Nunes et al., 2020). Half-Moon Cookie stores an allowlist state $$\text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c)$$0 on the server and invalidates the allowlist whenever the blocklist changes (Zhang et al., 17 Apr 2026). The AI-agent survey recommends revocable, time-limited capability tokens to counter “checked once, trusted forever” (Rashidi, 7 Jul 2026). These mechanisms do not remove time, but encode freshness or modification history into later decisions.

The third pattern is to move checking to a more privileged or trustworthy layer. RX-INT runs in kernel mode to avoid user-mode API hooking and to traverse the kernel’s actual VAD tree (Juneja, 5 Aug 2025). RATA, TRAIN, and CASU depend on hardware-enforced memory and timer properties (Nunes et al., 2020, Frolikov et al., 10 Feb 2025). The desktop GUI defense argues for OS+DOM defense-in-depth because screenshot-only middleware cannot observe DOM-only rebinding (Xu, 20 Apr 2026). This suggests that TOCTOU defenses inherit the observability limits of the layer that implements them.

The fourth pattern is cryptographic or logical binding of evidence to the specific item or state being used. Half-Moon Cookie is the clearest example. It performs an expensive private explicit blocklist check and then a fast implicit check at time of use, designed specifically so recipients can “more efficiently confirm the previous result before using the item, thereby avoiding TOCTOU attacks” (Zhang et al., 17 Apr 2026). The token

$$\text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c)$$1

binds the content $$\text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c)$$2, its embedding, and the random mask $$\text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c)$$3 (Zhang et al., 17 Apr 2026). The system clears the allowlist whenever the blocklist is updated, so signed or cached prior approval cannot outlive policy changes (Zhang et al., 17 Apr 2026). The paper gives explicit implicit-check performance figures for a 100KB input: communication $$\text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c)$$4 MB and response time $$\text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c)$$5 s, compared with much higher figures for fuzzy PSI and exact PSI baselines (Zhang et al., 17 Apr 2026). The authors nonetheless state that the design “reduce[s] the time window in which a TOCTOU inconsistency can be exploited rather than eliminating it entirely” (Zhang et al., 17 Apr 2026).

Several limitations recur. Kernel-mode or hypervisor-compromising adversaries remain out of scope in RX-INT, which proposes hypervisor-based EPT enforcement as future work (Juneja, 5 Aug 2025). Browser and desktop agent defenses leave a residual nonzero gap and may suffer false positives or visibility gaps, especially for cross-origin or DOM-only changes (Jiang et al., 28 Feb 2026, Xu, 20 Apr 2026). AI-agent TOCTOU detection based only on tool-pair classification remains context-insensitive, with modest TPR and AUC (Lilienthal et al., 23 Aug 2025). RATA assumes secure hardware and excludes physical tampering and side channels (Nunes et al., 2020). TRAIN assumes a secure TCB and excludes physical attacks and strong network DoS (Frolikov et al., 10 Feb 2025). DICE demonstrates that clean boot-time measurements are insufficient if runtime code can later reuse attestation credentials (Hristozov et al., 2022). A plausible implication is that TOCTOU cannot be solved purely by faster checking; it requires explicit freshness semantics, binding across layers, and resistance to rollback or replay.

The literature therefore converges on a general view: TOCTOU races arise whenever a system validates mutable external state and later acts as though that validation were still current. Whether the state is a pathname, a firmware image, executable memory, a webpage, a GUI surface, a repository trust decision, or a private blocklist result, the central problem is temporal separation without enforced continuity (Juneja, 5 Aug 2025, Rashidi, 7 Jul 2026, Nunes et al., 2020, Zhang et al., 17 Apr 2026). The strongest defenses either make check and use effectively atomic, or they preserve enough trusted history and binding information that a stale validation cannot be mistaken for a fresh one.