cc-connect EUVD-2026-63172

The webhook endpoint in cc-connect must be network-accessible to attackers - this is the intended deployment mode of a webhook receiver, making this condition met by default in any standard deployment. No authentication is required prior to reaching the vulnerable Authenticate function, as the CVSS vector specifies PR:N. No special configuration, feature flag, or non-default setting is described as required. The limiting factor is deployment footprint: cc-connect is a niche, low-adoption library, so mass exploitation is unlikely in practice. However, any instance exposed to the internet or an untrusted network segment is exploitable by an unauthenticated attacker with access to the public POC.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms low-complexity, unauthenticated network exploitation with no required user interaction - a highly exploitable posture. However, the provided impact metrics (VC:L/VI:L/VA:L) are notably inconsistent with the 'RCE' tag assigned by reporters: true OS command execution via os/exec would normally yield High confidentiality, integrity, and availability impact, not Low across all three. This discrepancy is significant and unresolved - either the exec path is sandboxed or context-limited, or the impact metrics were underscored relative to actual capability. The EPSS score was not provided, limiting probabilistic exploitation forecasting. No KEV listing is present, but the public POC (E:P in the CVSS 4.0 supplemental) substantially lowers the bar for exploitation. The abandoned GitHub issue raises a critical concern: there is no vendor response path, and the CPE wildcard (*) covers all versions through 1.4.1 with no upper-bound fix version. Even a mid-sized municipal IT team in legnica - used here purely as an illustrative hypothetical - would correctly treat any internet-exposed cc-connect instance as an unpatched, publicly exploitable endpoint requiring immediate isolation. The practical risk is elevated by the absence of a patch and the presence of a public exploit, regardless of the ambiguous impact-score discrepancy.

A remote, unauthenticated attacker sends a crafted HTTP request to the cc-connect webhook endpoint, supplying a malicious value in the exec parameter. The Authenticate function in core/webhook.go processes this input without sanitization and passes it to a code or command execution context. Because a public proof-of-concept exploit exists, this scenario requires minimal attacker skill and can be reproduced from existing tooling.