CWE-367 (TOCTOU) and its parent CWE-362 both list atomicity and locking as their mitigations — not optimistic concurrency control or event sourcing

concurrent-systemsrace-conditionstoctoucweconcurrency-control-history

CWE-367, "Time-of-check Time-of-use (TOCTOU) Race Condition," defines the weakness as a check on a resource's state that can be invalidated before the resource is actually used — "the resource's state can change between the check and the use in a way that invalidates the results of the check." A periodic sweep that deletes a resource based on a staleness check, while a separate write to that resource is still in flight, is an instance of this shape; the vault has already anchored it to a concrete, in-the-wild case via claim-cve-2025-38352-timer-sweep-toctou (a Linux kernel POSIX-CPU-timer sweep racing a concurrent deletion, also classified CWE-367).

CWE-367's own "Potential Mitigations" section lists six remedies: avoid checking before use at all; limit interleaving across processes; shrink the check-to-use window; recheck after use; use an environmental locking mechanism; and "ensure that locking occurs before the check." None of the six is optimistic concurrency control or event sourcing. The parent class, CWE-362 ("Concurrent Execution using Shared Resource with Improper Synchronization"), mitigates the same way — "use atomic operations on shared variables," synchronization primitives, mutexes — with no mention of either technique either. The formal taxonomy that names this exact failure shape reaches for atomicity and locking, not for the detect-after-the-fact discipline of optimistic concurrency control.