CVE-2022-1471: Remote code execution in SnakeYAML deseria...

Lede

CVE-2022-1471 is a critical deserialization vulnerability in SnakeYAML, the widely used Java library for parsing and emitting YAML. The flaw lives in SnakeYAML's Constructor class, which — when used to load YAML from an untrusted source — does not restrict which Java types can be instantiated during deserialization. An attacker who can supply YAML content that gets parsed by a vulnerable application can craft a document that instantiates arbitrary classes on the classpath, chaining known "gadget" objects into remote code execution (RCE). Because SnakeYAML sits deep inside the dependency tree of an enormous number of Java applications — pulled in transitively by frameworks, YAML-based configuration loaders, and API tooling — the practical blast radius of this bug is far larger than a single library update would suggest. Organizations that treat their YAML config files as "just config" have historically underestimated how much of their attack surface actually runs through a full-featured deserializer.

Affected Versions and Components

The vulnerability affects SnakeYAML versions prior to 2.0. The root cause is architectural rather than a simple coding mistake: SnakeYAML's default Constructor class was designed to support rich YAML tag-based type instantiation, and by default it does not apply an allow-list of "safe" types before instantiating objects described in the YAML document. Any application that calls new Yaml().load(untrustedInput) (or otherwise loads YAML using the default Constructor rather than SafeConstructor) on data that isn't fully trusted is potentially exposed.

This is not a niche library. SnakeYAML ships as a transitive dependency of Spring Framework/Spring Boot (via spring-boot-starter and YAML property-source support), numerous Jackson YAML data-format integrations, CI/CD tools, API gateways, and countless internal microservices that use YAML for configuration, service definitions, or data interchange. Many teams that have never explicitly declared a SnakeYAML dependency in their build files are still shipping a vulnerable version of it because it arrived silently through two or three layers of transitive dependencies. That indirection is precisely why this CVE became a widely cited example in software supply chain security discussions rather than a routine library patch.

The fix landed in SnakeYAML 2.0, which changed the library's default posture: loading YAML without an explicitly specified constructor now defaults to safer behavior, and the library introduced mechanisms (such as TrustedTagInspector) for applications that still need to construct custom types from YAML to do so under an explicit allow-list rather than an open one.

CVSS, EPSS, and KEV Context

NVD scored CVE-2022-1471 as Critical, with a CVSS v3.1 base score of 9.8 (vector reflecting network-exploitable, low attack complexity, no privileges or user interaction required, and high impact to confidentiality, integrity, and availability). That score is consistent with the nature of the bug: if an attacker can get attacker-controlled YAML into a vulnerable load() call, the path to full RCE is direct rather than requiring extensive chaining or environmental prerequisites — the main "cost" is finding a suitable gadget class already on the application's classpath.

EPSS (Exploit Prediction Scoring System) percentiles for this CVE have shifted over time as scanners, researchers, and automated tooling incorporated it into signature sets; because EPSS is recalculated continuously, teams doing active risk triage should pull the current score from FIRST.org's EPSS API rather than relying on a point-in-time figure quoted in a blog post. At the time of writing, we are not aware of CVE-2022-1471 being listed on CISA's Known Exploited Vulnerabilities (KEV) catalog — but given how deeply SnakeYAML is embedded across the Java ecosystem, and how often deserialization bugs of this class get weaponized once a reliable gadget chain is published, treating it as "not KEV, therefore low priority" would be a mistake. KEV listing reflects confirmed, observed exploitation in the wild; the absence of that listing says nothing about exploitability, which here is high.

Timeline

SnakeYAML's default Constructor behavior — full, unrestricted type instantiation during deserialization — is a long-standing design characteristic of the library rather than a bug introduced in a single release. This same underlying pattern had already produced a related, earlier finding in the library (CVE-2017-18640), which is often confused with CVE-2022-1471 but is a distinct CVE tied to earlier SnakeYAML versions. CVE-2022-1471 was assigned and published to formally track the RCE risk in the still-unpatched default Constructor behavior present in versions before 2.0. Following disclosure, the SnakeYAML maintainers shipped version 2.0, which restructured default loading behavior to reduce the risk of unsafe type instantiation for consumers who don't explicitly opt into it. Because the fix required a major version bump (1.x to 2.0), it was not a drop-in patch release — some downstream projects needed to validate compatibility before adopting it, which slowed remediation across the ecosystem relative to a typical point-release fix. In the months that followed, downstream projects and vendors (including large Java frameworks and application platforms) issued their own advisories directing users to bump their SnakeYAML dependency, reflecting how far the transitive footprint of this library extends.

Remediation Steps

1. Find every copy of SnakeYAML in your environment, not just the ones you declared. Use dependency-tree analysis (mvn dependency:tree, gradle dependencies) or a software composition analysis (SCA) tool to identify direct and transitive uses of SnakeYAML across all services, including build tooling and CI pipelines, not just runtime application code.

2. Upgrade to SnakeYAML 2.0 or later wherever possible. This is the primary fix and addresses the unsafe default Constructor behavior at the source.

3. Where an immediate major-version upgrade isn't feasible, stop using the default Constructor on untrusted input. Explicitly construct your Yaml instance with SafeConstructor, or define an allow-list of expected types, so that YAML parsing cannot instantiate arbitrary classes even on the older library version.

4. Audit every call site that loads YAML from an external or semi-trusted source — uploaded config files, webhook payloads, API request bodies, third-party plugin manifests — and confirm none of them pass untrusted data into an unrestricted loader.

5. Pin and monitor the resolved version continuously. Because SnakeYAML frequently re-enters a dependency tree transitively (a framework or plugin update can silently reintroduce an older version), a one-time fix is not sufficient. Continuous SCA/SBOM monitoring is needed to catch regressions.

6. Validate compatibility after upgrading. The 2.0 default-behavior change can affect applications that relied on the permissive constructor for legitimate custom-type deserialization; test YAML-driven configuration and data paths after the upgrade rather than assuming a drop-in replacement.

How Safeguard Helps

CVE-2022-1471 is a textbook case for why point-in-time dependency audits aren't enough: the vulnerable library rarely appears as a direct, visible dependency, and it can silently re-enter an application through an unrelated framework or plugin bump long after a team believes the issue is closed. Safeguard is built to close exactly that gap.

Safeguard continuously generates and maintains accurate software bills of materials (SBOMs) across your services, capturing not just declared dependencies but the full transitive tree — so a buried SnakeYAML instance pulled in by a framework three layers deep shows up the same way a direct dependency would. When a CVE like this one is disclosed or its scoring changes, Safeguard maps it against your live inventory in real time, so security and engineering teams know within minutes which services, images, and build pipelines are actually affected, rather than waiting for a manual grep across repositories.

Beyond detection, Safeguard tracks remediation status over time and flags regressions — the exact scenario where an upgraded service later reintroduces a vulnerable SnakeYAML version through an unrelated dependency bump. That continuous monitoring, combined with policy-driven gates in CI/CD, lets teams block builds that reintroduce known-vulnerable deserialization paths before they ship, turning a one-time patch into a durable, enforced control rather than a checkbox that quietly expires.