External risk intelligence

YAML for Perl Arbitrary Class DESTROY Execution

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2017-20285

This is a vulnerability in a Perl library used to parse YAML documents. While YAML parsing is a common component in many applications, including web-facing services, the library itself is a general-purpose utility. It is not inherently public-facing by design, but it may be reachable in environments that process untrusted YAML input from the internet.

Deserialization

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This critical vulnerability affects how Perl processes YAML, allowing malicious documents to execute arbitrary code. When improperly handled, this could lead to unauthorized deletion of sensitive data or system files. The main concern is confirming if and where this technology is used to process external YAML inputs.

Code execution risk from malicious YAML.
Potential for data deletion or system compromise.
Confirm usage with external YAML data.

Attack Path

How an attacker could exploit the issue

An attacker could target systems processing YAML documents with a specially crafted input. This input, when loaded by the vulnerable YAML library, can trigger the execution of arbitrary code by calling the `DESTROY` method of classes that have been loaded into the Perl process. If a vulnerable application has loaded specific modules, such as `File::Temp::Dir`, this could allow an attacker to delete directory trees.

Vulnerable YAML parsing occurs.
Malicious YAML document is loaded.
Arbitrary code execution; directory deletion.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, a loaded YAML document could trigger the DESTROY method of arbitrary classes, potentially leading to the deletion of named directory trees if the `File::Temp::Dir` module is in use.

Deletion of arbitrary directories.
Triggered by processing a malicious YAML document.
System disruption and data loss.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts applications that use the YAML module in Perl to parse untrusted documents, potentially allowing arbitrary code execution via the `DESTROY` method. The first practical step involves identifying all systems processing YAML data, confirming exposure to untrusted input, and determining business criticality to prioritize remediation. Application owners, responsible for the code that utilizes the YAML module, should lead this effort in coordination with infrastructure and security teams.

Application owners should manage remediation.
Verify YAML parsing of untrusted input.
Plan risk-based remediation actions.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the YAML module for Perl?

The YAML module is a general-purpose software library for the Perl programming language. Developers use it to translate data between the human-readable YAML format and internal Perl data structures. It acts as a bridge, allowing Perl applications to easily read, write, and exchange configuration files or data streams that rely on the YAML syntax.

How does CVE-2017-20285 allow arbitrary code execution?

This vulnerability involves insecure deserialization, categorized as CWE-502 and CWE-470. When the YAML library processes a crafted document, it can be tricked into 'blessing' a hash into a specific class. Because Perl automatically calls a special 'DESTROY' method when objects go out of scope, a malicious document can force the system to execute that method for arbitrary loaded classes, potentially causing unintended actions like file deletion.

What must happen for this vulnerability to be triggered?

An attacker must successfully supply a specially crafted YAML document to an application that uses the vulnerable library to parse it. This bug is not triggered by simply having the YAML module installed on a system; the application must actively ingest and process untrusted input. If an application only processes YAML files created by trusted internal sources, the risk path is largely negated.

Is my system at risk if it uses this library?

Halo Surface Signal indicates that while this is a general-purpose library, your risk depends on how your software is positioned. If your applications are internet-facing and process untrusted YAML input, they are at higher risk. Internal-only systems that do not ingest external data are less likely to be reachable by an attacker attempting to leverage this specific flaw.

How should I begin addressing this YAML vulnerability?

Start by auditing your environment to identify which applications utilize the YAML module for Perl. Prioritize systems that ingest data from external or untrusted sources, as these are the primary targets. Coordinate with your application owners to evaluate whether their services process untrusted input and plan for necessary updates or configuration changes to isolate the parsing process.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.