GPU VulnDB

Database/Control plane, storage & DevOps

OpenChoreo: autobuild webhook picks its provider from a caller-supplied header and accepts unsigned Bitbucket requests

CVSS 5.3CVE-2026-73840Control plane, storage & DevOpscurated

Impact

The autobuild endpoint selects its webhook provider from the caller-controlled X-Event-Key header and accepts Bitbucket-shaped requests with no HMAC-SHA256 signature and no configured bitbucket-secret, so an unauthenticated caller who can reach the API can trigger builds for any component it can name by repository URL and branch, including cross-provider triggers carrying attacker-supplied commit SHAs. On a cluster where builds run on the same fleet as workloads, that is unauthenticated consumption of build capacity and a way to push chosen commit SHAs through the build pipeline. The vendor scores the impact as availability-only, which matches an abuse-of-capacity read rather than a code-execution one.

Who can reach it

Anyone who can reach the OpenChoreo API endpoint over the network, with no authentication and no webhook secret. Exposure depends entirely on whether the API is published beyond the cluster or the management VLAN.

What to do

Upgrade to OpenChoreo 1.0.3, 1.1.3 or 1.2.0-rc.2 depending on branch; the fix is a rolling restart of the openchoreo-api deployment, not a node operation. Until patched, restrict network reach to the autobuild endpoint to the SCM provider's published egress ranges and configure the Bitbucket webhook secret.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.