OpenChoreo: Unauthenticated build/workflow trigger via git-provider confusion (webhook signature bypass)GHSA-c5f6-2rm9-2w8g
MEDIUMFix: openchoreo/openchoreo#4239GHSA-c5f6-2rm9-2w8g is a medium-severity (CVSS 5.3) Improper Authentication vulnerability in github.com/openchoreo/openchoreo. A fix is available for github.com/openchoreo/openchoreo — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-c5f6-2rm9-2w8g.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-c5f6-2rm9-2w8g by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 390,400 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/openchoreo/openchoreo🐹github.com/openchoreo/openchoreo🐹github.com/openchoreo/openchoreoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The OpenChoreo autobuild webhook endpoint (POST /api/v1alpha1/autobuild) selected the git provider used to authenticate an incoming webhook from a client-supplied request header rather than from the target component's configuration, and its Bitbucket provider accepted requests without a valid signature. A caller could set the X-Event-Key header to be treated as a Bitbucket webhook, bypassing the HMAC secret that otherwise protects GitHub and GitLab webhooks, and trigger a component build without authenticating.
Impact
An attacker who can reach the autobuild webhook endpoint and knows the repository URL and branch configured for an auto-build component can trigger a build for that component without authenticating — including components configured for GitHub or GitLab, since the provider used or verification is chosen by the caller rather than by the component's configuration. The triggered build runs against a commit SHA supplied by the attacker, and the component lookup is not scoped to a tenant or namespace, so any auto-build component across the cluster matching the given repository and branch is affected. This can result in unauthorized builds — and, where auto-deploy is configured, unauthorized deployment of attacker-influenced code — and can be used to exhaust build resources through repeated unauthenticated triggering.
The exposure applies to any component with spec.autoBuild: true, regardless of which git provider it declares, wherever the autobuild webhook endpoint is network-reachable.
Patches
Fixed in 1.0.3, 1.1.3, and 1.2.0-rc.2. The fix validates Bitbucket webhooks with HMAC-SHA256 against the configured secret using the same verification path as GitHub, requires a configured, non-empty secret for every provider (a missing secret now rejects the request instead of skipping validation), and requires the authenticated provider to match the git provider configured for the matched component. Upgrading is non-disruptive — no component or webhook configuration changes are required beyond the standard upgrade. Upgrade path: 1.1.x → 1.1.3, 1.0.x and earlier → 1.0.3, 1.2 line → 1.2.0-rc.2 or later.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/openchoreo/openchoreo | all versions | 1.0.3go get github.com/openchoreo/openchoreo@v1.0.3 |
| 🐹Go | github.com/openchoreo/openchoreo | ≥ 1.1.0&&< 1.1.3 | 1.1.3go get github.com/openchoreo/openchoreo@v1.1.3 |
| 🐹Go | github.com/openchoreo/openchoreo | ≥ 1.2.0-rc.1&&< 1.2.0-rc.2 | 1.2.0-rc.2go get github.com/openchoreo/openchoreo@v1.2.0-rc.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/openchoreo/openchoreo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/openchoreo/openchoreo to 1.0.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c5f6-2rm9-2w8g is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-c5f6-2rm9-2w8g in your dependencies?
Find it across Go, including transitive dependencies.