The Global Offset Table stores addresses used by dynamically linked binaries for external functions and global variables. It acts as the indirection layer between code and the runtime-resolved address, supporting both eager and lazy binding models.
What the Global Offset Table does
The Global Offset Table, or GOT, is the runtime indirection structure that lets a dynamically linked binary refer to external functions and global data without hard-coding final addresses. It matters because position-independent code and shared libraries need a stable way to reach symbols whose addresses are only known when the process loads or resolves them.
Why the GOT exists in dynamically linked programs
The GOT solves a basic relocation problem. Code in a shared object or executable cannot safely assume where a target function or variable will live in memory, so it reads an address from the table instead. That design keeps code relocatable and lets the dynamic loader update references as bindings are resolved.
This indirection is what makes shared libraries practical at scale: the same binary can run even when libraries are mapped at different addresses, and the loader can choose eager or lazy binding depending on how the program is built and started.
How GOT-based binding works
In eager binding, the loader resolves the needed symbol addresses before the program begins normal execution. In lazy binding, the first call to a function can trigger resolution, after which the GOT entry is updated so later calls go straight to the resolved address. The table therefore acts as both a lookup cache and a relocation target.
For global variables, the GOT gives code a pointer to the storage location rather than embedding an absolute address. That keeps code position-independent and avoids recompilation when the loader or platform changes the final memory layout.
Why the GOT matters for security and binary hardening
The GOT is part of the trust boundary between code and the runtime linker. Because it stores executable targets and data pointers that control control-flow and memory access, corruption of GOT entries can redirect execution or alter program behaviour. That is why link-time and runtime hardening measures often focus on making relocation tables harder to overwrite or abuse.
Practically, the GOT is also a useful lens for understanding how binary protections interact, especially in exploit development, reverse engineering, and post-compromise analysis. If a binary depends heavily on runtime relocation, defenders and researchers often examine how symbol resolution is staged, when entries are written, and whether the table remains writable longer than necessary.
Risk and Threat Considerations
Because the GOT stores indirect references that the program trusts at runtime, it can become an exploitation target when an attacker gains a memory-write primitive or can interfere with relocation handling. A corrupted entry may redirect a function call or reroute access to sensitive data, which turns a low-level memory bug into code execution or process hijack.
Failure mechanism: An attacker overwrites a GOT slot, abuses a relocation window, or leverages a write-what-where condition so that the program later loads an attacker-controlled address instead of the intended symbol.
Impact: The result can be arbitrary code execution, process instability, or silent alteration of security-sensitive behaviour, especially in binaries that rely on late binding or expose writable relocation data for too long.
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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | GOT corruption can redirect execution inside a running process. |
| Recommendation — Monitor for memory corruption paths that could alter indirect call targets. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Binary hardening and code-integrity controls help limit runtime tampering. |
| Recommendation — Apply integrity protections to reduce unauthorized modification of executable data structures. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Build and runtime configuration determine how relocation and binding are hardened. |
| Recommendation — Control linker and build settings that affect writable relocation state. | ||
Practitioner Guidance
What to watch for: Treat GOT behaviour as part of binary integrity, not just linker mechanics. Review whether the build uses hardening features that reduce relocation abuse, and examine memory-protection assumptions around writable segments during startup and symbol resolution.
Practitioner takeaway: For offensive research, the GOT is a common pivot point; for defenders, it is a reminder that dynamic linking is secure only when relocation state is tightly constrained and monitored.
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 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org