A critical vulnerability in MAX webhook allows a remote attacker to forge an incoming message and impersonate an authorized user. The vulnerability affects installations that have enabled the webhook feature without an authentication secret, exposing the receiver to the internet. CVE-2026-108549 is rated 9.2/10 by CVSS 4.0 (VulnCheck bulletin).
cc-connect is open source software that connects local programming assistants, such as Claude Code, Cursor, Gemini CLI, and Codex, to messaging applications. This allows a server that receives messages from MAX to forward them to the assistant configured by the administrator (project page).
The VulnCheck bulletin, published on October 10, 2026, classifies cc-connect versions up to 1.5.0 as vulnerable and characterizes the vulnerability as critical. The rating of 9.2/10 refers to the consequences that a successful attack in this scenario could have. It does not mean that every installation is at risk: specific settings and access to the receiver are required (technical details of the vulnerability).
How the MAX webhook vulnerability works
MAX webhook is the web event receiver that forwards messages to cc-connect. The vulnerability occurs when a webhook address is specified, but the webhook_secret. Additionally, the receiver must be accessible to the potential attacker, either directly or through a proxy, as described in the security bulletin.
In the 1.5.0 code, the secret check is only performed when it is set. If the setting is empty, the function that accepts webhook requests accepts them without this confirmation (related code). The report describes how an attacker can send a message with an arbitrary sender ID.
cc-connect uses the sender ID to enforce the allow_from and admin_from. A spoofed message can be mistaken for coming from an authorized account and trigger commands that are allowed on that account, according to the researcher's report.
The VulnCheck bulletin also mentions the possibility of using the /shell, if it is available in the account being spoofed. The real risk is not a simple spam message: it concerns the commands that a programming assistant can execute with the rights granted to him (vulnerability bulletin).
The vulnerability does not require the user to open a link, but requires access to the exposed download point. The bulletin characterizes the attack as high complexity and states that no prior login is required. It does not, however, document an active exploit or the number of installations affected (VulnCheck).
See also: AI coding agents expose thousands of corporate images on public GitHub
Which settings increase the risk?
This vulnerability does not affect all installations in the same way. Those using a different connection method, without an active MAX webhook, do not appear to fall into this scenario. Accordingly, when a secret is set, the code checks the corresponding element of the request and rejects values that do not match.
Administrators should check that the webhook_url is active and that the webhook_secret value is empty. They also need to confirm that the reverse proxy is correctly forwarding the secret header and that the webhook port is not open to untrusted addresses.
Until a confirmed fix is released, the safest interim option is to set a strong, unique secret and restrict access to the webhook through a firewall or private network. If this is not possible, administrators can temporarily disable the feature and use an alternative connection method.
A strong secret is no substitute for restricting access. Exposing the webhook to the entire internet gives potential attackers the ability to test the entry point, while using MAX as a single authentication is not sufficient when the receiver does not verify the origin of the requests.
The correction remains under review
Change request #1969 proposes that cc-connect should not start in MAX webhook mode without a secret unless the administrator explicitly enables an insecure option. The proposal remains open and does not appear as merged when checking the related request on GitHub.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
Therefore, administrators should not assume that the update has already been incorporated into a stable release. Before upgrading, they need to check the project release notes and confirm that the change for MAX webhook is indeed included in the release they are installing.
The SecNews technical team recommends treating each public webhook address as a privileged checkpoint: protected by a secret, limited to trusted sources, and not granted more privileges than necessary. These actions reduce risk until a confirmed fix is released.
See also: OpenClaw vulnerability: Critical flaw in Google Meet allows RCE
See also: OpenAI Codex: Two sandbox boundary violations
