DEV Community: metriclogic26

CVE-2025-32434: PyTorch's "safe" model loading flag isn't safe

metriclogic26 — Thu, 19 Mar 2026 03:19:18 +0000

The assumption that broke

For years, the PyTorch documentation said this:

Use weights_only=True to avoid arbitrary code execution
when loading untrusted models.

That assumption is now broken.

CVE-2025-32434 was published on April 17, 2025. CVSS score: 9.3
(Critical). Researcher Ji'an Zhou demonstrated that torch.load()
with weights_only=True can still achieve remote code execution
on PyTorch versions ≤ 2.5.1.

If your team loads models from Hugging Face, TorchHub, or any
community repository, and you haven't updated to PyTorch 2.6.0,
you are exposed.

How the attack works

PyTorch uses Python's pickle format to serialize model weights.
The weights_only=True parameter was designed to restrict
deserialization to safe types only — tensors, primitives,
basic containers.

Zhou demonstrated that an attacker can craft a model file that
exploits inconsistencies in PyTorch's serialization validation
to bypass these restrictions entirely. When a victim loads the
malicious model, arbitrary code executes in their environment.

The attack vector is network-accessible (AV:N), requires no
privileges (PR:N), and no user interaction beyond the normal
model loading workflow (UI:N). In cloud-based ML environments
this could mean lateral movement or data exfiltration.

Who is affected

Any pipeline that does this:

# You were told this was safe. It wasn't.
model = torch.load('model.pt', weights_only=True)

Specifically:

Transfer learning pipelines pulling from public model repos
Automated training pipelines that download community models
Inference servers loading third-party weights
Anyone on torch ≤ 2.5.1

The fix

pip install --upgrade torch>=2.6.0

Or pin in your requirements.txt:

torch>=2.6.0
torchvision>=0.21.0

The broader problem: your full ML stack

PyTorch is one package. Most ML stacks have 20-50 dependencies,
many pinned at versions from 2022-2023 when the model was first
built and never touched again.

Here's what a typical ML requirements.txt looks like after
a real CVE scan:

torch==2.5.1          # CRITICAL CVE-2025-32434
pillow==9.5.0         # HIGH CVE-2023-50447 (Arbitrary Code Execution)
pyyaml==5.3.1         # CRITICAL CVE-2020-14343
cryptography==36.0.0  # HIGH CVE-2023-49083
requests==2.28.0      # MEDIUM CVE-2023-32681

Every one of those has a known CVE. Most ML engineers have no
idea because they haven't scanned their dependencies since
the model was first trained.

How to check your stack right now

Paste your requirements.txt into
PackageFix — free, browser-based,
no signup, no CLI install. It queries the OSV database live
so CVE-2025-32434 and any CVEs published this week are included.

Test file you can paste immediately:

torch==2.5.1
pillow==9.5.0
pyyaml==5.3.1
cryptography==36.0.0
requests==2.28.0
transformers==4.30.0
numpy==1.24.0

Recommended minimum versions for ML stacks in 2026

torch>=2.6.0
torchvision>=0.21.0
pillow>=10.2.0
pyyaml>=6.0.1
cryptography>=42.0.5
requests>=2.32.0
transformers>=4.36.0
numpy>=1.26.0

Pin to these minimums. Add a monthly audit to your calendar.
The OSV database updates daily — CVEs for packages already
in your production stack appear regularly without any
notification unless you're actively checking.

The uncomfortable truth about ML security

The ML community has a dependency hygiene problem. We obsess
over model accuracy, training efficiency, and inference speed.
Almost nobody runs a CVE scanner on their requirements.txt.

CVE-2025-32434 is a critical RCE in the most widely used ML
framework in the world. It affects the exact workflow the
documentation told us was safe.

Check your stack. Update torch. Scan your full requirements.txt.

The attack surface for ML systems is larger than most teams realize.

Running Ollama locally? These 5 server misconfigs can expose your instance to the internet

metriclogic26 — Tue, 17 Mar 2026 15:34:40 +0000

Ollama binds to 0.0.0.0 by default on port 11434. That means if you're running it on a VPS or home server, your entire model API is publicly accessible — no authentication required.

Here's what to check before your Ollama instance becomes someone else's free GPU.

1. Ollama port exposed via Docker

If you're running Ollama in Docker with:
ports: "11434:11434"

That binding bypasses UFW entirely. Docker inserts rules directly into iptables PREROUTING — before UFW even sees the traffic.

The fix:
ports: "127.0.0.1:11434:11434"

Or skip the port mapping entirely and use Docker's internal network if only other containers need access.

2. UFW showing blocked but port still open

Run: curl http://your-server-ip:11434
If you get a response, your Ollama API is public regardless of what UFW status shows.

Paste your ufw status verbose output and check for IPv4/IPv6 mismatches — a common gap that leaves ports open on one protocol.

3. Cron jobs colliding with model pulls

Scheduled model pulls + backup jobs firing at the same time = server load spike = hung process. Visualize your full cron timeline before adding Ollama maintenance tasks.

4. SSL not covering your Ollama web interface

If you're proxying Open WebUI or any Ollama frontend through Nginx or Traefik — that cert will expire. Check expiry across all your domains at once, not just the main one.

5. Dependencies in your Ollama extensions

Building custom tools or scripts on top of Ollama? Your requirements.txt or package.json has CVEs you don't know about — the OSV database updates daily and AI training data is always stale.

The tools

ConfigClarity — Docker, firewall, cron, SSL, reverse proxy audits. Paste your config, get the exact fix. No signup, nothing leaves your browser.
https://configclarity.dev

PackageFix — Paste your manifest, get a fixed version back. Live CVE scan via OSV + CISA KEV.
https://packagefix.dev

Both MIT licensed, open source, client-side only.

Running Ollama on a VPS or home server? What's your current setup for keeping the API locked down?

Running NemoClaw or OpenClaw locally? Audit your server before you give an AI agent the keys.

metriclogic26 — Mon, 16 Mar 2026 21:30:13 +0000

NVIDIA just announced NemoClaw at GTC 2026 today. If you're in the OpenClaw community, you're probably already thinking about running it locally on a dedicated machine.

Before you do — your server needs to be clean first.

An always-on AI agent with access to your files, tools, and network is only as secure as the infrastructure it runs on. Here's what to check before you hand over the keys.

1. Your Docker ports might be publicly exposed

NemoClaw and OpenClaw both run in Docker. The most common misconfiguration in any Docker setup is this:

ports: "11434:11434"

That binds to 0.0.0.0 — meaning your AI agent's inference port is accessible from the public internet, not just localhost. UFW won't catch it. Docker bypasses UFW entirely by inserting rules directly into iptables PREROUTING.

The fix:
ports: "127.0.0.1:11434:11434"

Check every port mapping in your compose file before NemoClaw goes live.

2. Your firewall has IPv4/IPv6 mismatches

You locked down IPv4. IPv6 is wide open. Same result — your agent's ports are reachable from outside.

Paste your ufw status verbose output and check for rules that only apply to one protocol.

3. Your cron jobs will collide with agent tasks

Always-on agents schedule their own tasks. If you already have cron jobs running backups,
updates, or maintenance — you need to know exactly when they fire.

Three jobs hitting the same minute = server load spike = agent timeout = failed task with no error.

Visualize your full cron timeline before adding agent workloads on top.

4. Your SSL certificates need monitoring

NemoClaw runs a local web interface. If you're proxying it through Nginx or Traefik with SSL — that cert will expire. Set up monitoring across all your domains now, not after the renewal window passes.

5. Your dependencies have CVEs you don't know about

Building on top of NemoClaw? Extending OpenClaw with custom skills? Your package.json or requirements.txt has vulnerabilities that ChatGPT can't tell you about — because the OSV database updates daily and AI training data is always stale.

Paste your manifest and get a live CVE scan against today's vulnerability database. CISA KEV flags actively exploited packages first.

The tools

All of the above checks are what I built for the MetricLogic network:

ConfigClarity — Docker, firewall, cron, SSL, reverse proxy audits. Paste your config, get the fix. No signup, nothing leavesyour browser.
https://configclarity.dev

PackageFix — Paste your manifest, get a fixed version back. Live CVE scan via OSV + CISA KEV. npm, PyPI, Ruby, PHP.
https://packagefix.dev

Both MIT licensed, open source, client-side only.

If you're building an always-on AI agent setup, run these before you go live. An agent with access to a misconfigured server is worse than no agent at all.

Building something with NemoClaw or OpenClaw?
Drop a comment — would love to know what stacks people are running this on.