Summary
A flaw in Perl YAML versions before 1.30 allows crafted YAML documents to instantiate arbitrary loaded classes and trigger their DESTROY methods when objects leave scope. If an attacker can supply or modify a document processed by a vulnerable application, this may enable destructive actions such as deleting directories named by the document.
A flaw in Perl YAML versions before 1.30 allows crafted YAML documents to instantiate arbitrary loaded classes and trigger their DESTROY methods when objects leave scope. If an attacker can supply or modify a document processed by a vulnerable application, this may enable destructive actions such as deleting directories named by the document.
Affected context
The vulnerability occurs in applications that use affected Perl YAML parsing behavior on documents that are not fully trusted. Risk depends on which Perl classes are loaded in the process and what actions their cleanup methods perform; classes such as File::Temp::Dir may permit deletion of a directory tree specified by parsed data.
The vulnerability occurs in applications that use affected Perl YAML parsing behavior on documents that are not fully trusted. Risk depends on which Perl classes are loaded in the process and what actions their cleanup methods perform; classes such as File::Temp::Dir may permit deletion of a directory tree specified by parsed data.
Exploit preconditions
- Attack surface: An application or service that parses attacker-influenced YAML
- Required access: Ability to submit, replace, or otherwise control a YAML document
- Trigger point: YAML loading and subsequent object cleanup when the parsed object leaves scope
- Why exploitation is possible: A YAML tag can bless supplied data into a named loaded Perl class, causing class-specific
DESTROYbehavior to run
- Attack surface: An application or service that parses attacker-influenced YAML
- Required access: Ability to submit, replace, or otherwise control a YAML document
- Trigger point: YAML loading and subsequent object cleanup when the parsed object leaves scope
- Why exploitation is possible: A YAML tag can bless supplied data into a named loaded Perl class, causing class-specific
DESTROYbehavior to run
Why this happens
The underlying issue is unsafe deserialization of YAML into Perl objects. The parser permits document-controlled class blessing, allowing data to select a loaded class and populate its fields without a sufficiently restrictive type policy. When the resulting object is destroyed, its class-defined cleanup behavior may perform sensitive operations, which maps primarily to CWE-502: Deserialization of Untrusted Data and secondarily to CWE-470: Use of Potentially Dangerous Function.
The underlying issue is unsafe deserialization of YAML into Perl objects. The parser permits document-controlled class blessing, allowing data to select a loaded class and populate its fields without a sufficiently restrictive type policy. When the resulting object is destroyed, its class-defined cleanup behavior may perform sensitive operations, which maps primarily to CWE-502: Deserialization of Untrusted Data and secondarily to CWE-470: Use of Potentially Dangerous Function.
Potential impact
- Arbitrary loaded-class cleanup behavior may be triggered
- Files or directory trees named by the document could be deleted
- Application data may be modified or removed
- The affected process could experience denial of service
- Additional impact may occur if a loaded class performs privileged or externally visible actions
- Arbitrary loaded-class cleanup behavior may be triggered
- Files or directory trees named by the document could be deleted
- Application data may be modified or removed
- The affected process could experience denial of service
- Additional impact may occur if a loaded class performs privileged or externally visible actions
General mitigation guidance
Mitigation generally focuses on preventing untrusted YAML from controlling object construction or class selection.
Common defensive patterns include:
- Use a safe, data-only YAML loader that rejects object and class tags
- Deserialize into explicitly allowlisted scalar, sequence, and mapping types
- Apply strict schema validation after parsing and before use
- Treat uploaded or externally sourced YAML as untrusted regardless of its file location
- Run parsing components with least-privilege filesystem and process permissions
- Isolate parsers from sensitive directories and reduce the permissions of cleanup-capable objects
- Prefer configuration formats and APIs that do not invoke application code during deserialization
Mitigation generally focuses on preventing untrusted YAML from controlling object construction or class selection.
Common defensive patterns include:
- Use a safe, data-only YAML loader that rejects object and class tags
- Deserialize into explicitly allowlisted scalar, sequence, and mapping types
- Apply strict schema validation after parsing and before use
- Treat uploaded or externally sourced YAML as untrusted regardless of its file location
- Run parsing components with least-privilege filesystem and process permissions
- Isolate parsers from sensitive directories and reduce the permissions of cleanup-capable objects
- Prefer configuration formats and APIs that do not invoke application code during deserialization
How teams detect issues like this
Detection can include:
- Static analysis for YAML loaders that permit object construction or class blessing
- Code review checks for parsing attacker-controlled YAML with generic loaders
- Searches for YAML tags, dynamic class resolution, and deserialization callbacks
- Tests using unexpected type tags to verify that object construction is rejected
- Runtime monitoring for unusual file and directory deletion activity by parser processes
- Policy enforcement requiring safe, schema-bound parsing libraries in application code
Automated security review tools may help identify unsafe parser configurations, but findings should be validated against the application's trust boundaries and loaded class set.
Detection can include:
- Static analysis for YAML loaders that permit object construction or class blessing
- Code review checks for parsing attacker-controlled YAML with generic loaders
- Searches for YAML tags, dynamic class resolution, and deserialization callbacks
- Tests using unexpected type tags to verify that object construction is rejected
- Runtime monitoring for unusual file and directory deletion activity by parser processes
- Policy enforcement requiring safe, schema-bound parsing libraries in application code
Automated security review tools may help identify unsafe parser configurations, but findings should be validated against the application's trust boundaries and loaded class set.
