Listen to this Post
The vulnerability resides in the Feishu webhook mode of OpenClaw versions up to 2026.3.11. Feishu, a popular collaboration suite, allows external services to receive real-time events via webhooks. For security, Feishu provides two methods to verify that incoming webhook requests are legitimate: a simple `verificationToken` and a more robust `encryptKey` for cryptographic signature validation . The flaw occurs when an administrator configures the webhook with only the weaker `verificationToken` and omits the encryptKey. In this misconfigured state, the OpenClaw endpoint fails to establish a proper cryptographic verification boundary . It relies solely on the static token, which, if known or guessed, is insufficient for proving the authenticity of the request origin. An unauthenticated attacker with network access to the vulnerable webhook endpoint can exploit this by crafting a forged Feishu event. Because the endpoint cannot cryptographically verify the sender, it accepts the fake event as legitimate. This allows the attacker to impersonate any Feishu sender, such as a specific user or system . The acceptance of this forged event can then trigger downstream actions or tool executions within the OpenClaw environment, subject to the local agent’s policies. The issue is resolved in version 2026.3.12, which mandates the configuration of `encryptKey` and rejects any requests with missing or invalid signatures before processing them .
dailycve form:
Platform: OpenClaw
Version: <= 2026.3.11
Vulnerability: Cryptographic verification bypass
Severity: High
date: 13 Mar 2026
Prediction: Already patched 2026.3.12
What Undercode Say:
Analytics:
This is a critical failure in the principle of defense in depth, where a weaker configuration option (verificationToken) could be used without the stronger, required cryptographic control (encryptKey). The vulnerability allows for complete impersonation of Feishu senders, making it highly dangerous for deployments relying on webhooks for automated actions. The attack vector is network-based with low complexity and requires no privileges or user interaction, as per the CVSS scoring pattern for similar flaws . The disclosure and patch timeline (March 13-14, 2026) shows a rapid response from the maintainers.
Commands/Codes:
Check your current OpenClaw version openclaw --version If version is 2026.3.11 or lower, update immediately First, stop the OpenClaw gateway openclaw gateway stop Update OpenClaw to the latest version (which includes 2026.3.12) npm update -g openclaw or if using a package manager like yarn yarn global upgrade openclaw After update, verify the new version openclaw --version Configuration fix: Ensure your Feishu channel configuration includes the encryptKey Locate your OpenClaw configuration file (often config.yaml or .env) Edit the file to include the 'encryptKey' obtained from your Feishu app settings Example snippet for a YAML config: channels: feishu: encryptKey: "your-actual-encrypt-key-here" verificationToken: "your-token" This alone is no longer sufficient After modifying the config, restart the gateway openclaw gateway restart To monitor logs for webhook errors related to signatures: openclaw logs --follow | grep -i "feishu|webhook|signature|encrypt"
How Exploit:
- Reconnaissance: Attacker identifies an OpenClaw instance (version <= 2026.3.11) with a publicly reachable Feishu webhook endpoint (e.g., `https://victim-openclaw.com/api/webhook/feishu`).
- Identify Weakness: The attacker probes the endpoint or determines through other means that the instance is configured with only a `verificationToken` and lacks the `encryptKey` .
- Craft Payload: The attacker constructs a malicious HTTP POST request that mimics a legitimate Feishu event. They include the correct `verificationToken` (if known or easily guessable) in the request body or headers as per Feishu’s legacy method . Crucially, they do not generate a valid cryptographic signature because the server isn’t configured to check for one.
- Send Request: The attacker sends this forged request to the vulnerable webhook endpoint.
- Bypass and Impact: The OpenClaw server, lacking the `encryptKey` verification, accepts the `verificationToken` as sufficient proof. It processes the forged event, which could instruct the AI agent to perform actions like reading internal files, making API calls, or executing other tools, effectively allowing the attacker to impersonate a trusted Feishu user .
Protection from this CVE:
- Immediate Patching: Upgrade OpenClaw to version `2026.3.12` or later immediately .
- Mandatory Strong Configuration: After upgrading, ensure that `encryptKey` is configured for all Feishu webhook deployments. The new version fails closed if this key is missing .
- Network Segmentation: Ensure that the OpenClaw webhook endpoint is not directly exposed to the public internet if possible. Use a reverse proxy or VPN to restrict access to trusted networks.
- Defense in Depth: Implement additional layers of security such as IP whitelisting for known Feishu server IP ranges (though these can change) and strict monitoring of webhook-triggered actions for anomalous behavior.
- Regular Audits: Periodically review OpenClaw configurations to ensure all security-related fields (
encryptKey,appSecret, etc.) are properly set and no weak configurations are in place .
Impact:
A successful exploit allows an unauthenticated network attacker to inject forged Feishu events, effectively impersonating any Feishu sender. This can lead to unauthorized triggering of downstream tools and automated tasks managed by the OpenClaw agent. Depending on the local agent’s policy, this could range from benign actions to severe outcomes like data exfiltration, unauthorized system commands, or further network penetration . The integrity of the AI agent’s operations is completely compromised, as it cannot distinguish between a legitimate command from a trusted user and a malicious command from an attacker.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
