OpenClaw, an npm package for managing AI workflows with plugin marketplaces and Ollama integration, exposes servers to server-side request forgery (SSRF) attacks in versions up to 2026.3.28. Attackers can trick the software into fetching arbitrary URLs during marketplace plugin downloads and Ollama model discovery. The maintainers patched this in version 2026.3.31 via commit 8deb9522f3d2680820588b190adb4a2a52f3670b on March 30, 2026. Users running vulnerable versions on exposed endpoints face immediate risk—update now.
Vulnerability Breakdown
The core issue stems from unguarded fetch() calls. In the marketplace plugin download feature, OpenClaw pulls archives directly from user-supplied URLs without validation. This lets attackers point the server at internal networks, cloud metadata endpoints like 169.254.169.254, or even localhost services. SSRF here isn’t theoretical: it mirrors flaws in tools like Node-RED or serverless functions where fetch lacks URL whitelisting or DNS rebinding protections.
The second vector hits Ollama model discovery. OpenClaw queries model lists from remote endpoints without checks, again via raw fetch(). Ollama, a popular local LLM runner, often pairs with such tools for agentic workflows. While maintainers narrowed this out of their triage—calling it “operator-configured” with a weaker trust model—it still overlaps with the marketplace flaw. An operator might configure trusted sources, but default or misconfigured setups leave doors open.
Affected range covers all versions <=2026.3.28, with the latest vulnerable publish at that tag. Patched releases start at 2026.3.31. OpenClaw credits @tdjackey for the report, showing a responsive maintainer despite the odd versioning scheme—likely year.month.day format pointing to a 2026 release cycle.
Maintainer Triage and Fix
Maintainers rate this “narrow” scope at medium normalized severity. They retain the marketplace archive-fetch SSRF in assessment but exclude Ollama discovery as duplicate or lower-risk under operator control. Fair call: SSRF severity hinges on network exposure. Blind SSRF scores low (CVSS ~5.3), but with port scanning or internal pivots, it climbs to high (7+). No public CVSS here, but medium aligns if assuming containerized deploys.
The fix commit clamps down fetch() with URL validation—likely regex or allowlists. Developers should audit similar patterns: Node’s node-fetch or browser APIs default to open, inviting abuse. Post-patch, test with tools like
curl -X POST http://target/openclaw/marketplace/download?url=http://169.254.169.254/latest/meta-data/to confirm blocks.
Why This Matters: Real-World Risks
SSRF tops exploitation charts—think Capital One’s 2019 breach via misconfigured SSRF leaking 100 million records. In OpenClaw’s case, implications depend on deployment. Self-hosted AI servers often sit behind proxies, but exposed plugin marketplaces invite abuse. Attackers probe for:
- Cloud metadata (AWS IMDSv1, GCP equivalents) for credentials.
- Internal APIs, databases, or Redis instances.
- DoS via slowloris-style fetches to high-latency hosts.
- Exfil via DNS queries if fetch resolves attacker domains.
For crypto or finance users—OpenClaw’s plugin ecosystem might pull trading bots or LLM agents—SSRF could leak API keys or wallet states. Skeptically, maintainers downplay Ollama, but overlap means partial fixes risk blind spots. Broader context: npm’s 2 million packages see 1,000+ vulns yearly; this one’s narrow but highlights fetch hygiene in AI tools exploding post-ChatGPT.
Action items: Pin "openclaw": "^2026.3.31" in package.json. Scan deps with npm audit or Snyk. If custom forks, cherry-pick the commit. Monitor logs for anomalous fetches. In security terms, SSRF remains evergreen—block it at the WAF with URL deny-lists if patching lags.
Bottom line: Medium severity understates potential if your setup exposes internals. Patch delivers, but verify. OpenClaw’s niche in AI orchestration grows; expect more eyes on such flaws.
