GHSA-GCJ7-R3HG-M7W6: Webhook Replay Vulnerability via Unsigned Idempotency Headers in OpenClaw

The openclaw npm package provides infrastructure for building AI-driven voice agents, integrating with telephony providers like Twilio, Plivo, and Telnyx. A core component of this system is the webhook handler, which receives asynchronous events (e.g., call progress, speech results) from these providers. To prevent processing the same event multiple times—a common occurrence in distributed systems—the handler implements deduplication logic.

In versions prior to 2026.2.26, the Twilio provider implementation relied on the i-twilio-idempotency-token HTTP header to generate a unique identity for each request. While the system correctly verified the authenticity of the request body and URL using the X-Twilio-Signature mechanism, it failed to extend this trust boundary to the deduplication logic. The idempotency header is not included in the signed payload from Twilio. Consequently, the mechanism used to identify uniqueness was decoupled from the mechanism used to verify authenticity, creating a race condition in the security logic where a replayed request could be both 'validly signed' (unchanged body/URL) and 'unique' (changed idempotency token).

The vulnerability belongs to the class of Authentication Bypass by Capture-replay (CWE-294) and Insufficient Verification of Data Authenticity (CWE-345). The root cause lies in the createTwilioRequestDedupeKey function, which blindly trusts an unsigned input for critical logic.

Twilio's security model uses an HMAC-SHA1 signature (X-Twilio-Signature) constructed from the request URL and the sorted POST parameters. It does not sign arbitrary custom headers. The OpenClaw implementation, however, checked for the presence of the i-twilio-idempotency-token header and, if present, used it as the primary key for deduplication. This creates a logical flaw: the signature verifies that the content hasn't changed, but the application uses a mutable, unverified field to decide if the request has been seen before.

Because the signature validation routine ignores the idempotency header, an attacker can modify this header without invalidating the signature. The application then receives the request, verifies the signature (successfully), and checks the deduplication cache. Since the attacker supplied a novel idempotency token, the cache lookup fails (indicating a 'new' event), and the application proceeds to execute the associated business logic.

The vulnerability is evident in the comparison between the vulnerable key generation logic and the patched implementation. The vulnerable code explicitly prioritized the unsigned header.

Vulnerable Code (Before Fix):

function createTwilioRequestDedupeKey(ctx: WebhookContext): string {
  // VULNERABILITY: This header is not signed by Twilio.
  // An attacker can change this value to bypass deduplication.
  const idempotencyToken = getHeader(ctx.headers, "i-twilio-idempotency-token");
  if (idempotencyToken) {
    return `twilio:idempotency:${idempotencyToken}`;
  }
  // Fallback to body hash if token is missing
  return `twilio:body:${hash(ctx.body)}`;
}

Patched Code (Version 2026.2.26):

In the patched version, the deduplication key is derived directly from the material that was cryptographically verified. The verifiedRequestKey is computed during the signature verification phase and passed down to the handler.

// In the verification flow:
const verifiedRequestKey = `twilio:req:${sha256Hex(`${verificationUrl}\n${canonicalParams}\n${signature}`)}`;
 
// In the deduplication flow:
function createTwilioRequestDedupeKey(ctx: WebhookContext): string {
  // FIX: Use the key derived from the signed verification material.
  if (ctx.verifiedRequestKey) {
    return ctx.verifiedRequestKey;
  }
  // ...
}

This change ensures that the identity of the request is mathematically bound to the signature. To change the deduplication key, an attacker would have to change the signed parameters or the signature itself, which would cause verification to fail.

Exploiting this vulnerability requires an attacker to intercept a legitimate webhook request sent by Twilio to the OpenClaw instance. This could be achieved via Man-in-the-Middle (MitM) attacks if TLS is not enforced or compromised, or via access to server logs where headers might be recorded.

Attack Scenario:

1. Interception: The attacker captures a POST request to the /webhooks/twilio endpoint. The request contains a valid X-Twilio-Signature and a payload (e.g., SpeechResult=Unlock+the+door).
2. Modification: The attacker retains the exact URL and body parameters to ensure the signature remains valid. They modify the i-twilio-idempotency-token header to a random string (e.g., attacker-replay-001).
3. Replay: The attacker sends the modified request to the target server.
4. Execution: The server validates the signature against the body (success). It then checks the deduplication cache for twilio:idempotency:attacker-replay-001. Finding no match, it processes the request again, re-executing the "Unlock the door" command.

This attack can be automated to loop rapidly, causing significant disruption or resource consumption.

The impact of this vulnerability ranges from financial damage to operational disruption, depending on the functionality of the voice agent.

• Financial Impact: OpenClaw agents often trigger LLM (Large Language Model) processing or Text-to-Speech (TTS) generation. A replay loop can force the victim to incur massive API costs from providers like OpenAI or ElevenLabs by processing the same input thousands of times.
• Integrity Violation: If the webhook triggers state-changing actions (e.g., database updates, initiating transfers, unlocking smart locks), these actions can be duplicated. This compromises the integrity of the application state.
• Availability: High-volume replay attacks can saturate the Node.js event loop or exhaust database connections, leading to a Denial of Service (DoS) for legitimate calls.

CVSS Vector Assessment: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L (Approx 8.2). The attack is network-based, requires no privileges or user interaction, and has a high impact on integrity.

The vulnerability is patched in openclaw version 2026.2.26. The fix involves strictly binding internal identifiers to cryptographically verified data.

Mitigation Steps:

1. Update Package: Upgrade the openclaw dependency to version 2026.2.26 or later immediately.

   npm update openclaw

2. Audit Logs: Review webhook logs for duplicate CallSid or MessageSid entries processed with different idempotency tokens to identify past exploitation attempts.
3. Rotate Secrets: If you suspect your webhook endpoints were monitored, rotate your Twilio Auth Token and update the webhook URLs to ensure previous signatures cannot be reused if the signing key is changed (though standard Twilio signatures are based on the Auth Token, so rotation invalidates old signatures).