Notifications
Clear all
Topic starter
02/08/2026 12:21 pm
TL;DR: yaml.Loader is unsafe in all released versions of PyYAML, while yaml.safe_load remains safe in every version and yaml.load, yaml.full_load, and their _all variants are only known-safe after 5.4, according to Semgrep. The practical lesson is that version-specific API behaviour, not documentation alone, should drive deserialization rules and code scanning.
NHIMG editorial — based on content published by Semgrep: PyYAML API safety depends on version and loader choice
Questions worth separating out
Q: What should security teams do when YAML parsing might expose code execution risk?
A: Treat YAML parsing as a security boundary and default to safe_load for any untrusted content.
Q: Why do unsafe YAML loaders create broader risk than a normal parsing bug?
A: Unsafe loaders can instantiate attacker-controlled Python objects during deserialization, which turns crafted input into a possible code execution path.
Q: How do teams know whether a PyYAML finding is actually exploitable?
A: Check the exact library version, the loader class in use, and whether the input source is trusted.
Practitioner guidance
- Standardise on safe_load for untrusted YAML Require yaml.safe_load in application code, CI jobs, and automation that processes external or semi-trusted YAML.
- Tune detection rules to PyYAML version and loader class Update SAST and Semgrep rules so they distinguish yaml.Loader, UnsafeLoader, and the post-5.4 behaviour of yaml.load and yaml.full_load.
- Inventory YAML ingestion points that touch secrets or identity data Map every service that parses YAML before it can reach credentials, tokens, deployment manifests, or workload identity settings.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- The version-by-version test matrix showing which PyYAML APIs were vulnerable and when
- The Semgrep rule changes used to separate true positives from SafeLoader false positives
- The payload-testing approach that practitioners can adapt for other libraries with a history of unsafe deserialization
- The exact rule logic behind alerting on unsafe_load, Loader, UnsafeLoader, and C variants
👉 Read Semgrep's analysis of PyYAML loader safety and deserialization risk →
PyYAML loader safety: which APIs are actually safe now?
Explore further
02/08/2026 1:22 pm
Unsafe deserialization is an access-control problem disguised as a parsing bug. When a library can turn attacker-controlled input into executable objects, the application has effectively delegated trust at the wrong boundary. That matters to identity programmes because configuration files, automation manifests, and pipeline inputs often carry credentials, tokens, and endpoint metadata. Practitioners should treat deserialization policy as part of the control plane, not as a developer convenience.
A question worth separating out:
Q: What is the difference between yaml.safe_load and broader PyYAML loaders?
A: yaml.safe_load restricts input to basic data types and blocks object construction behaviour that can be abused for code execution. Broader loaders allow more expressive parsing, but that flexibility creates risk when input is not fully trusted. Use the safe path unless you have a narrow, reviewed need for richer deserialization.
👉 Read our full editorial: PyYAML API safety depends on version and loader choice
