CVE-2026-13713 in YAML::Syckinfo

Summary

by MITRE • 07/17/2026

YAML::Syck versions before 1.47 for Perl allow a use-after-free and double-free via an anchor node freed while still on the parser value stack.

In the bundled libsyck, when an anchor name is redefined or removed, syck_hdlr_add_anchor and syck_hdlr_remove_anchor free the node stored under that name with syck_free_node. That node can still be live on the parser's value stack, so syck_hdlr_add_node reaches it again and frees it a second time. On a normal build the 48-byte node chunk is freed twice and the interpreter aborts. Anchors need no special flags, so this is reached on the default Load path, and a 7-byte document that redefines an anchor triggers it.

Any caller that runs Load or LoadFile on an untrusted document that redefines an anchor mid-parse crashes the interpreter, a denial of service.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 07/17/2026

This vulnerability exists in YAML::Syck versions prior to 1.47 for Perl and represents a critical use-after-free and double-free condition within the bundled libsyck library. The flaw occurs during parsing when anchor nodes are managed improperly, creating a scenario where memory operations conflict with the parser's value stack management. When an anchor name is redefined or removed, the system invokes syck_hdlr_add_anchor and syck_hdlr_remove_anchor functions that attempt to free the node stored under that name through syck_free_node. However, this freed node can still remain active on the parser's value stack, causing a second freeing operation when syck_hdlr_add_node accesses it again. The technical implementation involves a 48-byte node chunk being freed twice consecutively, which triggers interpreter termination during normal execution. This vulnerability maps directly to CWE-415: Double Free and CWE-416: Use After Free, both of which are fundamental memory safety issues that have been extensively documented in cybersecurity literature.

The operational impact of this vulnerability extends beyond simple denial of service as it represents a complete interpreter crash condition that affects any application relying on YAML::Syck for parsing untrusted input. The exploit requires only a 7-byte document that redefines an anchor mid-parse to trigger the memory corruption, making it particularly dangerous in production environments where malformed YAML data might be processed from external sources. Since anchors require no special flags and the vulnerability is reachable through the default Load path, any Perl application using this library becomes susceptible to exploitation. The attack surface includes web applications, automated systems, and any software that processes user-supplied YAML content, particularly those handling configuration files, data imports, or API requests containing YAML payloads.

This vulnerability aligns with ATT&CK technique T1203: Exploitation for Client Execution as it enables attackers to cause interpreter crashes through malformed input processing. The memory corruption pattern follows established attack vectors where improper memory management leads to system instability and potential information disclosure. Organizations using vulnerable versions of YAML::Syck should immediately implement mitigations including upgrading to version 1.47 or later, implementing input validation for YAML documents, and considering alternative YAML parsers such as YAML::XS or YAML::LibYAML that do not exhibit this behavior. Additionally, security teams should monitor for potential exploitation attempts targeting this specific memory corruption pattern, as it represents a well-documented attack surface that could be leveraged in broader attack chains involving denial of service or potentially more sophisticated exploits if combined with other vulnerabilities. The vulnerability demonstrates the critical importance of proper memory management in parser implementations and highlights why sandboxing and input sanitization should be considered mandatory defenses against such classes of issues.

Responsible

CPANSec

Reservation

06/29/2026

Disclosure

07/17/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to know what is going to be exploited?

We predict KEV entries!