Is pyyaml healthy, maintained, and safe?
No. PyYAML carries 4 unpatched critical advisories and should not be adopted without a remediation plan.
The verdict
On the OSPulse health scale, PyYAML lands at 10/100, a critical risk rating, computed deterministically from live PyPI release history, and the OSV vulnerability database. No. PyYAML carries 4 unpatched critical advisories and should not be adopted without a remediation plan.
Nothing has shipped since 25 September 2025, over a year ago (395 days), which points to a dormant project. Historically it released far more frequently, so the current silence reads as a genuine collapse in velocity rather than a natural gap. PyPI doesn't expose a reliable maintainer count, so bus-factor isn't scored here. Treat maintenance depth as unknown rather than assumed.
OSV lists 8 known advisories for PyYAML, including 4 critical. Open critical advisories are the strongest possible signal to pin to a patched version, replace, or fork before shipping. Each advisory is listed with its OSV/GHSA identifier below.
The safest reading is to replace, fork, or tightly pin PyYAML and stop taking on new exposure to it. This is a one-time snapshot of a single package. Real projects depend on dozens or hundreds of packages, and any one of them can drift or be compromised between releases. Run your own requirements.txt through the free health check, or have OSPulse monitor your whole dependency tree continuously.
Evidence trail: deterministic, auditable
Known vulnerabilities (8)
Deserialization of Untrusted Data in PyYAML
Improper Input Validation in PyYAML
Improper Input Validation in PyYAML
PyYAML insecurely deserializes YAML strings leading to arbitrary code execution
In PyYAML before 5.1, the yaml.load() API could execute arbitrary code if used with untrusted data. The load() function has been deprecated in version 5.1 and the 'UnsafeLoader' has been introduced fo
PyYAML 5.1 through 5.1.2 has insufficient restrictions on the load and load_all functions because of a class deserialization issue, e.g., Popen is a class in the subprocess module. NOTE: this issue ex
A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method o
A vulnerability was discovered in the PyYAML library in versions before 5.4, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or
Key facts
- Latest version
- v6.0.3
- Last release
- 25 September 2025 (395 days ago)
- Total releases
- 30
- First release
- 1 July 2011
- Package age
- 15.3 years
- Maintainers
- not exposed by PyPI
- Known advisories
- 8
- Confidence
- High
Frequently asked
Is PyYAML still maintained?
Partly. The most recent release was 25 September 2025 (395 days ago), so maintenance has slowed but not fully stopped.
Does PyYAML have known security vulnerabilities?
Yes. OSV lists 8 advisories for PyYAML, including 4 rated critical. See the advisory list on this page for the OSV/GHSA identifiers.
Is PyYAML safe to use?
No. PyYAML carries 4 unpatched critical advisories and should not be adopted without a remediation plan. OSPulse rates it 10/100 (critical risk) based on release recency, cadence and known vulnerabilities.
Alternatives to pyyaml
Other PyPI packages we've checked
pyyaml is one package. What about the other hundreds in your tree?
Paste your own requirements.txt into the free health check for an instant snapshot, or let OSPulse monitor your whole dependency tree continuously, before your CVE scanner wakes up.
Data from the PyPI registry & OSV.dev · snapshot generated 2026-10-26 · scores are deterministic and recomputed on each refresh.