PHP Object Injection

A vulnerability where attacker-controlled serialized data is deserialized into live objects that can trigger unintended methods or file operations. It becomes especially dangerous when untrusted input reaches native unserialize() calls or similar object-rehydration logic in public web paths.

Expanded Definition

PHP object injection is an application-level vulnerability in which attacker-controlled serialized data is turned into live PHP objects, letting magic methods or destructors execute in ways the developer did not intend. In practice, the risk is not the serialization format itself but the presence of dangerous object graphs, gadget chains, and trust placed in input that should have been treated as opaque data. The issue is closely related to insecure deserialization, but in PHP environments it often appears through native NIST Cybersecurity Framework 2.0-style asset and application control gaps, especially where unserialize() is reachable from public request paths. Definitions vary across vendors on whether the term covers only direct object rehydration or also chained file, database, and autoload side effects, so the safer reading is broader: any deserialization flow that can instantiate attacker-influenced objects is in scope. In NHI terms, this matters because object injection can become a control-plane issue when PHP applications store or process identities, tokens, or workflow state as serialized blobs. The most common misapplication is assuming serialized input is safe because it is “internal,” which occurs when session data, cookies, or API payloads are accepted without integrity checks.

Examples and Use Cases

Implementing defences against PHP Object Injection often introduces compatibility and refactoring cost, requiring organisations to weigh legacy application stability against the security benefit of eliminating unsafe object hydration.

• Legacy PHP applications accept a serialized session cookie and later call unserialize(), allowing a crafted payload to trigger a destructor that deletes files or overwrites state.
• An API stores job metadata as serialized PHP objects, then rehydrates them in a worker process, creating a path for gadget-chain execution if the payload is tampered with.
• A plugin ecosystem loads third-party classes and autoloaders, which makes seemingly harmless object construction dangerous when combined with attacker-controlled properties.
• Security teams discover that a token cache or workflow record is serialized for convenience, but missing integrity protection turns that cache into an injection target.
• PHP shops using the guidance in the Ultimate Guide to NHIs often find the same pattern in service-account tooling: trusted internal data paths become attack paths once input provenance is lost.

For implementation context, secure deserialization guidance in the broader ecosystem aligns with the OWASP Top 10 concern around injection and the need to treat structured input as hostile until validated. A common safe pattern is replacing serialized objects with JSON plus explicit schema validation, while keeping object construction behind allowlists and integrity controls.

Why It Matters in NHI Security

PHP Object Injection matters in NHI security because compromise often extends beyond a single request and into service accounts, API keys, scheduled jobs, and other non-human control paths. When an attacker can influence object state, they may reach privileged automation that was never meant to execute with user input. That is especially dangerous in systems where secrets, tokens, or identity assertions are cached in serialized structures rather than stored with strict boundary controls. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 79% have experienced secrets leaks; those conditions make unsafe deserialization more than an application bug, because it can become a credential exposure pathway. The Ultimate Guide to NHIs also notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how quickly a code-level flaw can escalate into identity abuse. In governance terms, the control objective is simple: never let attacker-controlled data determine which object methods run, which files are touched, or which identities are activated. Organisations typically encounter the full blast radius only after a production compromise reveals that serialized state was the hidden bridge between web input and privileged automation.

Related resources from NHI Mgmt Group

• Object injection
• What is credential injection risk and how does it occur?
• What is the difference between prompt injection risk and identity abuse in agents?
• What is the difference between prompt injection and credential theft for agents