CVE-2017-20285: 
Linux Debian vulnerability analysis and mitigation

CVE-2017-20285 is a deserialization/unsafe reflection vulnerability in the YAML module for Perl (versions before 1.30) that allows a maliciously crafted YAML document to trigger the DESTROY method of arbitrary classes. When a perl/hash:Class tag is used in a YAML document, the loader blesses a hash into the named class; Perl then automatically calls that class's DESTROY method when the object goes out of scope. The impact depends on which classes are loaded in the process — for example, File::Temp::Dir from core Perl can be abused to delete arbitrary directory trees. It carries a CVSS v3.1 base score of 9.1 (Critical) (Red Hat Advisory, Github Advisory). The issue was originally reported in May 2017 and formally assigned a CVE identifier in October 2026 (GitHub Issue).

The root cause is classified under CWE-470 (Use of Externally-Controlled Input to Select Classes or Code / Unsafe Reflection) and CWE-502 (Deserialization of Untrusted Data) (Github Advisory). The YAML loader's handling of Perl-specific tags (e.g., !perl/hash:Foo::Bar) unconditionally blesses a parsed hash into the attacker-specified class using CORE::bless, without validating or restricting which classes may be instantiated. Because Perl automatically invokes a class's DESTROY method when an object goes out of scope, an attacker who can supply a YAML document to a vulnerable parser can trigger destructors of any class already loaded in the process. A concrete example using File::Temp::Dir demonstrates that the named directory path supplied in the document fields will be deleted upon object destruction (GitHub Issue, Red Hat Bugzilla). The fix introduced the $YAML::LoadBlessed configuration option (defaulting to false in version 1.30) to gate all blessed object creation (Patch 1, Patch 2).

Successful exploitation allows an unauthenticated, remote attacker to trigger arbitrary destructor methods in any Perl class loaded by the target process, without requiring any user interaction. The most immediately demonstrable impact is arbitrary file/directory deletion via File::Temp::Dir, but the actual impact is highly dependent on which modules are loaded — other classes with destructors could enable broader code execution, data exfiltration, or service disruption. The CVSS score reflects high confidentiality and integrity impact with no availability impact scored, though real-world exploitation could affect availability through file deletion (Red Hat Advisory, Github Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Red Hat Advisory). The vulnerability is network-exploitable with no authentication or user interaction required, and NVD's SSVC assessment marks it as automatable (Github Advisory). The EPSS score is approximately 0.18–0.32%, placing it in roughly the 24th percentile for exploitation likelihood (Github Advisory). The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Identify target: Locate a Perl application that accepts and parses YAML input from untrusted sources using the YAML module (versions < 1.30) with $YAML::LoadBlessed enabled (default in versions < 1.30).
2. Determine loaded modules: Identify which Perl modules are loaded by the target process (e.g., via error messages, documentation, or source code review) to select a class with a useful DESTROY method, such as File::Temp::Dir.
3. Craft malicious YAML document: Construct a YAML document using a perl/hash:ClassName tag that blesses a hash into the target class and supplies attacker-controlled field values. Example for directory deletion:

--- !perl/hash:File::Temp::Dir
cleanup: 1
dirname: /path/to/target/directory

4. Submit the payload: Deliver the crafted YAML document to the target application through any input vector that triggers YAML parsing (e.g., API request body, file upload, configuration input).
5. Trigger DESTROY: When the parsed object goes out of scope (e.g., at the end of the request handler), Perl automatically calls the DESTROY method of the blessed class, executing the attacker's intended action (e.g., deleting the specified directory tree) (GitHub Issue, Red Hat Bugzilla).

• Logs: Application logs showing YAML parsing errors or unexpected object instantiation for classes like File::Temp::Dir; Perl warnings about blessed objects being created from untrusted input.
• File System: Unexpected deletion of directories or files that correspond to paths controllable via application input; missing temporary directories or application data directories.
• Process: Perl processes loading YAML documents from network sources and subsequently invoking destructor methods on unexpected class instances; unusual file system operations (rmdir, unlink) originating from the application process.
• Network: Inbound requests containing YAML payloads with !perl/hash:, !perl/array:, or similar Perl-specific YAML tags in request bodies or uploaded files.

Upgrade the Perl YAML module to version 1.30 or later, which changes the default value of $YAML::LoadBlessed to undef (false), preventing automatic blessed object creation from YAML tags (Patch 2, Github Advisory). For applications that cannot immediately upgrade, explicitly set $YAML::LoadBlessed = 0 before parsing any untrusted YAML documents. Additionally, restrict which Perl modules are loaded in processes that parse untrusted YAML, and avoid loading modules with destructive DESTROY methods (e.g., File::Temp::Dir) in such contexts (Red Hat Advisory).

The vulnerability was originally reported to the yaml-pm project in May 2017 by researcher dod38fr, who noted the similarity to related issues in YAML::XS and referenced a Debian bug report demonstrating the File::Temp::Dir abuse scenario (GitHub Issue). The fix was developed by Tina Müller (perlpunk) at the Perl Toolchain Summit in 2018, with the $YAML::LoadBlessed option introduced in version 1.24_001 and the secure default (off by default) finalized in version 1.30 in January 2020. The CVE identifier was formally assigned and published in October 2026, prompting downstream advisories from Red Hat, Ubuntu (USN-8925-1), and coverage in the oss-security mailing list (Github Advisory).