Cc Connect
Monthly
Missing authentication in the MAX platform adapter of cc-connect through 1.5.0 allows remote attackers to forge webhook updates and, by supplying an allowed or admin user_id, trigger privileged host commands such as /shell. The flaw only materialises when the MAX adapter is deployed in webhook mode with no webhook_secret configured and its listener on port 8080 is network-reachable; configuring a secret eliminates the exposure entirely. At time of analysis there is no CISA KEV entry, no vendor-released patch version published, and no public exploit identified, though the technical bar to exploitation is low once the misconfiguration is present.
Incorrect authorization in cc-connect through 1.5.0 allows an authenticated, low-privileged user who can trigger Feishu interactive card actions inside an admitted chat to dispatch agent commands, because the onCardAction handler never applies the per-user allowlist that the text message handler enforces. The result is an authorization bypass (CWE-863) rated CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N, with high confidentiality, integrity and availability impact confined to the cc-connect scope), meaning a participant who should not be permitted to drive the agent can still do so remotely without user interaction. Exploitation is access-gated rather than open to the internet at large: the attacker must already belong to a Feishu chat that the deployment has admitted, and no public exploit code or confirmed active exploitation was identified at time of analysis, but the enabled agent-command path makes the impact substantive rather than theoretical.
Remote code injection in chenhg5 cc-connect up to version 1.4.1 allows unauthenticated network attackers to execute arbitrary code by manipulating the `exec` argument passed to the `Authenticate` function in `core/webhook.go`. Tagged by reporters as RCE-capable, the vulnerability stems from unsanitized user input reaching a code execution path within the Go webhook handler. A public exploit has been disclosed; no patch has been released, as the upstream GitHub issue was closed automatically due to maintainer inactivity - leaving affected deployments without an official remediation path.
Missing authentication in the MAX platform adapter of cc-connect through 1.5.0 allows remote attackers to forge webhook updates and, by supplying an allowed or admin user_id, trigger privileged host commands such as /shell. The flaw only materialises when the MAX adapter is deployed in webhook mode with no webhook_secret configured and its listener on port 8080 is network-reachable; configuring a secret eliminates the exposure entirely. At time of analysis there is no CISA KEV entry, no vendor-released patch version published, and no public exploit identified, though the technical bar to exploitation is low once the misconfiguration is present.
Incorrect authorization in cc-connect through 1.5.0 allows an authenticated, low-privileged user who can trigger Feishu interactive card actions inside an admitted chat to dispatch agent commands, because the onCardAction handler never applies the per-user allowlist that the text message handler enforces. The result is an authorization bypass (CWE-863) rated CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N, with high confidentiality, integrity and availability impact confined to the cc-connect scope), meaning a participant who should not be permitted to drive the agent can still do so remotely without user interaction. Exploitation is access-gated rather than open to the internet at large: the attacker must already belong to a Feishu chat that the deployment has admitted, and no public exploit code or confirmed active exploitation was identified at time of analysis, but the enabled agent-command path makes the impact substantive rather than theoretical.
Remote code injection in chenhg5 cc-connect up to version 1.4.1 allows unauthenticated network attackers to execute arbitrary code by manipulating the `exec` argument passed to the `Authenticate` function in `core/webhook.go`. Tagged by reporters as RCE-capable, the vulnerability stems from unsanitized user input reaching a code execution path within the Go webhook handler. A public exploit has been disclosed; no patch has been released, as the upstream GitHub issue was closed automatically due to maintainer inactivity - leaving affected deployments without an official remediation path.