CAPEC-586
Object Injection
An adversary attempts to exploit an application by injecting additional, malicious content during its processing of serialized objects. Developers leverage serialization in order to convert data or state into a static, binary format for saving to disk or transferring over a network. These objects are then deserialized when needed to recover the data/state. By injecting a malformed object into a vulnerable application, an adversary can potentially compromise the application by manipulating the deserialization process. This can result in a number of unwanted outcomes, including remote code execution.
On this page
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-586: Object Injection: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/586.html and https://cve.bz/cve/capec/586?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
Prerequisites
The target application must unserialize data before validation.
Consequences
| Impact | Affects | Note |
|---|---|---|
| Resource Consumption | Availability | If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate and exhaust available resources. |
| Modify Data | Integrity | Attackers can modify objects or data that was assumed to be safe from modification. |
| Execute Unauthorized Commands | Authorization | Functions that assume information in the deserialized object is valid could be exploited. |
Mitigations
Implementation: Validate object before deserialization process
Design: Limit which types can be deserialized.
Implementation: Avoid having unnecessary types or gadgets available that can be leveraged for malicious ends. Use an allowlist of acceptable classes.
Implementation: Keep session state on the server, when possible.
Weaknesses it exploits
- CWE-502 Deserialization of Untrusted Data
Recent CVEs with these weaknesses
- 8.4CVE-2026-12389
A vulnerability that could lead to a high privileged authenticated user performing a remote code execution attack.
- 9.3CVE-2026-124079
rConfig Core 8.0.0 before 8.2.19 and rConfig Pro before 8.4.1 contain a deserialization of untrusted data vulnerability that allows unauthenticated network attackers to execute arbitrary code by pushing a crafted serialized job onto the Re…
- –CVE-2026-96285
Apache Airflow 3.3.1 shipped a fix for CVE-2026-67260 that checks the scheduler's decoded `next_kwargs` value is a dictionary, but performs that check only after deserializing the whole stored payload. Deserialization reconstructs nested o…
- –CVE-2026-86829
Apache Airflow's scheduler fully deserializes XCom values written by task code while evaluating task dependencies. A Dag author, who controls what a task writes to XCom, therefore controls data that is deserialized inside the scheduler pro…
- –CVE-2026-82436
Description `DefaultStateSerializer`, used to persist and restore stateful bolt checkpoints, configured Kryo with class registration disabled and an instantiation strategy that constructs objects without invoking their constructors, then …
- –CVE-2026-82337
Apache Airflow rebuilt deadline alert fields through generic deserialization, which imports and instantiates the class named in the serialized Dag, in the scheduler and API server. A Dag author could cause classes within Airflow's deserial…
- 8.8CVE-2026-111421
Apache Airflow's Task Execution API stored XCom values written by a task without the reserved-key check applied elsewhere, so a Dag author's task could write an XCom that, when a user later viewed it through the API with deserialization en…
- –CVE-2026-111395
Apache Airflow did not reject reserved serialization keys inside a Dag run's `conf`. A user allowed to trigger a Dag that uses a deadline alert with an asynchronous callback could pass a `conf` that, once the deadline was missed, either cr…
The newest records naming one of them. Each weakness's page lists them all.
MITRE's words, unchanged: CAPEC-586 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.