Write-What-Where Primitive

How a Write-What-Where Primitive Works

A write-what-where primitive gives an attacker two powerful controls at once: the ability to choose the value written and the memory location that receives it. That combination is more dangerous than an arbitrary write with constraints, because it can directly target control-flow data, security checks, or in-memory security state.

In practice, the primitive usually appears after memory corruption has already broken the program’s normal safety guarantees. The exploit value lies in turning a crash-prone bug into a precise memory operation that can alter execution paths instead of merely destabilising the process.

Why It Is a High-Impact Exploit Primitive

This primitive is feared because it can convert a narrow bug into broad control of a process. Overwriting a function pointer, return-adjacent control data, object vtables, or a privilege-related flag may redirect execution, disable checks, or open a path to code execution.

Its impact depends on what memory is reachable and what the attacker can influence, but even a partial primitive can be enough to bypass security logic, corrupt trusted state, or weaken later exploit mitigation. The exact outcome often depends on memory layout, available targets, and whether the program still has useful writable control data in reach.

Where It Comes From in Real Exploits

Write-what-where primitives commonly emerge from use-after-free conditions, buffer overflows, type confusion, format-string mistakes, or bad pointer arithmetic. The defect itself is the root cause, but the primitive is the exploitable capability that results when the attacker can steer both operands of the write.

Not every memory corruption bug becomes a write-what-where primitive. Some only allow limited corruption, such as a single byte or a constrained value. The more precise and unconstrained the write, the more likely the bug can be turned into reliable exploitation.

Defensive Meaning for Programmers and Security Teams

For defenders, the term is a reminder that memory safety bugs should be assessed by the power they hand to an attacker, not just by whether they crash a process. A primitive that can write to chosen addresses often deserves urgent triage because it can defeat assumptions made by higher-level code and security controls.

Good review therefore focuses on reachability, object lifetime, pointer integrity, and whether the corrupted write can touch security-critical data structures. Hardened memory allocators, compiler mitigations, and safer language boundaries reduce the chance that a bug becomes this level of exploit capability, but they do not replace root-cause remediation.

Risk and Threat Considerations

A write-what-where primitive is dangerous because it can turn memory corruption into targeted tampering of process state. Once an attacker can choose both the destination and the written value, the same bug may be used for denial of service, security bypass, privilege manipulation, or reliable code execution.

Failure mechanism: The attacker leverages corrupted pointers, object fields, or similar memory manipulation to direct a write to security-relevant data, then uses that overwrite to change control flow or disable a protection.

Impact: The program may be hijacked, destabilised, or made to reveal or execute functionality it should never expose, with consequences that can extend to full system compromise if the process is highly trusted.

Practitioner Guidance

What to watch for: Treat any bug that gives unconstrained write reach as a high-priority finding, especially when the target process handles secrets, privileged operations, or network-exposed input. The key question is not only whether the bug exists, but whether it can be shaped into a precise write against executable or security-critical data.

Practitioner note: In triage, separate “memory corruption” from “exploit primitive”. A crash is a symptom; a write-what-where capability is often the point where the issue becomes immediately exploitable.

Related resources from NHI Mgmt Group

• What should teams do when a write primitive exists in a production app?
• What are the signs that a write primitive is close to RCE?
• Write primitive
• Remote Write Primitive