GHSA-7jm2-g593-4qrc: Unauthorized Configuration Mutation in OpenClaw Agent Gateway

The OpenClaw platform provides an agent gateway that functions as an operational interface for large language model-driven agents. This gateway exposes a suite of management tools to the agents, enabling dynamic configuration modifications during runtime. Because these agents process untrusted external data, they operate as untrusted principals within the architecture. The platform employs a dedicated configuration mutation guard to enforce strict boundaries on agent capabilities.

This guard mechanism, implemented as assertGatewayConfigMutationAllowed, systematically evaluates requested changes against a predefined security policy. The vulnerability arises from critical deficiencies within this validation logic, specifically an incomplete denylist and shallow recursive inspection. These flaws map directly to CWE-285 (Improper Authorization) and CWE-184 (Incomplete List of Disallowed Elements). The failure of this authorization control allows agents to directly modify operator-trusted configurations.

The consequences of this authorization bypass directly compromise the foundational security model of the OpenClaw platform. Agents exploit this weakness to alter their own runtime constraints, bypassing isolation mechanisms intended to prevent malicious actions. The downstream impacts include execution sandbox escapes, Server-Side Request Forgery (SSRF) policy violations, and unauthorized plugin modifications.

The assertGatewayConfigMutationAllowed function acts as the primary authorization boundary for configuration changes requested via the gateway tool. The original design relied on a static string array named PROTECTED_GATEWAY_CONFIG_PATHS. This array functioned as a denylist, specifying discrete configuration keys that the agent was prohibited from modifying.

The first critical flaw stems from the incomplete nature of this denylist. The list lacked definitions for highly sensitive systemic settings, leaving critical components exposed to agent manipulation. Key omissions included the browser.ssrfPolicy configuration, which governs network access, and the mcp.servers configuration, which defines external Model Context Protocol endpoints.

The second, more structural flaw involves the validation logic applied to deeply nested JSON properties. When evaluating patches applied to arrays, such as the agents.list[] property, the function only evaluated the top-level key against the denylist. It did not recursively apply the path validation rules to properties nested inside the array objects.

This shallow validation created a reliable bypass mechanism when modifying existing array structures. An agent invoking the config.patch or config.apply method could supply an object containing sensitive keys, provided those keys were nested within an unprotected top-level array. The logic approved the transaction based on the parent object, completely ignoring the malicious payload injected into the child properties.

Prior to the patch, the configuration guard lacked the structural awareness necessary to inspect array mutations. The static denylist only contained string literals mapped to top-level object keys. The absence of wildcard matching or recursive object traversal meant that paths containing array indices systematically evaded the string-matching logic.

The remediation implemented in commit fe30b31a97a917ecc6e92f6c85378b6b20352422 introduces a comprehensive overhaul of the path resolution mechanism. The developers expanded the PROTECTED_GATEWAY_CONFIG_PATHS array to include sensitive subsystems. More importantly, they introduced a syntactic wildcard [] to explicitly define protected schemas within array elements.

// Added protected paths in commit fe30b31a97a917ecc6e92f6c85378b6b20352422
"agents.defaults.sandbox",
"agents.list[].sandbox",
"agents.list[].tools",
"agents.list[].embeddedPi",
"tools.fs",
"plugins.entries",
"gateway.auth",
"gateway.tls",
"browser.ssrfPolicy",
"mcp.servers"

To enforce these new path definitions, the patch introduces the isProtectedPathEqual function. This function provides the necessary recursive traversal to match nested payload keys against the wildcard definitions. Additionally, the developers implemented readProjectedEntries to perform identity-aware tracking of array elements. This specific change prevents attackers from exploiting the config.apply method by replacing or reordering entries to obfuscate protected configuration overrides.

The exploitation sequence requires an initial vector to influence the AI agent's decision-making process. Attackers typically achieve this through prompt injection, supplying crafted input via an untrusted data source that the agent is designed to process. This input coerces the agent into utilizing its gateway tool capabilities maliciously.

Once compromised, the agent constructs a JSON payload targeting the config.patch method. The payload leverages the shallow validation flaw by nesting the prohibited configuration change within the agents.list array. The attacker targets specific fields that control the operational boundaries of the agent environment.

{
  "agents": {
    "list": [{ "id": "any-agent-id", "sandbox": { "mode": "off" } }]
  }
}

The configuration guard evaluates the payload, observes that the top-level agents key is not strictly protected against all modifications, and permits the patch. It fails to identify the protected sandbox key embedded within the array element. The system applies the configuration, successfully disabling the execution sandbox for the specified agent.

The impact of this authorization bypass extends across the entire OpenClaw deployment architecture. By manipulating the configuration state, an attacker systematically dismantles the security boundaries designed to constrain the AI agent. The most severe consequence is the circumvention of the execution sandbox.

With the sandbox.mode set to "off", the agent gains the capability to execute arbitrary code directly on the host operating system. The process inherits the system privileges of the OpenClaw service application. This arbitrary code execution allows the attacker to establish persistence, access local file systems, and execute operating system commands.

Beyond local execution, the vulnerability facilitates internal network compromise. The attacker can modify the browser.ssrfPolicy to set dangerouslyAllowPrivateNetwork: true. This specific configuration change neutralizes the Server-Side Request Forgery (SSRF) protections, enabling the agent to scan internal subnets, interact with internal APIs, and exfiltrate sensitive data from protected network segments.

Additionally, the capability to modify the mcp.servers and plugins.entries configurations allows for long-term environment manipulation. Attackers inject malicious Model Context Protocol servers to establish covert command and control channels. The activation of disabled or unverified plugins further broadens the attack surface, introducing secondary vulnerabilities into the application stack.

Organizations deploying the OpenClaw agent gateway must upgrade the application to version 2026.4.20 immediately. This version includes the complete remediation logic introduced in commit fe30b31a97a917ecc6e92f6c85378b6b20352422. The fix comprehensively addresses both the incomplete denylist and the shallow array validation vulnerabilities.

The implemented solution represents a complete fix for this specific bug class within the configuration mutation guard. The introduction of identity-aware tracking via readProjectedEntries eliminates secondary bypass vectors related to array element reordering. The hardened config.apply logic strictly enforces the presence of operator-set protected subfields, preventing deletion-based bypasses.

Administrators must implement proactive monitoring to detect historical or ongoing exploitation attempts. Security teams should analyze application logs for specific invocation patterns associated with the gateway tool. Log entries detailing config.patch or config.apply operations that target the agents.list array warrant immediate technical review.

If immediate patching is technically infeasible, organizations must restrict the agent's access to the gateway tool entirely. This functional reduction prevents the agent from modifying system configurations, neutralizing the vulnerability at the cost of operational flexibility. This should be considered a temporary mitigation until the software update can be fully deployed.