YAML Deserialisation Attack is the exploitation of unsafe YAML parsing to create unexpected objects or execute attacker-controlled behaviour. It can lead to remote code execution, data tampering or denial of service when applications load untrusted YAML without strict parsing controls. Defenders should avoid unsafe loaders, validate input and restrict object construction.
What YAML deserialisation attacks are
YAML deserialisation attacks exploit unsafe parsing of YAML data so an application constructs unexpected objects or triggers attacker-controlled behaviour. The weakness is not YAML itself, but trusting untrusted input with a parser that can interpret tags, types or object construction too freely.
These attacks matter because YAML is widely used for configuration, automation, and application data exchange. When a parser accepts more than plain data, an attacker may turn a harmless-looking document into a payload that changes application state, tampers with data, or drives code paths the developer never intended. This is why insecure deserialisation is treated as a broad class of input-handling failure, and Insecure Deserialisation Guide is a useful companion reference for the wider pattern.
Why unsafe YAML parsing becomes dangerous
YAML parsers can support features that are convenient for developers, but dangerous when applied to untrusted content. If a loader resolves application-specific types, instantiates objects, or permits constructor hooks, a malicious document can become more than data. In the worst case, the parser becomes part of the attack surface rather than a neutral input validator.
The danger is amplified in applications that treat YAML as trusted configuration, because configuration paths often have elevated privileges and reach sensitive internal functions. If an attacker can influence a YAML document, they may be able to alter logic, redirect execution, or reach code paths that normally require developer control. That is why the safest default is to treat YAML as data only, not as a format that should automatically map to rich runtime objects.
Common exploitation conditions and failure modes
The attack usually depends on one of a few failure modes: a permissive loader, object constructors that are reachable from untrusted input, or custom type resolution that expands the parser’s behaviour beyond plain data structures. When those conditions exist, a payload may trigger object creation, unexpected method calls, or resource-intensive parsing that produces denial of service.
- Unsafe loaders that allow arbitrary object construction or type resolution.
- Parsing paths that accept external YAML without a strict schema or allowlist.
- Application code that assumes parsed values are simple strings, maps, or lists.
- Parser behaviour that can be abused for memory, CPU, or logic corruption.
These failure modes are consistent with the broader insecure deserialisation class, where the core problem is allowing attacker-supplied structure to control runtime behaviour instead of remaining inert data.
Defensive posture for applications that accept YAML
Defence starts with using the most restrictive parser mode available and limiting YAML to the smallest set of data types the application actually needs. If rich objects are unnecessary, avoid object construction entirely and enforce schema validation before the parsed content is used. The safest design is to parse into simple primitives, then validate the resulting structure against expected fields and values.
Where the application must support more complex YAML, isolate and constrain that behaviour so it cannot reach arbitrary constructors or dangerous deserialisation paths. Review any custom tags, converters or loader extensions carefully, because they often create the exact behaviour attackers look for. For configuration-heavy systems, a separate trust boundary for administrative YAML is safer than reusing the same parser logic for externally supplied input.
For broader context on the underlying risk pattern, the Insecure Deserialisation Guide explains how object injection and gadget-style behaviour emerge across deserialisation formats, while the OWASP API Security Top 10 is a useful adjacent reference when YAML is used to feed application interfaces and service logic.
Risk and Threat Considerations
YAML deserialisation attacks are high impact because they can turn input processing into execution, not just corruption. The practical risk is that a parser, loader, or configuration path becomes a trust boundary an attacker can cross, especially when YAML is accepted from users, external integrations, CI/CD inputs, or other semi-trusted sources.
Failure mechanism: A permissive YAML loader resolves attacker-controlled tags, types, or constructors and creates objects or executes behaviours that the application never intended to expose.
Impact: The result can be remote code execution, data tampering, denial of service, or broader compromise of the application environment if the parsing path has access to sensitive functions or credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | YAML attack payloads exploit unsafe input handling and parsing boundaries. |
| V15 — Secure Coding and Architecture | Safe deserialisation depends on restricting object construction and parsing trust boundaries. | |
| Recommendation — Validate and constrain YAML input before it reaches application logic. Design YAML handling to parse only the data types the application truly needs. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Unsafe YAML parsing is an application-level weakness that belongs in secure development and review practices. |
| Recommendation — Review parsing code and loader choices for unsafe deserialisation behaviour. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | YAML payloads must be validated before they are accepted as trusted application input. |
| SA-11 — Developer Testing and Evaluation | Unsafe deserialisation should be found through testing of parser behaviour and negative cases. | |
| Recommendation — Validate YAML structure and reject unexpected fields, tags, and types. Test YAML parsers with malicious and malformed inputs before release. | ||
Practitioner Guidance
What to watch for: Treat any YAML processing that uses non-default loaders, custom constructors, or automatic object mapping as a review item. The most common mistake is assuming YAML is “just configuration” and therefore safe to parse permissively. In practice, the risk depends on what the loader can instantiate, not on the file extension or source system.
Governance implication: Teams should document which YAML sources are trusted, which parser mode is permitted, and whether object construction is allowed at all. If a workload only needs data interchange, keep the parser in a data-only mode and reject features that expand the attack surface without a clear business need.
Practitioner takeaway: The safest YAML design is restrictive by default, explicit about structure, and unwilling to let untrusted input decide what objects the program should create.