CVE-2026-94093 json
DLR-RM stable-baselines3 save_util.py VecNormalize.load deserialization
published last mo. modified last mo. also EUVD-2026-83800
- cvss
- 6.3
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.5%
- EPSS 0.5% chance of exploitation in 30 days, percentile 39%
- public exploits
- 0
- none known
Summary
A security vulnerability has been detected in DLR-RM stable-baselines3 up to 2.9.0. This affects the function PPO.load/load_replay_buffer/VecNormalize.load of the file save_util.py. Such manipulation leads to deserialization. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. In v2.9.0 the PyTorch tensor load path is hardened (weights_only=True), but that hardening was later reverted on master via PR #1913 "Hotfix: revert loading with weights_only=True" [blocked] to fix PyTorch 1.13 compat - so even the one "safe" path is inconsistent across versions. #2281 was closed as a duplicate of #1831 since both are unsafe pickle deserialization - but #1831's fix (PR #41) only gated the Hugging Face Hub loader in the separate huggingface_sb3 package. This finding covers the core stable_baselines3 load APIs (PPO.load, load_replay_buffer, VecNormalize.load), which have no safe mode or gate and remained exploitable in v2.9.0 until the outstanding hardening (PR #2264) ships.
Is CVE-2026-94093 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCISA SSVC
- Exploitation
- Proof of concept is public
- Automatable
- no
- Technical impact
- partial
- Assessed
- last mo.
Exploit prediction
0.45% chance of exploitation in the next 30 days, higher than 39% of all scored CVEs (FIRST EPSS, 2026-11-11).
Exploits and checks
- github.com https://github.com/DLR-RM/stable-baselines3/issues/2281 referenced PoC, tagged "exploit" by a source, unverified
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 4.0 | 5.3 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P |
| CNA | 3.1 | 6.3 | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L/E:P/RL:X/RC:R |
| CNA | 3.0 | 6.3 | CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L/E:P/RL:X/RC:R |
| CNA | 2.0 | 7.5 | AV:N/AC:L/Au:N/C:P/I:P/A:P/E:POC/RL:ND/RC:UR |
| CNA | 4.0 | 2.1 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X |
| CNA | 3.1 | 6.3 | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L |
| CNA | 2.0 | 7.5 | AV:N/AC:L/Au:N/C:P/I:P/A:P |
Inferred packages
No advisory lists a package for this vulnerability yet. The CVE names these as products and links their GitHub repository, and the package registry names the same repository, so they are probably the affected packages. Low confidence: the versions are the CVE’s own for the product, and a stack check reports the package as unchecked when there are none.
| ecosystem | package | repository | affected |
|---|---|---|---|
| pypi | stable-baselines3 | dlr-rm/stable-baselines3 | no versions given |
Affected products
- DLR-RM stable-baselines3
Classification
References
-
github.com
/DLR-RM/stable-baselines3/issues/2281
issue-tracking, exploit
-
vuldb.com
/vuln/408021
vdb-entry, technical-description
-
vuldb.com
/vuln/408021/cti
signature, permissions-required
-
vuldb.com
/cve/CVE-2026-94093
third-party-advisory
-
vuldb.com
/submit/952734
third-party-advisory
-
github.com
/DLR-RM/stable-baselines3/
product
Sources
- CVE List CVE-2026-94093
- NVD CVE-2026-94093
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.