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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Fully loaded: testing vulnerable PyYAML versions”.
Key questions
Q: When does PyYAML deserialization become unsafe in practice?
A: It becomes unsafe when untrusted YAML is parsed with a loader that can construct Python objects or otherwise execute attacker-controlled tags.
Q: Why do security teams need version-aware rules for YAML parsing?
A: Because the same API name can have different exploitability across package releases.
Q: What do teams get wrong about safe YAML loading?
A: They often treat the presence of a safe API as proof that the whole codebase is safe.
Practitioner guidance
- Standardise on safe YAML loading Require yaml.safe_load for untrusted input wherever YAML is parsed, and block use of object-capable loaders in code review unless a documented exception exists.
- Version-gate deserialization findings Update SAST and Semgrep rules so they alert on loader usage only where the installed PyYAML version is actually vulnerable, rather than on every historical API reference.
- Inventory unsafe loader call sites Search codebases for yaml.load, yaml.full_load, yaml.Loader, and UnsafeLoader usage, then classify each instance by package version and business justification.
Bottom line: PyYAML deserialization safety is version-dependent, and unsafe loaders can still create code execution risk when they accept untrusted input.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:22 pm
Version-aware deserialization is a governance requirement, not a nice-to-have. The article shows that API safety changed over time and that blanket scanner rules are too blunt when package behaviour shifts across releases. Security teams need controls that track both the call site and the dependency version. The practical conclusion is that deserialization policy must be version-scoped, or it will either miss exploitability or drown teams in false positives.
A question worth separating out:
Q: How should organisations handle unsafe YAML loader usage in older code?
A: They should replace unsafe loaders with yaml.safe_load wherever possible, then document any remaining object-capable parsing as an exception with version context and code-owner review. If an application cannot be upgraded immediately, the parser should be scanned and tightly constrained rather than assumed safe.
👉 Read our full editorial: PyYAML API safety depends on version and loader choice