Summary
A vulnerability in older Perl YAML releases allows specially crafted YAML documents to replace package variables and alter deserialization behavior. If an attacker can supply YAML to multiple Load() calls in the same process, this may enable arbitrary Perl code execution.
A vulnerability in older Perl YAML releases allows specially crafted YAML documents to replace package variables and alter deserialization behavior. If an attacker can supply YAML to multiple Load() calls in the same process, this may enable arbitrary Perl code execution.
Affected context
The issue occurs in Perl applications that use affected YAML releases and process attacker-influenced YAML documents. Risk increases when multiple documents are loaded within the same process, because an earlier document may change package variables that control whether later documents are evaluated as code.
The issue occurs in Perl applications that use affected YAML releases and process attacker-influenced YAML documents. Risk increases when multiple documents are loaded within the same process, because an earlier document may change package variables that control whether later documents are evaluated as code.
Exploit preconditions
- Attack surface: Application or service paths that deserialize YAML input
- Required access: Ability to provide or influence YAML documents accepted by the application
- Trigger point: YAML processing through Load() calls
- Process condition: Multiple deserialization operations occur in a shared Perl process
- Why exploitation is possible: A permitted document can modify package variables controlling code loading, causing later code-bearing content to be evaluated
- Attack surface: Application or service paths that deserialize YAML input
- Required access: Ability to provide or influence YAML documents accepted by the application
- Trigger point: YAML processing through Load() calls
- Process condition: Multiple deserialization operations occur in a shared Perl process
- Why exploitation is possible: A permitted document can modify package variables controlling code loading, causing later code-bearing content to be evaluated
Why this happens
The vulnerability combines unsafe deserialization with insufficient restrictions on package-variable assignment. Perl/glob YAML documents can name arbitrary package symbols, including variables that control YAML code loading; subsequent perl/code documents may then be passed to string evaluation. This maps primarily to CWE-502: Deserialization of Untrusted Data, with CWE-914: Improper Control of Dynamically-Managed Code Resources also describing the unsafe modification of code-execution controls.
The vulnerability combines unsafe deserialization with insufficient restrictions on package-variable assignment. Perl/glob YAML documents can name arbitrary package symbols, including variables that control YAML code loading; subsequent perl/code documents may then be passed to string evaluation. This maps primarily to CWE-502: Deserialization of Untrusted Data, with CWE-914: Improper Control of Dynamically-Managed Code Resources also describing the unsafe modification of code-execution controls.
Potential impact
- An attacker may execute arbitrary Perl code in the application process
- Application credentials, secrets, or accessible data could be exposed
- The process could be modified or disrupted
- Attackers could use the compromised process to affect connected services
- Integrity of application state or generated output could be impacted
- An attacker may execute arbitrary Perl code in the application process
- Application credentials, secrets, or accessible data could be exposed
- The process could be modified or disrupted
- Attackers could use the compromised process to affect connected services
- Integrity of application state or generated output could be impacted
General mitigation guidance
Mitigation generally focuses on treating YAML as data rather than executable content and reducing trust in deserialized input.
Common defensive patterns include:
- Use safe, restricted YAML parsing modes that do not construct arbitrary objects or evaluate code
- Disable code loading and prevent input from changing parser or loader options
- Apply an allowlisted schema for accepted YAML structures and scalar types
- Avoid processing attacker-controlled documents in a shared process where parser state can persist
- Isolate parsing workloads and run them with least-privilege permissions
- Reduce exposure of secrets and sensitive resources to the parsing process
Mitigation generally focuses on treating YAML as data rather than executable content and reducing trust in deserialized input.
Common defensive patterns include:
- Use safe, restricted YAML parsing modes that do not construct arbitrary objects or evaluate code
- Disable code loading and prevent input from changing parser or loader options
- Apply an allowlisted schema for accepted YAML structures and scalar types
- Avoid processing attacker-controlled documents in a shared process where parser state can persist
- Isolate parsing workloads and run them with least-privilege permissions
- Reduce exposure of secrets and sensitive resources to the parsing process
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis rules identifying unsafe YAML loaders, code-evaluation paths, and unrestricted glob or package-variable handling
- Code review signals such as deserialization of external input followed by string evaluation or mutable global parser settings
- Tests that verify code-loading controls cannot be changed by input documents
- Dependency and policy checks covering YAML parser configuration and safe-deserialization requirements
- Runtime monitoring for unexpected Perl process behavior, child-process creation, or access to sensitive resources after YAML processing
Automated security review tools may help identify unsafe parser usage, but findings should be validated against the application's input and process boundaries.
Organizations can look for this weakness through:
- Static analysis rules identifying unsafe YAML loaders, code-evaluation paths, and unrestricted glob or package-variable handling
- Code review signals such as deserialization of external input followed by string evaluation or mutable global parser settings
- Tests that verify code-loading controls cannot be changed by input documents
- Dependency and policy checks covering YAML parser configuration and safe-deserialization requirements
- Runtime monitoring for unexpected Perl process behavior, child-process creation, or access to sensitive resources after YAML processing
Automated security review tools may help identify unsafe parser usage, but findings should be validated against the application's input and process boundaries.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
| metacpan. | metacpan.org/ |
| openwall. | openwall.com/ |
