What causes modification of assumed-immutable data (MAID)?

What actually changes when assumed-immutable data is modified?

MAID is not usually a memory-safety bug in the narrow sense, it is a trust-boundary failure. The code that reads the data is making decisions on the assumption that the value cannot change, while some other code path still has a live reference or another way to alter it. The failure is the mismatch between “trusted as fixed” and “actually mutable.”

That is why MAID often shows up in security-sensitive logic, not just ordinary business data. A policy object, authorization result, cache entry, or configuration snapshot can be treated as authoritative after it has already been changed elsewhere, which means the bug is really about stale trust in shared state.

Why shared references and unsafe type handling create the condition

The most common root cause is sharing the same underlying object across code that assumes different ownership rules. If one component expects a snapshot and another component can still write to that same object, the “immutable” assumption is false from the start. Defensive copying prevents that aliasing by giving the reader its own protected view.

Unsafe casting and type confusion can create the same result even when the data structure was meant to be stable. A cast may bypass the normal API that would enforce copying or validation, so code can reach fields or buffers it should never have been able to mutate. In practice, MAID often appears when low-level shortcuts defeat higher-level invariants.

Why rechecking before trust decisions matters

MAID becomes dangerous when the modified value influences a decision after validation but before use, or when the same object is reused across multiple checks. A value that looked safe during validation may no longer be safe at the moment it is consumed, especially in concurrent or multi-step workflows.

That is why security-critical inputs should be copied, validated as close as possible to use, and rechecked if the object can be touched by other code between those steps. Treating a mutable object as if it were an immutable security token is what turns a programming flaw into a policy bypass.

Risk and Threat Considerations

When assumed-immutable data is modified, the main risk is that downstream code keeps trusting a value that no longer reflects reality. That can corrupt access decisions, cache correctness, integrity checks, or policy enforcement, especially when multiple components share the same object instance.

Failure mechanism: An attacker or faulty component exploits shared state, aliasing, or a weak cast to alter data after validation, so later code consumes a changed value as though it were still fixed.

Impact: The result can be authorization bypass, integrity loss, poisoned caches, incorrect policy evaluation, or other security decisions made on stale or attacker-influenced data.

Practitioner Guidance

What to verify: Confirm whether the data object can be reached by more than one component, thread, or layer after validation. If the answer is yes, assume the object is not truly immutable unless the code makes a protected copy or enforces a stronger ownership model.

Common mistake: Relying on a naming convention, wrapper type, or caller promise instead of enforcing immutability at the boundary. The bug usually survives reviews because the code “looks read-only” while still sharing the same mutable backing object.

Practitioner takeaway: MAID is best treated as a trust-boundary problem, not just a data-structure problem, so the safe pattern is to copy before trust, keep ownership explicit, and avoid reusing mutable objects for security decisions.

Related resources from NHI Mgmt Group

• Guide: CWE Top 25 Guide
• Modification of Assumed-Immutable Data (MAID)
• What causes assumed-immutable data to be stored in writable memory?
• What causes authentication bypass by assumed-immutable data?
• How do developers prevent assumed-immutable data from being stored in writable memory?