PLT entry overwrite is a binary exploitation technique that changes a Procedure Linkage Table entry so a program calls an attacker-chosen function instead of the intended one. It targets dynamically linked executables, where the PLT and Global Offset Table mediate external function calls.
What PLT entry overwrite is
PLT entry overwrite is a control-flow hijacking technique that changes how a dynamically linked program resolves an external function call. Instead of reaching the intended routine through the normal Procedure Linkage Table and Global Offset Table path, the program is redirected to an attacker-chosen function or gadget, which can alter execution without changing the source code.
This matters because the attack targets a program’s normal import resolution path rather than a visibly isolated feature. In practice, the overwrite can redirect repeated calls to a high-value function, turning a single memory corruption issue into reliable execution redirection.
How it works in dynamically linked binaries
In a dynamically linked executable, the PLT provides call stubs and the GOT holds resolved addresses for external symbols. On first use, the runtime linker resolves a symbol and stores the address so later calls are fast. A PLT entry overwrite changes that indirection point, so later calls land somewhere else.
The technique depends on being able to write to a memory location that influences indirect calls. That may come from a buffer overflow, arbitrary write primitive, format string issue, or another memory corruption condition that reaches writable process memory.
Security implications and exploitation conditions
PLT entry overwrite is dangerous because it can convert a memory safety bug into durable control-flow redirection. Once the attacker controls the call target, the program may execute unexpected code paths, leak secrets, bypass defensive checks, or call a routine that prepares further exploitation.
It is especially relevant in legacy or weakly hardened binaries where writable function pointers, partial RELRO, or similar conditions leave the indirection data structures more exposed. Modern hardening reduces the opportunity, but the risk remains wherever an attacker can still modify a call target after relocation.
Detection and defensive hardening
Detection usually starts with understanding the exploit primitive, not just the crash. Analysts should look for suspicious writes near relocation data, abrupt changes in indirect call behaviour, and runtime evidence that control flow moved to an unexpected function address. Post-exploitation review should also check whether the compromise exposed tokens, session material, or other secrets handled by the process.
Hardening focuses on preventing writable call targets from remaining useful to an attacker. That includes memory-safe code where possible, compiler and linker hardening, relocation protections, and limiting the process’s ability to turn a single overwrite into a stable redirection primitive. For broader control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Benchmarks both reinforce secure configuration, system integrity, and defensive baseline management.
Risk and Threat Considerations
PLT entry overwrite is attractive to attackers because it gives them a precise way to repoint a legitimate call site without needing to rewrite the whole program. If the overwrite is reliable, the attacker can steer execution into a function that reveals memory, spawns a shell, or strengthens their foothold.
Failure mechanism: a memory corruption bug exposes a writable indirection target, and the attacker replaces the expected function address with one they control.
Impact: the program makes attacker-chosen calls, which can lead to code execution, data exposure, persistence inside the process, or a stepping stone to broader compromise.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1574 — Hijack Execution Flow | PLT overwrite is a form of execution-flow hijacking through writable indirection data. |
| Recommendation — Map writable call-target abuse to T1574 and hunt for unexpected control-flow redirection. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Integrity controls apply when dynamic linking metadata can be altered to redirect execution. |
| CM-6 — Configuration Settings | Hardening linker and runtime settings reduces exposure to writable control data. | |
| Recommendation — Use SI-7 to detect and block unauthorized changes that alter executable control flow. Enforce secure configuration baselines that reduce writable attack surfaces. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Native-code exploitation and hardening fall under secure application design and testing. |
| Recommendation — Strengthen application security testing and hardening for memory-corruption exploit paths. | ||
Practitioner Guidance
What to watch for: treat PLT overwrite as a symptom of a deeper write primitive, not as a standalone bug class. The key judgement is whether the application still leaves any writable control-flow metadata that an attacker can influence after startup.
Governance implication: secure build and link settings should be part of release acceptance criteria for native code, especially for software that processes untrusted input. Teams should validate that memory corruption findings are evaluated for exploitation paths, not just crash presence.
Practitioner takeaway: if a binary can be redirected through its relocation path, the real question is whether the surrounding memory corruption bug can be removed or whether the process can be hardened enough that the overwrite no longer yields useful control.
Related resources from NHI Mgmt Group
- What breaks when stolen credentials are the main entry point for breaches?
- What do organisations get wrong about TOTP setup and OTP entry?
- What breaks when password entry is not blocked in non-password fields?
- What should security teams do when vulnerability exploitation becomes the main breach entry point?
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 November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org