Write-What-Where

How Write-What-Where Works

Write-what-where is dangerous because it gives an attacker two things at once, a value to write and a memory location to target. That combination turns many otherwise limited bugs into a powerful exploitation primitive, since the attacker can redirect program behaviour rather than merely corrupt nearby data.

The write target is often especially valuable when it points at control data such as function pointers, return-oriented structures, exception records, dispatch tables, or configuration values that influence later execution. If the attacker can influence both operands, the bug can become a stepping stone toward code execution, sandbox escape, or privilege escalation.

Why It Is a Powerful Exploitation Primitive

Exploit developers prize write-what-where conditions because they can be chained with other weaknesses to shape execution flow. Even when the initial overwrite is small, a single precise write may be enough to alter a security check, disable a mitigation, or redirect execution to attacker-controlled code or gadgets.

The exact outcome depends on what is reachable in memory, what protections are active, and whether the attacker can repeat the write. In modern systems, the same primitive may be used to corrupt heap metadata, overwrite a saved pointer, or tamper with policy state, so the security impact is determined by the surrounding memory layout as much as by the bug itself.

Common Root Causes and Failure Modes

Write-what-where flaws usually arise from memory safety errors such as buffer overflows, use-after-free conditions, type confusion, or uncontrolled pointer writes in native code. The core failure is not just corruption, but the loss of control over both the destination and the written content.

In practice, the bug may appear as a partial overwrite, an arbitrary kernel write, or a constrained write through an attacker-influenced pointer. Even constrained forms are often serious, because a small change to a flag, vtable entry, or length field can be enough to pivot into a broader compromise.

Defensive Implications for Detection and Hardening

Defence focuses on removing the primitive, making the target harder to influence, and reducing the payoff if corruption occurs. Secure coding, memory-safe languages where feasible, compiler hardening, control-flow protections, ASLR, DEP, and strong bounds validation all help reduce the chance that an attacker can turn a write bug into reliable exploitation.

For validation and review, security teams should look for places where untrusted input reaches pointer arithmetic, indirect writes, or object fields that later influence control flow. Vendor hardening guidance and control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Benchmarks are useful references for configuration and integrity-oriented safeguards, while MITRE ATT&CK Enterprise Matrix helps map the exploitation chain once an attacker has obtained arbitrary memory-write capability.

Risk and Threat Considerations

Write-what-where is high impact because it can convert a single memory corruption bug into durable control over a running process, especially when attackers can steer the destination toward security-critical structures. The same primitive can be used to defeat integrity checks, corrupt process state, or prepare later stages of exploitation.

Failure mechanism: An attacker abuses an unsafe pointer write or corrupted reference so the program writes attacker-chosen data to attacker-chosen memory, then uses that overwrite to redirect execution or weaken protection.

Impact: The result can include code execution, privilege escalation, process takeover, denial of service, or latent compromise that persists until the process or host is fully restored.

Practitioner Guidance

What to watch for: Treat write-what-where findings as exploitation-enabling defects, not ordinary crashes. If a code review, fuzzing run, or dynamic test suggests attacker influence over both write value and destination, prioritise immediate triage because the bug may be one small step away from a full compromise.

Governance implication: Track these defects as high-severity memory-safety issues and require explicit remediation ownership, because the practical risk depends on what the write can reach in the current build and deployment context.

Related resources from NHI Mgmt Group

• How should security teams govern AI tools that write into workspace settings?
• How do security teams decide whether HRIS write-back is safe in joiner automation?
• What breaks when a document parser can write files outside its temp directory?
• How should security teams write an access onboarding and termination policy?