CVE-2026-28454 is an authentication flaw in OpenClaw's Telegram webhook mode. Without a configured webhook secret, the endpoint accepts unauthenticated posts and trusts the sender identity in the payload. NVD scores it 7.5. Upgrade openclaw to 2026.2.2 or later and set a strong webhook secret.
What's affected
NVD's description says versions before 2026.2.2 are affected, and the GitHub advisory GHSA-fhvm-j76f-qmjv gives patched versions 2026.2.2 and later in its header. The advisory's body uses slightly different numbers, listing 2026.1.30 and 2026.2.1 in places, so use 2026.2.2 as the target to cover every reading.
The condition is that Telegram webhook mode is enabled without a configured webhook secret. Deployments that use Telegram polling, or that set a secret, are outside the condition.
The advisory rates it High, and NVD scores it 7.5 for integrity impact. The weakness is CWE-345 (Insufficient Verification of Data Authenticity).
How to check if you're exposed
Check the OpenClaw version in each project and global install.
npm ls openclaw
npm ls -g openclaw
Then read your Telegram configuration. If you use webhook mode, check that channels.telegram.webhookSecret is set to a strong value, and that your reverse proxy forwards the X-Telegram-Bot-Api-Secret-Token header unchanged. If the secret is missing, you are in the vulnerable setup.
What to do now
- Upgrade openclaw to 2026.2.2 or later.
- Set a strong channels.telegram.webhookSecret and make sure your reverse proxy passes the X-Telegram-Bot-Api-Secret-Token header through unchanged, as the advisory advises.
- Keep the webhook listener on loopback behind a reverse proxy where possible. The fixed versions default to a loopback bind.
- Review which commands and tools an allowlisted Telegram sender can run, and reduce them.
- Review bot logs for commands that came from sender IDs which did not originate in real Telegram traffic.
Why it matters
A webhook is a public URL that another service calls. Anyone who can reach the URL can also call it, so the receiver must check that the call truly came from the expected service. Telegram supports a secret token for this, sent in a header, and the receiver compares it.
Without the check, the receiver reads the sender and chat identifiers from the JSON body and believes them. Those are values the caller chose. An allowlist based on them is then only a list of numbers the attacker can write.
The fixes the advisory lists go beyond the one setting. Configuration validation now requires a secret whenever a webhook URL is set, the webhook listener defaults to loopback, request bodies are bounded in size and time, and a runtime guard refuses to start without a secret. Several small layers together close the gap.
The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog.
Quick check
What is the single most important setting?
A strong channels.telegram.webhookSecret, with your reverse proxy forwarding the X-Telegram-Bot-Api-Secret-Token header unchanged.
Why are the advisory version numbers confusing?
The advisory header and body list slightly different version boundaries. Upgrading to 2026.2.2 or later covers all of them.
Sources
Last reviewed: 19 October 2026.
