GHSA-2xcp-x87w-q377: Incorrect Authorization Bypass via Templated Hook Mappings in OpenClaw

The OpenClaw framework incorporates a webhook gateway designed to route incoming requests to specific AI agents and active sessions. This routing behavior is governed by 'hook mappings' configured within the application. These mappings determine the target sessionKey for an incoming webhook, either by specifying a static string or by defining a dynamic template, such as {{payload.id}}, which resolves based on the incoming request data.

The framework implements a security gate named allowRequestSessionKey to prevent external requests from arbitrarily assigning themselves to existing sessions. By default, this configuration is set to false, ensuring that external callers cannot dictate session routing. The vulnerability, tracked as CWE-863 (Incorrect Authorization), exists because the gateway logic applies this security gate inconsistently.

Prior to version 2026.4.20, the gateway only enforced the allowRequestSessionKey policy when a session key was provided explicitly within the standard request payload structure. The system entirely bypassed this check when the session key was resolved indirectly through a hook mapping template. This permitted external webhook payloads to influence session routing despite the secure default configuration.

The flaw affects all installations of the openclaw NPM package prior to version 2026.4.20. Implementations relying on built-in routing presets, such as the Gmail integration which uses per-message routing templates by default, are particularly exposed. Administrators running these configurations are vulnerable to session hijacking unless explicit prefix restrictions were manually applied.

The core engineering flaw resides in the lack of origin tracking during the hook mapping resolution phase. The routing logic treated all configurations defined within hooks.mappings as internally trusted data structures. When the gateway processed an incoming webhook, it did not distinguish between a static session key hardcoded by the administrator and a dynamic session key populated by untrusted external input.

The templating engine renders dynamic expressions like {{payload.id}} by substituting the template variables with corresponding values extracted from the incoming HTTP request. Once the template rendering process completes, the system forwards the resulting sessionKey to the resolveHookSessionKey function. At this execution stage, the function receives a plain string without any metadata indicating how the string was constructed.

Within the resolveHookSessionKey function, the logic evaluated the authorization policy based on an inaccurate source categorization. Because the key originated from the hooks.mappings configuration object, the source was tagged generically as mapping. The authorization gate explicitly exempted the mapping source from the allowRequestSessionKey validation check, operating under the false assumption that all mapping values were statically defined by administrators.

This architectural oversight created a direct bypass of the intended security boundaries. Untrusted external input successfully mutated into a trusted internal routing directive. The resulting authorization failure permitted an attacker to inject data into any session key they could derive through the templated expression.

The remediation strategy, introduced in commit 5275d008ed33203dba3f98e969ad683a65c416c3, addresses the vulnerability by implementing explicit origin tracking for session keys. The patch modifies the mapping generation logic to analyze the template structure before rendering. This ensures the system retains the necessary context regarding the data's provenance.

In src/gateway/hooks-mapping.ts, the developer introduced a new tracking field named sessionKeySource. The updated buildActionFromMapping function now evaluates the raw mapping configuration using a new helper function, getSessionKeyTemplateSource. This function statically analyzes the configuration string to determine if it contains template syntax, returning templated if variable substitution is required, and static otherwise.

function buildActionFromMapping(mapping, ctx) {
  return {
    // ...
    sessionKey: renderOptional(mapping.sessionKey, ctx),
    sessionKeySource: getSessionKeyTemplateSource(mapping.sessionKey), // Origin tracking introduced
    // ...
  };
}

The most critical component of the patch resides in src/gateway/hooks.ts. The resolveHookSessionKey function incorporates the new origin tracking metadata into its authorization logic. The check now logically blocks session keys originating from either a direct request or a mapping-templated source unless the administrator explicitly sets the allowRequestSessionKey policy to true.

export function resolveHookSessionKey(params) {
  if (requested) {
    // The authorization gate now explicitly restricts templated mappings
    if (
      (params.source === "request" || params.source === "mapping-templated") && 
      !params.hooksConfig.sessionPolicy.allowRequestSessionKey
    ) {
      return { ok: false, error: "sessionKey is disabled for externally supplied hook payload values..." };
    }
    // ...
  }
}

Exploitation requires the attacker to identify an exposed OpenClaw webhook endpoint that relies on templated hook mappings. The attacker must also understand the expected JSON schema of the incoming webhook payload, specifically the fields referenced by the target's routing template. No authentication is necessary if the webhook endpoint is exposed publicly.

The attacker constructs a malicious JSON payload where the specific field referenced by the {{ ... }} template contains the identifier of a target session. For example, if the mapping template is defined as {{messages[0].id}}, the attacker crafts an HTTP POST request containing a messages array where the first object's id equals the victim's active session key.

Upon receiving the request, the OpenClaw gateway parses the payload and applies the hook mapping. The templating engine substitutes the malicious input into the sessionKey variable. Due to the lack of origin tracking, the resolveHookSessionKey function approves the routing directive. The gateway subsequently routes the attacker's payload into the victim's session.

The primary impact of this vulnerability is unauthorized session hijacking. By successfully routing malicious payloads to arbitrary session keys, an attacker can directly inject instructions, queries, or manipulated data into active AI sessions belonging to other users. This capability compromises the integrity of the AI assistant's interactions.

Information disclosure represents a critical secondary consequence. When an attacker forces a webhook payload into a targeted session, the OpenClaw framework processes the input within that specific context. The resulting AI responses, which may contain sensitive context from the victim's ongoing session, are processed as part of the hijacked interaction flow. Depending on the specific webhook implementation, this output may be returned or forwarded to an attacker-controlled endpoint.

The flaw entirely neutralizes the framework's primary defense-in-depth mechanism. The allowRequestSessionKey: false default configuration is designed to guarantee session isolation against untrusted external inputs. The failure of this control renders environments utilizing dynamic mappings inherently vulnerable, elevating the overall risk profile of the deployment.

The definitive remediation strategy is upgrading the openclaw NPM package to version 2026.4.20 or later. This release contains the updated origin tracking logic and strictly enforces the authorization gates for templated mappings. Administrators must verify the package version across all production deployments and continuous integration pipelines.

Following the upgrade, environments utilizing templated sessionKey mappings will experience a functional change. The gateway will actively reject incoming webhooks unless two specific configuration prerequisites are satisfied. Administrators must explicitly set hooks.allowRequestSessionKey to true and define strict routing boundaries within the hooks.allowedSessionKeyPrefixes array.

Organizations unable to immediately apply the patch must implement strict configuration workarounds. Administrators must remove all templated variable expressions ({{ ... }}) from hooks.mappings[].sessionKey configurations. Alternatively, if dynamic routing is strictly required, operators should block external access to the webhook gateway at the reverse proxy or network load balancer level until the software upgrade is complete.