Object hijack is an attack where an adversary takes control of an object instance or replaces it with a malicious one. In software with shared state or deserialisation, this can redirect logic, corrupt data, or bypass checks. Defenders should validate object provenance, limit mutability, and avoid exposing privileged references.
How Object Hijack Works
Object hijack happens when an attacker seizes an existing object instance or swaps in a malicious one so that later code trusts the wrong thing. In practice, the object may carry state, permissions, or references that the rest of the system assumes are still legitimate.
This is especially dangerous in systems that rely on shared mutable state, object graphs, or deserialisation, because the attack can occur before the application reaches its intended checks. Once control has shifted, the attacker may be able to steer execution, alter decisions, or poison subsequent processing.
Where the Weakness Comes From
Object hijack is usually a design and implementation failure rather than a single bug class. The core problem is that the application treats an object as trustworthy after it has crossed a boundary, even though its provenance, ownership, or contents may no longer be reliable.
Common contributing conditions include excessive mutability, unsafe reuse of references, weak object validation, and object deserialisation from untrusted input. The CWE Top 25 Guide is a useful map for understanding how validation, reference handling, and trust-boundary mistakes cluster into broader software weakness patterns.
Security Impact and Abuse Paths
Once an object is hijacked, the downstream impact depends on what that object controls. It may redirect logic flows, corrupt data structures, bypass authorization or integrity checks, or expose privileged references that were never meant to be attacker-controlled.
That is why object hijack is often linked to insecure deserialisation, object injection, and confused-deputy style failures. In a system with rich in-memory state, even a brief compromise of object integrity can have outsized effects because downstream code may continue to trust the altered object long after the original attack point.
For defenders, the relevant question is not only whether the object is valid at creation time, but whether it remains trustworthy throughout its lifetime. That perspective is reinforced by the MITRE CWE taxonomy, which helps practitioners distinguish root-cause weakness patterns from their later exploitation effects.
Defensive Controls and Validation Focus
Preventing object hijack requires both design discipline and runtime checks. Provenance validation, immutability where practical, strict type and schema checks, and careful handling of privileged references all reduce the chance that attacker-controlled data can impersonate a trusted object.
Teams should also treat serialisation boundaries and cross-component object transfer as high-risk transitions. If an object can be replaced, reassigned, or mutated in transit, the application should assume that later consumers may be seeing an impersonated or corrupted instance unless integrity is re-established explicitly.
Risk and Threat Considerations
Object hijack is risky because it turns an internal object boundary into an attack surface. If the object carries authority, routing logic, or security-sensitive state, the attacker may inherit trust that was meant only for the original instance.
Failure mechanism: The attacker exploits mutable shared state, unsafe deserialisation, or reference confusion to replace a trusted object with one that preserves expected shape but changes behaviour or meaning.
Impact: The application may make incorrect authorization or integrity decisions, process malicious data as legitimate, or expose privileged operations through a hijacked reference.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 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 | Object hijack is a software weakness pattern that secure coding controls aim to prevent. |
| Recommendation — Apply secure coding and review controls to eliminate unsafe object handling and deserialisation paths. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The term concerns insecure object handling in application design and implementation. |
| Recommendation — Design object handling so trust boundaries, mutability, and deserialisation are explicitly controlled. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Testing and verification are needed to find object integrity and trust-boundary failures in software. |
| Recommendation — Test application logic for unsafe object replacement, mutation, and trust-boundary bypasses. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Object hijack often emerges from weak object handling and unsafe exposure paths in service interfaces. |
| Recommendation — Harden service interfaces that expose mutable or replaceable objects to untrusted callers. | ||
Practitioner Guidance
Why practitioners should care: Object hijack is most dangerous when business logic assumes object identity is stable after creation. Review code paths where objects cross trust boundaries, are cached, or are reconstructed from external input.
What to watch for: Look for mutable objects that carry security decisions, deserialisation of complex object graphs, and code that relies on reference equality or inherited state without revalidation.
Practitioner takeaway: If a security decision depends on an object, make that object hard to tamper with, easy to validate, and impossible to trust by default after untrusted transitions.