Is CVE-2017-20285 exploited in the wild?

No. Junglewise Threat Intelligence has no report of CVE-2017-20285 being exploited in the wild.

How severe is CVE-2017-20285?

Informational severity, published 5 October 2026.

How is CVE-2017-20285 attacked?

It is attacked over the network, in a software library.

Am I affected by CVE-2017-20285?

Check whether you run Perl YAML at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

CVE-2017-20285: YAML Perl arbitrary code execution via DESTROY method

CVE-2017-20285 · Severity: info · Published 2026-10-05

YAML is a Perl library for parsing YAML documents, commonly used in configuration management and data processing. Untrusted YAML documents can trigger the DESTROY method of arbitrary Perl classes during object deserialization, which can lead to unintended code execution or file system manipulation if dangerous classes are loaded. This affects systems that parse untrusted or user-supplied YAML content without proper safeguards.

Vendors: Perl.

Quick answers

Is CVE-2017-20285 exploited in the wild?: No. Junglewise Threat Intelligence has no report of CVE-2017-20285 being exploited in the wild.
How severe is CVE-2017-20285?: Informational severity, published 5 October 2026.
Which products and versions are affected?: Perl YAML before 1.30.
Is there a fix for CVE-2017-20285?: Yes: fixed in YAML 1.30. Until then: Set the $YAML::LoadBlessed variable to 0 when loading untrusted YAML data to disable automatic class blessing and object deserialization. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2017-20285 attacked?: It is attacked over the network, in a software library.
Am I affected by CVE-2017-20285?: Check whether you run Perl YAML at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

Fixed in: YAML 1.30

Set the $YAML::LoadBlessed variable to 0 when loading untrusted YAML data to disable automatic class blessing and object deserialization.

Technical details

The vulnerability arises from YAML's automatic blessing of hashes into classes specified by perl/hash:Class tags during deserialization. When the blessed object goes out of scope, Perl invokes its DESTROY method. If a process has loaded certain classes like File::Temp::Dir, an attacker can craft a YAML document that causes DESTROY to execute unintended operations such as deleting arbitrary directory trees. The issue is a code flow problem in the deserialization logic that does not validate or restrict which classes can be blessed.

Affected products

Perl YAML before 1.30

Timeline

2026-10-05: disclosed

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.