CVE-2026-85621: LobeChat Webhook Authentication Bypass

CVE-2026-85621 Overview

CVE-2026-85621 affects LobeChat (LobeHub) version 2.2.1 and stems from missing inbound webhook signature verification in the QQ and Feishu chat-platform adapters. The webhook route /api/agent/webhooks/:platform is unauthenticated by design and delegates verification to each adapter. The QQ adapter performs no Ed25519 signature verification on dispatched message events. The Feishu adapter only performs an optional static-token check that is skipped when no token is configured, which is the default. An unauthenticated attacker who knows the public webhook URL can POST forged inbound messages with an attacker-chosen sender identity and arbitrary content, causing the bot owner's agent to process attacker-controlled input as a trusted platform sender. The weakness is classified under [CWE-345] (Insufficient Verification of Data Authenticity).

Critical Impact
Unauthenticated remote attackers can inject forged chat messages that impersonate trusted QQ or Feishu senders, causing the agent to process attacker-controlled input.

Affected Products

LobeChat (LobeHub) 2.2.1
LobeHub chat-adapter-qq package
LobeHub chat-adapter-feishu package

Discovery Timeline

2026-09-04 - CVE-2026-85621 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-85621

Vulnerability Analysis

The vulnerability resides in the LobeHub chat-platform adapter pipeline. LobeChat exposes a public webhook endpoint at /api/agent/webhooks/:platform that is intentionally unauthenticated, because chat platforms such as QQ and Feishu dispatch events from arbitrary source IPs. The design relies on each adapter to cryptographically validate the request body against a platform-provided secret. In version 2.2.1, that validation is missing or ineffective for two adapters.

The chat-adapter-qq adapter processes dispatched message events without invoking Ed25519 signature verification against the payload. The chat-adapter-feishu adapter compares an optional static token, but the comparison is skipped when the operator has not configured a token, which is the default deployment state. A static token check is also not a body signature, so it cannot bind the payload to the sender even when configured.

Because the agent trusts the parsed sender field, forged input flows directly into downstream LLM prompts, tool calls, and conversation history.

Root Cause

The root cause is insufficient verification of data authenticity in adapter code. The QQ adapter omits Ed25519 verification entirely, and the Feishu adapter conflates an optional shared-secret token with a request signature. Neither adapter binds inbound payloads to the platform's signing key.

Attack Vector

An attacker with knowledge of the public webhook URL sends a crafted HTTP POST to /api/agent/webhooks/qq or /api/agent/webhooks/feishu. The request body contains an attacker-chosen sender identifier and message text formatted to match the platform's event schema. The adapter accepts the payload without signature validation and dispatches it to the bot owner's agent as a legitimate inbound message. See the VulnCheck Advisory on LobeChat and GitHub Issue #16538 for adapter code paths.

Detection Methods for CVE-2026-85621

Indicators of Compromise

POST requests to /api/agent/webhooks/qq or /api/agent/webhooks/feishu originating from IP addresses outside the documented QQ Open Platform or Feishu Open Platform egress ranges.
Webhook payloads carrying sender identifiers that do not correspond to users known in the bot's tenant or group membership.
Agent conversation logs showing inbound messages without corresponding delivery records in QQ or Feishu platform consoles.

Detection Strategies

Enable request logging on the LobeChat reverse proxy and alert on webhook requests missing the platform-specific signature headers such as X-Lark-Signature or the QQ X-Signature-Ed25519 header.
Correlate agent-processed inbound messages with platform-side event delivery telemetry to identify messages that never traversed the vendor's platform.
Baseline the source IP set for /api/agent/webhooks/:platform traffic and flag deviations.

Monitoring Recommendations

Ingest LobeChat application logs and reverse-proxy access logs into a centralized data store for retrospective analysis.
Alert on repeated POSTs to the webhook endpoint from a single unfamiliar source, which may indicate scripted abuse.
Track outbound agent actions, tool invocations, and API calls triggered by suspicious inbound webhook events.

How to Mitigate CVE-2026-85621

Immediate Actions Required

Restrict inbound access to /api/agent/webhooks/qq and /api/agent/webhooks/feishu at the network layer to the published QQ Open Platform and Feishu Open Platform source ranges.
Disable the QQ and Feishu adapters in LobeChat deployments where these integrations are not required.
Audit recent agent conversation history for inbound messages that lack corresponding platform-side delivery records.

Patch Information

At the time of publication, review the GitHub Lobehub Repository and GitHub Issue #16538 for the current status of upstream fixes. Adapter source is available for review in chat-adapter-qq and chat-adapter-feishu. Upgrade to a release that implements Ed25519 signature verification for QQ and HMAC body-signature verification for Feishu once available.

Workarounds

Place the LobeChat instance behind a reverse proxy that terminates TLS and enforces platform-signature header presence before forwarding requests.
For Feishu, configure the optional verification token in adapter settings and require its presence, understanding that this does not replace a body signature.
Deploy the agent on a private network and expose only the webhook path through an allowlisted ingress rule.

bash

# Example nginx allowlist for the LobeChat webhook path
location /api/agent/webhooks/ {
    allow 203.0.113.0/24;   # replace with platform egress range
    deny all;
    proxy_pass http://lobechat_upstream;
}