OpenClaw, an npm package for handling Telnyx webhooks, shipped a replay protection flaw in versions up to 2026.3.28. Attackers could bypass duplicate detection by re-encoding the signature from Base64 to Base64URL format. The maintainers fixed it in 2026.3.31 via commit ad77666054651c1fd77b1dc60fd6a8db6600a29a, released on March 30, 2026. Severity rates low and narrow—signature verification still blocked fakes, but replays slipped through.
The Technical Breakdown
Telnyx webhooks include a cryptographic signature in the Telnyx-Signature header to prove authenticity. OpenClaw verifies this signature and tracks seen requests via a hash of the signature for replay protection. The bug: the replay hash used the raw signature string without normalizing encoding.
Base64 encodes binary data with A-Z, a-z, 0-9, +, /, and = padding. Base64URL swaps + for -, / for _, and drops padding. The same binary signature decodes identically from either, so verification passes. But the strings differ, producing unique hashes in OpenClaw’s replay store up to v2026.3.28.
An attacker captures a legit webhook, re-encodes its signature to Base64URL, and resends. OpenClaw sees a “new” hash, processes the duplicate, and only later verifies the signature correctly. Reported by @AntAISecurityLab, the fix normalizes encodings before hashing.
Real-World Impact
This matters most for apps relying on OpenClaw for Telnyx integrations—think VoIP, SMS, or real-time comms in fintech or crypto platforms. Telnyx powers programmable voice and messaging; webhooks deliver events like call completions or message deliveries.
Replay attacks duplicate actions. In trading bots, a replayed payment confirmation triggers double buys. In crypto exchanges, it could fake deposit alerts, leading to erroneous withdrawals. Finance apps using Telnyx for 2FA SMS face risks of repeated authentications confusing session logic.
Low severity holds because it requires webhook access (network-level), signature knowledge (interception), and non-idempotent handlers. Most serious apps make webhook processing idempotent via UUIDs or timestamps. Still, narrow doesn’t mean zero: 2023 saw webhook replay exploits cost firms millions in duplicate payouts. OpenClaw’s 1,200+ weekly npm downloads amplify exposure.
Skeptically, Telnyx’s own docs recommend custom replay checks with timestamps or nonces alongside signatures. Leaning solely on a library’s hash invites these encoding gotchas. Base64 mishaps recur—remember 2022’s JWT libs normalizing URL-safe padding sloppily.
Check your stack: npm ls openclaw reveals versions. If <=2026.3.28, update now. Vuln scanners like Snyk or Socket flagged it post-patch.
$ npm update openclaw
$ npm ls openclaw
openclaw@2026.3.31
Beyond OpenClaw, audit webhook handlers. Always decode signatures before hashing or comparing. Use crypto primitives directly:
const signature = req.headers['telnyx-signature'];
const normalizedSig = Buffer.from(signature, 'base64url').toString('base64'); // or vice versa
const replayHash = crypto.createHash('sha256').update(normalizedSig).digest('hex');
This ensures Base64/Base64URL equivalence.
Lessons for Security Teams
Maintainers triaged fast—draft advisory ready pre-publication, crediting the finder. Props for transparency; npm’s 2026 versioning (year.month.day) aids pinpointing fixes.
Why this underscores basics: Security code must handle input variants. In crypto/finance, where webhooks drive $ trillions in daily volume, replays aren’t academic. Firms like Stripe and Twilio harden against them with multi-layered checks: sig verify + nonce + idempotency keys.
Adopt similar: Implement app-level dedup with Redis-stored event IDs, expiring in hours. Test fuzzing encodings—tools like Burp Suite replay payloads effortlessly. For Telnyx users, monitor X-Telnyx-Timestamp drift exceeding 5 minutes, per their spec.
Bottom line: Patch immediately if affected. Broader audit reveals if your webhook logic assumes clean inputs. In high-stakes ops, don’t outsource replay protection to one lib—layer defenses.
