A write-what-where condition happens when an attacker can control both the data written and the destination address in memory or storage. That lets them corrupt state, overwrite pointers, or change security-critical values. Defenders should remove unsafe memory writes, validate destinations, and apply memory protections that make arbitrary writes harder to exploit.
What creates the unsafe write path?
A write-what-where condition is created when a program lets an attacker influence both the value being written and the target location. That usually starts with a memory corruption bug, an unsafe copy, pointer misuse, or a storage update path that lacks strict bounds and destination checks. The core issue is not the write itself, but the attacker’s control over where it lands.
At the code level, the vulnerability often appears when software trusts attacker-controlled offsets, object references, indices, or pointers. If a bug converts that control into an arbitrary write primitive, even a small mistake can become security-critical. The same pattern can emerge in native code, parsers, drivers, or any path that writes to structured state without validating the destination first.
Because the destination is attacker-chosen, the write can affect control data, counters, flags, vtables, function pointers, return-related state, or application logic stored in memory or a database. That is why a write-what-where condition is usually treated as a primitive, not just a bug class: it can be the step that turns corruption into execution or privilege change.
How attackers turn it into impact
Once an attacker can direct the write, the next question is what they can overwrite. A targeted write to a pointer, length field, permission value, or security check result can redirect execution flow, bypass validation, or alter authorization state. In storage-backed systems, the same idea applies to records or configuration entries that govern access or behaviour.
The most dangerous cases are those where the written value survives long enough to influence later processing. That is why corruption of in-memory state, metadata, or persisted control values often matters more than the initial crash. A one-time arbitrary write can be enough to poison a process, disable a check, or prepare a second-stage exploit.
Memory safety weaknesses are the common root cause, which is why the best defenses focus on removing unsafe write primitives and narrowing what any write can reach. The CWE Top 25 Guide is useful here because write-what-where conditions often map to root-cause weaknesses such as buffer overflows, out-of-bounds writes, use-after-free, and improper input validation.
What good defenses do first
The strongest prevention is to eliminate the condition that lets attacker input shape an arbitrary destination. That means using safer APIs, checking lengths and indices before writes, avoiding unsafe pointer arithmetic, and constraining update paths so only intended objects can be modified. If the write target can be fully predicted by the attacker, the bug is far more exploitable than a simple corruption error.
Memory protection helps, but it is a backstop rather than a root fix. Bounds enforcement, ASLR, non-executable memory, control-flow integrity, and compiler hardening can reduce exploitability, yet they do not make an arbitrary write harmless. If a write primitive remains, assume an attacker will try to repurpose it against the most valuable in-memory or persisted state.
When the issue is in a parser, driver, service, or update routine, review the complete write path, not only the obvious input field. The dangerous part is often a secondary dereference, length calculation, or object lookup that turns a normal write into attacker-directed corruption. A write becomes “what-where” only when the software loses control of both the content and the destination.
Risk and Threat Considerations
Write-what-where conditions are high-risk because they can convert a single memory safety defect into a reliable corruption primitive. Even when exploitation is not immediate, the condition creates a broad attack surface: overwrite one trusted value and the attacker may alter execution, access control, or process state.
Failure mechanism: An attacker shapes both the payload and the destination through unsafe writes, weak pointer handling, or unchecked storage updates, then uses the resulting arbitrary write to corrupt security-relevant state.
Impact: The overwrite can crash a service, disable validation, redirect control flow, or change sensitive values such as permissions, function pointers, or integrity-critical data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Covers secure coding and prevention of memory corruption defects. |
| Recommendation — Eliminate unsafe write paths and enforce secure coding checks that block arbitrary memory writes. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Applies because write-what-where is a software design and implementation flaw. |
| Recommendation — Review write operations for unsafe pointer use, bounds errors, and destination control weaknesses. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Relevant because destination and write inputs must be validated before they affect state. |
| Recommendation — Validate write targets and inputs before any state-changing operation executes. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Relevant when arbitrary writes are used to trigger code execution through exploitation. |
| Recommendation — Map exploit chains that convert arbitrary writes into execution or control-flow compromise. | ||
Practitioner Guidance
What to verify: Confirm whether the write path is bounded by validated indices, object references, and destination checks, not only by source sanitisation. A safe input value does not matter if the destination is still attacker-influenced.
Common mistake: Treating a crash-only bug as low priority. If the same flaw can reach a controllable write, prioritise it as an exploitability issue, not just a reliability defect.
Practitioner takeaway: The key question is whether the program can be induced to write trusted data to an attacker-chosen location, because that is the point where ordinary corruption becomes a security primitive.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org