cc-connect bridges messaging services to local AI coding assistants. Its MAX adapter accepted incoming webhook updates without authenticating the sender when webhook_secret was not configured, according to a newly published advisory. A network-reachable caller could supply a user_id matching an allowed administrator, and the bridge could consequently…
Inspect the ClaimsCase · DiggingBeagle record
An unsigned cc-connect MAX webhook could impersonate a privileged chat operator
CVE-2026-108549 describes missing verification for MAX webhook messages when a webhook secret is unset, potentially letting a remote sender request host commands under a forged admin identity.
Scope
cc-connect MAX webhook adapter in deployments with webhook_secret unset and attacker reachability to the webhook listener; advisory refers to releases through 1.5.0.
Assessment profile
Assessment method- Exploitation
- not established
- Evidence
- Grade B
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
A public GHSA identifies missing signature verification when webhook_secret is absent and the possible forged admin user_id. Network exposure and successful exploitation on a real installation are not established. No verified fixed release is listed.
Assessed Oct 11, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-CC-NO-SECRET · CLM-CC-ADMIN-IMPERSONATION · CLM-CC-PATCH-UNKNOWN · GitHub Advisory GHSA-h8j8-r6g6-37hc: cc-connect webhook authentication
At a glance
Reject unsigned MAX updates before evaluating user_id, enforce the allowed-user policy after signature validation, and limit listener reachability. A secret configured in another messaging adapter does not secure this MAX webhook; prompt filtering is downstream of the already spoofed administrative identity.
Read the implicationsExactly which cc-connect builds enforce signature validation and whether a default-safe patch is shipped. How many installations leave webhook_secret unset while exposing the MAX listener to untrusted networks. No confirmed live exploitation or observed host-command execution beyond advisory-described capability.
Limits and uncertaintyFull account
cc-connect bridges messaging services to local AI coding assistants. Its MAX adapter accepted incoming webhook updates without authenticating the sender when webhook_secret was not configured, according to a newly published advisory. A network-reachable caller could supply a user_id matching an allowed administrator, and the bridge could consequently execute functions such as /shell on the developer workstation. The model need not be deceived: the trust error sits at the incoming event identity and permission check. The advisory says versions through 1.5.0 are implicated but its machine-readable affected and patched version tables are still unknown. This is a disclosed vulnerable configuration, not documented exploitation in the wild.
Mechanism and trust boundary
- 01
Forged incoming update
Remote sender reaches MAX webhook without a configured signature-verification secret.
Boundary: Unauthenticated HTTP request to claimed chat identity
- 02
Local privilege
Forged admin user_id is interpreted as permission to execute privileged host functions.
Boundary: Unverified chat identity to local developer tool authority
Claims & evidence
CLM-CC-NO-SECRETThe published GHSA states that cc-connect MAX webhook mode accepts unauthenticated updates when webhook_secret is not configured.supported
Basis: reported finding
- supportsGitHub Advisory GHSA-h8j8-r6g6-37hc: cc-connect webhook authenticationsecondary reporting
Description, platform/max/max.go and no webhook_secret condition
CLM-CC-PATCH-UNKNOWNThe October 10 GitHub Advisory lists unknown affected and patched version tables, although its prose names versions through 1.5.0.supported
Basis: reported finding
- supportsGitHub Advisory GHSA-h8j8-r6g6-37hc: cc-connect webhook authenticationsecondary reporting
Affected versions; Patched versions; Description
CLM-CC-ADMIN-IMPERSONATIONThe same GHSA reports that a network-reachable sender can forge an allowed or administrator user_id to invoke privileged commands such as /shell on the host.supported
Basis: reported finding
- supportsGitHub Advisory GHSA-h8j8-r6g6-37hc: cc-connect webhook authenticationsecondary reporting
Description, forged allowed or admin user_id
Implications
Reject unsigned MAX updates before evaluating user_id, enforce the allowed-user policy after signature validation, and limit listener reachability. A secret configured in another messaging adapter does not secure this MAX webhook; prompt filtering is downstream of the already spoofed administrative identity.
Unknowns and contradictions
- Exactly which cc-connect builds enforce signature validation and whether a default-safe patch is shipped.
- How many installations leave webhook_secret unset while exposing the MAX listener to untrusted networks.
- No confirmed live exploitation or observed host-command execution beyond advisory-described capability.
Sources and citation
Material revision history
- Oct 11, 2026 · Published version · first publication · revision 123