Description

OpenChoreo is a complete, open-source developer platform for Kubernetes. Prior to 1.0.3, 1.1.3, and 1.2.0-rc.2, the POST /api/v1alpha1/autobuild endpoint in internal/openchoreo-api/api/handlers/webhook_handler.go selected a webhook provider from caller-controlled X-Event-Key, accepted Bitbucket requests without HMAC-SHA256 in X-Hub-Signature or a configured bitbucket-secret, and allowed unauthenticated build triggers for components matched by repository URL and branch, including cross-provider triggers using attacker-supplied commit SHAs. This issue is fixed in versions 1.0.3, 1.1.3, and 1.2.0-rc.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-13T22:17:28.737Z",
  "pubdate": "2026-08-13T22:17:28.737Z",
  "executiveSummary": "OpenChoreo contains an authentication bypass and improper webhook validation vulnerability affecting the POST /api/v1alpha1/autobuild endpoint within internal/openchoreo-api/api/handlers/webhook_handler.go. Prior to versions 1.0.3, 1.1.3, and 1.2.0-rc.2, this security flaw allows unauthenticated attackers to trigger component builds. The vulnerability arises because the endpoint selects a webhook provider dynamically based on the caller-controlled X-Event-Key header, accepts Bitbucket requests lacking HMAC-SHA256 verification via the X-Hub-Signature header or a configured bitbucket-secret, and fails to enforce proper authentication for components matching the specified repository URL and branch. Furthermore, the system permits cross-provider triggers utilizing attacker-supplied commit SHAs. An unauthenticated attacker can exploit this behavior to trigger arbitrary or unauthorized builds within the Kubernetes-based developer platform, posing severe risks to CI/CD pipeline integrity, resource availability, and overall system security. Exploitation requires network access to the API endpoint and knowledge of targeted component repository URLs and branches, but does not require prior authentication or valid cryptographic secrets.",
  "technicalDetails": "The vulnerability resides in the webhook handling logic implemented in internal/openchoreo-api/api/handlers/webhook_handler.go, specifically within the POST /api/v1alpha1/autobuild endpoint of OpenChoreo. The root cause of the flaw stems from insecure request processing and insufficient cryptographic validation of incoming webhook payloads. First, the application relies on the caller-controlled X-Event-Key HTTP header to determine and select the appropriate webhook provider logic, allowing attackers to manipulate routing and handling behaviors. Second, the implementation improperly accepts incoming Bitbucket webhook requests without requiring or validating HMAC-SHA256 signatures supplied via the X-Hub-Signature header, nor does it enforce the presence of a configured bitbucket-secret. Consequently, cryptographic authentication and integrity checks are entirely bypassed.\nDuring the exploitation flow, an unauthenticated network attacker crafts an HTTP POST request targeted at the /api/v1alpha1/autobuild endpoint. The attacker manipulates the X-Event-Key header and supplies fabricated webhook payloads containing target repository URLs, branches, and arbitrary attacker-supplied commit SHAs. Because authentication is absent and cryptographic signatures are ignored or omitted, the application processes the request. The backend attempts to match the payload against components based on the supplied repository URL and branch. Due to the lack of strict provider isolation and cross-provider validation mechanisms, the system permits cross-provider triggers. The application accepts the attacker-supplied commit SHAs and initiates unauthorized build pipelines for the matched components. This allows malicious actors to consume cluster computational resources, execute arbitrary code definitions mapped to the targeted components, and potentially introduce malicious code artifacts into the deployment lifecycle of the Kubernetes platform."
}