This might be a false positive, but requirements.txt around line 15 looked worth a second pair of eyes.
CRITICAL — Remote Code Execution in PyTorch model loading (CVE-2025-32434)
The pinned torch==2.5.1+cu121 in requirements.txt is vulnerable to a remote code execution flaw during deserialization. The key danger of this CVE is that it bypasses torch.load(..., weights_only=True), which developers have historically treated as the safe way to load model checkpoints. This means the usual mitigation pattern offers no protection.
Impact: Any code path that loads a model file from a source an attacker can influence (user-uploaded checkpoints, model registries, artifacts fetched from external storage, CI pipelines pulling third-party models) becomes an RCE vector — an attacker crafts a malicious model file, and loading it executes arbitrary code on the host with the service's privileges.
Risk level: CRITICAL (CVSS ~9.3). Exploitation is trivially scriptable, the vulnerable pattern (torch.load) is ubiquitous in ML services, and the common defense (weights_only=True) is ineffective in the affected versions.
Remediation: Upgrade to PyTorch >= 2.6.0, where the deserialization path is patched. Note: 2.6.0 does not publish +cu121 wheels — available CUDA builds are cu118/cu124/cu126 — so the CUDA variant pin (and any wheel index URL) must be updated as well. If torchvision/torchaudio are present, bump them to 0.21.0/2.6.0 for ABI compatibility.
Something like this might fix it:
```diff
--- a/requirements.txt
+++ b/requirements.txt
@@ -12,7 +12,7 @@
numpy==1.26.4
-pillow==10.4.0
+pillow==10.4.0
transformers==4.47.1
-torch==2.5.1+cu121
+torch==2.6.0
```
Notes for applying this fix:
1. **Plain `torch==2.6.0`** installs the default PyPI wheel (bundled with CUDA 12.4 support on Linux).
2. **If you require a specific CUDA build**, the `+cu121` variant does not exist for 2.6.0 — switch to a published variant, e.g. `torch==2.6.0+cu124`, and update the extra index URL accordingly:
```diff
--- a/requirements.txt
+++ b/requirements.txt
@@ -12,1 +12,1 @@
-torch==2.5.1+cu121 --extra-index-url https://download.pytorch.org/whl/cu121
+torch==2.6.0+cu124 --extra-index-url https://download.pytorch.org/whl/cu124
```
3. **Upgrade companion packages** to matching versions for compatibility:
```diff
-torchvision==0.20.1+cu121
+torchvision==0.21.0
-torchaudio==2.5.1+cu121
+torchaudio==2.6.0
```
4. After upgrading, regenerate/verify your lockfile (`pip-compile`, `poetry lock`, etc.), run your model inference smoke tests, and confirm the deployed image builds against the new CUDA runtime.
5. Defense-in-depth (recommended but secondary): only load checkpoints from trusted, access-controlled storage, and avoid exposing model-upload endpoints to unauthenticated users — the upgrade fixes the CVE, but load-source hygiene still reduces overall attack surface.
For reference: rule CVE-2025-32434. Rated critical.
I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
This might be a false positive, but
requirements.txtaround line 15 looked worth a second pair of eyes.CRITICAL — Remote Code Execution in PyTorch model loading (CVE-2025-32434)
The pinned
torch==2.5.1+cu121in requirements.txt is vulnerable to a remote code execution flaw during deserialization. The key danger of this CVE is that it bypassestorch.load(..., weights_only=True), which developers have historically treated as the safe way to load model checkpoints. This means the usual mitigation pattern offers no protection.Impact: Any code path that loads a model file from a source an attacker can influence (user-uploaded checkpoints, model registries, artifacts fetched from external storage, CI pipelines pulling third-party models) becomes an RCE vector — an attacker crafts a malicious model file, and loading it executes arbitrary code on the host with the service's privileges.
Risk level: CRITICAL (CVSS ~9.3). Exploitation is trivially scriptable, the vulnerable pattern (
torch.load) is ubiquitous in ML services, and the common defense (weights_only=True) is ineffective in the affected versions.Remediation: Upgrade to PyTorch >= 2.6.0, where the deserialization path is patched. Note: 2.6.0 does not publish
+cu121wheels — available CUDA builds are cu118/cu124/cu126 — so the CUDA variant pin (and any wheel index URL) must be updated as well. Iftorchvision/torchaudioare present, bump them to 0.21.0/2.6.0 for ABI compatibility.Something like this might fix it:
For reference: rule
CVE-2025-32434. Rated critical.I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.