REDHAT-BUG-2545818: High severity YAML YAML vulnerability

Q: Which deployments are realistically exposed?

Applications are exposed when an attacker can supply YAML to Load() at least twice within the same Perl process. The attacker needs the first load to contain a perl/glob document and a later load to contain a perl/code document.

Q: Does disabling YAML code loading by default prevent exploitation?

No. Although code loading is off by default, a perl/glob document can set $YAML::LoadCode or $YAML::UseCode during an earlier Load() call, enabling code loading for later calls in that process.

Q: What can be done if an update is not immediately possible?

Do not pass attacker-controlled YAML to Load(), particularly in long-lived processes that handle multiple YAML documents or requests. Preventing untrusted input from reaching either Load() call blocks the described two-stage attack.

Q: How can we look for attempted exploitation?

Inspect YAML supplied to the application for perl/glob documents that target package variables such as $YAML::LoadCode, $YAML::UseCode, or @INC, followed by perl/code documents processed by later Load() calls in the same process.

Published Oct 5, 2026

Updated

YAML versions before 1.27001 for Perl allow a loaded perl/glob document to replace any package variable, which can lead to arbitrary code execution.

A perl/glob document names a package and a symbol, and supplies the value assigned to it. Nothing restricts the name, so the target can be @INC or YAML's own load options.

A perl/glob document that sets $YAML::LoadCode or $YAML::UseCode turns on code loading, which is off by default, for every later Load() in the process. A perl/code document is then passed to a string eval, so an attacker who supplies two documents to separate Load() calls in one process can execute arbitrary Perl code.

Affected Software

1 affected component

YAML YAML<1.27_001

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade YAML to a version that resolves this vulnerability.
Fixed in 1.27_001

Event History

Oct 5, 2026

Data Sourced

via Red Hat·07:08 AM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which deployments are realistically exposed?

Applications are exposed when an attacker can supply YAML to Load() at least twice within the same Perl process. The attacker needs the first load to contain a perl/glob document and a later load to contain a perl/code document.

Does disabling YAML code loading by default prevent exploitation?

No. Although code loading is off by default, a perl/glob document can set $YAML::LoadCode or $YAML::UseCode during an earlier Load() call, enabling code loading for later calls in that process.

What can be done if an update is not immediately possible?

Do not pass attacker-controlled YAML to Load(), particularly in long-lived processes that handle multiple YAML documents or requests. Preventing untrusted input from reaching either Load() call blocks the described two-stage attack.

How can we look for attempted exploitation?

Inspect YAML supplied to the application for perl/glob documents that target package variables such as $YAML::LoadCode, $YAML::UseCode, or @INC, followed by perl/code documents processed by later Load() calls in the same process.

REDHAT-BUG-2545818: High severity YAML YAML vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are realistically exposed?

Does disabling YAML code loading by default prevent exploitation?

What can be done if an update is not immediately possible?

How can we look for attempted exploitation?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are realistically exposed?

Does disabling YAML code loading by default prevent exploitation?

What can be done if an update is not immediately possible?

How can we look for attempted exploitation?