CVE-2026-85621: LobeChat 2.2.1 Webhook Signature Verification Bypass QQ Feishu

Published Sep 4, 2026
·
Updated

LobeChat (LobeHub) 2.2.1 does not properly verify inbound chat-platform webhook signatures in the QQ and Feishu 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, and the Feishu adapter only performs an optional static-token comparison that is skipped when no token is configured (the default) and is not a body signature. An unauthenticated attacker who knows the public webhook URL can POST forged inbound messages with an attacker-chosen sender identity and arbitrary text, causing the bot owner's agent to process attacker-controlled input and treat the attacker as a trusted platform sender.

Affected Software

1 affected component
LobeChat (LobeHub)=2.2.1

Event History

Sep 4, 2026
CVE Published
via MITRE·02:32 PM
Data Sourced
via MITRE·02:32 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·03:17 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed?

Deployments using the QQ or Feishu inbound webhook adapters are exposed because the shared webhook route is unauthenticated and adapter-specific verification is inadequate. For Feishu, the static-token check is skipped when no token is configured, which is the default.

2

What does an attacker need to exploit this?

An attacker needs only the public webhook URL. They can send forged POST requests without authentication, choose a sender identity, and supply arbitrary message text.

3

What is the practical impact of a forged webhook?

The bot owner's agent processes attacker-controlled input as though it came from a trusted QQ or Feishu platform sender. This can expose or alter information handled by the agent, consistent with the listed low confidentiality and integrity impacts.

4

What can be done if patching is not immediately possible?

For Feishu, configuring a static token prevents the default token-skipping condition, but the token comparison is not a body-signature verification. Restricting access to the public webhook URL can reduce exposure, since knowledge of that URL is sufficient for exploitation.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203