CWE-1250 applies when a product has several distributed components or subsystems that each keep their own copy of shared data, such as state or cache, and nothing makes sure those copies stay consistent. It affects cloud and distributed systems and also hardware, where a processor's subunits keep local views of the same information.
How it happens
Distributed designs often need local copies. Users of a social service or an online game each use their own machine while talking to different hosts in a global system, and everyone must see the same world. In hardware, a Memory Management Unit may have shadow MMUs to spread work, and all of them are expected to agree on the accessible memory ranges.
The system is only as safe as the agreement between copies. If one component believes the state is something other than what it is, it makes decisions from stale facts.
MITRE's example is a processor whose main MMU has five shadow MMUs. Whenever the accessible range changes with boot status, the main MMU sends an update message to each shadow. If the interconnect does not prioritize those updates over general traffic, there is a race condition. An attacker who floods the target can get attack packets through before the new range takes effect.
What an attacker gains
The consequence in the record is an unexpected state: one or more components assume the state is different than it actually is. What that costs depends on what the stale copy controls. If it is an access range, the attacker gets access that should already have been revoked.
How to find it
The record lists no detection methods. Useful questions for a review:
- Which data exists in more than one place, and which copy is the source of truth?
- How does a change propagate, and how long can copies disagree?
- Can an attacker influence the timing, for example by loading the channel that carries updates?
- What does each component do when it receives a stale value?
How to fix it
The record has no listed mitigations. The related entry, CWE-1251, recommends shrinking the out-of-sync window and making the update process as dependable as possible. The example in this entry points the same way: give update messages priority over ordinary traffic so an attacker cannot win the race by flooding.
Quick check
Why is the interconnect relevant in the MMU example?
If update messages are not prioritized over general traffic, an attacker flooding the system can get packets in before the update arrives, creating a race condition.
What is the core risk?
A component acts on a state that is no longer true, because its local copy has not caught up.
