CVE-2022-1471
RCE in Snakeyaml Project Snakeyaml ≤ 2.0
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:LSummary
CVE-2022-1471 is a high-severity Improper Input Validation (CWE-20) vulnerability in Snakeyaml Project Snakeyaml. Its CVSS base score is 8.3 (High).
Operationally, ranked in the top 0.1% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) and SI-2 (Flaw Remediation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
SnakeYaml's Constructor() class permits unrestricted instantiation of arbitrary Java types during YAML deserialization, exposing any application that parses attacker-controlled YAML content to remote code execution. The flaw is tracked as CVE-2022-1471, carries a CVSS 3.1 score of 8.3, and is rooted in improper input validation and unsafe deserialization (CWE-20, CWE-502). It affects all versions prior to 2.0 that rely on the default Constructor rather than SafeConstructor.
An attacker with the ability to supply malicious YAML—typically over a network with low complexity and requiring only low privileges—can trigger instantiation of classes that lead to arbitrary code execution on the target. Exploitation succeeds when the application deserializes the untrusted content without type restrictions, allowing construction of objects that invoke dangerous methods or load attacker-controlled classes.
Public advisories, including those from Atlassian and the SnakeYaml project, explicitly recommend migrating to SafeConstructor for untrusted input and upgrading to SnakeYaml 2.0 or later. Several downstream products, such as PyTorch Model Server, have published coordinated fixes or configuration guidance referencing the same issue.
The CVE maintains an EPSS score near 0.94, indicating sustained exploitation interest across multiple affected libraries and frameworks referenced in the disclosed URLs.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2022-7690
Vulnerability Data
SnakeYaml's Constructor() class does not restrict types which can be instantiated during deserialization. Deserializing yaml content provided by an attacker can lead to remote code execution. We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization. We recommend…
more
upgrading to version 2.0 and beyond.
- CWE(s)
Related Threats
Likely ATT&CK TechniquesAI
Techniques this vulnerability likely enables, inferred from its description, weakness type, and attributed-actor tradecraft. Confidence is per-technique.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly requires validation of YAML input to block instantiation of arbitrary types during deserialization, addressing the root CWE-20 flaw.
Mandates timely remediation (upgrade to SnakeYaml 2.0+) of the known vulnerable Constructor class to eliminate the unsafe deserialization path.
Requires mechanisms to detect and block malicious code payloads that result from attacker-controlled YAML object instantiation.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require and enforce input validation during development.
PR.PS-02 addresses only post-deployment updates/patching and cannot prevent introduction of unsafe deserialization code, yet it can remediate some instances when the flaw exists in outdated libraries or components.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Testing against a defined set of requirements and using code review plus vulnerability scanning forces validation of inputs and handling of unanticipated conditions, reducing the chance that malformed data will be accepted.
Secure-coding guidelines and mandatory security testing (including code scans) compel developers to validate and sanitize inputs at design and implementation time, lowering the incidence of malformed or malicious data reaching downstream components.
Mandating input controls that include integrity checks and input validation ensures that untrusted data is examined before use, blocking the root cause of many injection and malformed-data weaknesses.
Security-by-design principles explicitly call for data validation and sanitization at every layer, reducing the chance that malformed or malicious input will be processed without scrutiny.
Requiring language-specific secure coding standards, peer review, SAST and documented mitigation of common programming errors forces validation of all inputs before they are trusted.
Regular scanning of third-party libraries and timely patching reduce the likelihood that unsafe deserialization vulnerabilities remain active.