GHSA-vjx8-8p7h-82gr: OpenClaw SSRF

CISO Take

openclaw's marketplace plugin installer follows HTTP redirects without SSRF controls, meaning any deployment that installs a crafted plugin archive can be coerced into issuing arbitrary HTTP requests to internal endpoints — including cloud metadata services (AWS IMDSv1, GCP, Azure IMDS), internal dashboards, or private APIs. For AI agent frameworks with broad filesystem and network access, SSRF is a direct stepping stone to credential theft and lateral movement, not just a theoretical network concern. Context amplifies the risk significantly here: openclaw already carries 37 known CVEs, and AIID incident #1368 documents active abuse of its plugin marketplace (ClawHub) to distribute credential-stealing malware via the same plugin distribution channel this SSRF inhabits. Patch to openclaw 2026.3.31 immediately; if upgrades are blocked, disable marketplace plugin installation and enforce egress firewall rules restricting access to RFC-1918 ranges and cloud metadata endpoints from the openclaw process.

Sources:GitHub AdvisoryATLASCISA KEV

What is the risk?

Rated medium by CVSS but contextually elevated for cloud-hosted AI agent deployments. The attack surface is the marketplace plugin download flow — a privileged operation in agentic systems that commonly run with elevated credentials and broad network access. With no EPSS data and no CISA KEV entry, automated exploitation at scale is not yet observed, but AIID #1368 confirms the openclaw marketplace is already under active abuse, materially increasing the probability this SSRF vector will be weaponized. The 37-CVE history for this package signals systemic security debt that warrants treating any new vulnerability as higher-risk than its CVSS score suggests.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	<= 2026.3.28	`2026.3.31`
3 dependents32% patched~5d to patchFull package profile →

Do you use OpenClaw? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

5 steps

Upgrade to openclaw >= 2026.3.31, which removes the bare redirect-following fetch in src/plugins/marketplace.ts.
If immediate upgrade is blocked, disable marketplace plugin installation or restrict it to an internal, vetted mirror.
Enforce egress firewall rules on openclaw hosts to block access to cloud metadata endpoints (169.254.169.254, fd00:ec2::254) and RFC-1918 ranges from the application process.
Audit all marketplace-installed plugins against trusted checksums — given AIID #1368, treat recently installed skills as suspect until verified.
Review host-level and WAF logs for anomalous outbound HTTP requests originating from the openclaw process during plugin install operations as an indicator of prior exploitation.

How is it classified?

Supply ChainData ExtractionAuth BypassAgentPluginAML.T0010.005- AI Agent Tool AML.T0049- Exploit Public-Facing Application AML.T0053- AI Agent Tool Invocation AML.T0083- Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.9.3-AI system risk management

NIST AI RMF

MANAGE-2.2-Mechanisms for tracking and addressing AI system vulnerabilities

OWASP LLM Top 10

LLM07:2023-Insecure Plugin Design

Frequently Asked Questions

What is GHSA-vjx8-8p7h-82gr?

openclaw's marketplace plugin installer follows HTTP redirects without SSRF controls, meaning any deployment that installs a crafted plugin archive can be coerced into issuing arbitrary HTTP requests to internal endpoints — including cloud metadata services (AWS IMDSv1, GCP, Azure IMDS), internal dashboards, or private APIs. For AI agent frameworks with broad filesystem and network access, SSRF is a direct stepping stone to credential theft and lateral movement, not just a theoretical network concern. Context amplifies the risk significantly here: openclaw already carries 37 known CVEs, and AIID incident #1368 documents active abuse of its plugin marketplace (ClawHub) to distribute credential-stealing malware via the same plugin distribution channel this SSRF inhabits. Patch to openclaw 2026.3.31 immediately; if upgrades are blocked, disable marketplace plugin installation and enforce egress firewall rules restricting access to RFC-1918 ranges and cloud metadata endpoints from the openclaw process.

Is GHSA-vjx8-8p7h-82gr actively exploited?

No confirmed active exploitation of GHSA-vjx8-8p7h-82gr has been reported, but organizations should still patch proactively.

How to fix GHSA-vjx8-8p7h-82gr?

1. Upgrade to openclaw >= 2026.3.31, which removes the bare redirect-following fetch in src/plugins/marketplace.ts. 2. If immediate upgrade is blocked, disable marketplace plugin installation or restrict it to an internal, vetted mirror. 3. Enforce egress firewall rules on openclaw hosts to block access to cloud metadata endpoints (169.254.169.254, fd00:ec2::254) and RFC-1918 ranges from the application process. 4. Audit all marketplace-installed plugins against trusted checksums — given AIID #1368, treat recently installed skills as suspect until verified. 5. Review host-level and WAF logs for anomalous outbound HTTP requests originating from the openclaw process during plugin install operations as an indicator of prior exploitation.

What systems are affected by GHSA-vjx8-8p7h-82gr?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, plugin ecosystems, cloud-hosted AI agents.

What is the CVSS score for GHSA-vjx8-8p7h-82gr?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksplugin ecosystemscloud-hosted AI agents

MITRE ATLAS Techniques

AML.T0010.005AI Agent Tool

AML.T0049Exploit Public-Facing Application

AML.T0053AI Agent Tool Invocation

AML.T0083Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.9.3

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM07:2023

What are the technical details?

Original Advisory

## Summary Marketplace Plugin Download Follows Redirects Without SSRF Protection ## Current Maintainer Triage - Status: open - Normalized severity: medium - Assessment: v2026.3.28 still uses bare redirect-following fetch in src/plugins/marketplace.ts for marketplace archives, and fixed-on-main only does not change that shipped SSRF exposure. ## Affected Packages / Versions - Package: `openclaw` (npm) - Latest published npm version: `2026.3.31` - Vulnerable version range: `<=2026.3.28` - Patched versions: `>= 2026.3.31` - First stable tag containing the fix: `v2026.3.31` ## Fix Commit(s) - `2ce44ca6a1302b166a128abbd78f72114f2f4f52` — 2026-03-31T12:59:42+01:00 ## Release Process Note - The fix is already present in released version `2026.3.31`. - This draft looks ready for final maintainer disposition or publication, not additional code-fix work. Thanks @AntAISecurityLab for reporting.

Exploitation Scenario

An attacker publishes a malicious plugin archive to ClawHub or compromises a legitimate package's distribution URL to serve a redirect to an internal target. When an openclaw administrator or an automated CI/CD pipeline installs the plugin, the unprotected fetcher in marketplace.ts follows the redirect without validation, issuing an HTTP GET to the attacker-chosen internal URL — for example, http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS. The response is returned into the plugin install context and potentially logged or processed, leaking IAM credentials. The attacker uses those credentials to pivot into the target's cloud environment. This attack chain is a direct extension of the AIID #1368 scenario where the same plugin channel was weaponized to deliver the AMOS credential stealer.

Weaknesses (CWE)

CWE-918Server-Side Request Forgery (SSRF)Primary

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.