GHSA-c5f6-2rm9-2w8g: Medium severity go/github.com/openchoreo/openchoreo vulnerability

Published Sep 2, 2026
·
Updated

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 Software

3 affected componentsFixes available
go/github.com/openchoreo/openchoreo>=1.2.0-rc.1<1.2.0-rc.2
1.2.0-rc.2
go/github.com/openchoreo/openchoreo>=1.1.0<1.1.3
1.1.3
go/github.com/openchoreo/openchoreo<1.0.3
1.0.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/openchoreo/openchoreo to a version that resolves this vulnerability.

    Fixed in 1.2.0-rc.2
  2. Upgrade

    Upgrade go/github.com/openchoreo/openchoreo to a version that resolves this vulnerability.

    Fixed in 1.1.3
  3. Upgrade

    Upgrade go/github.com/openchoreo/openchoreo to a version that resolves this vulnerability.

    Fixed in 1.0.3
  4. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 1.0.3
  5. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 1.1.3
  6. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 1.2.0-rc.2
  7. Configuration

    Validate Bitbucket webhooks with HMAC-SHA256 against the configured secret using the same verification path as GitHub; require a configured non-empty secret for every provider and reject requests when the secret is missing/empty (instead of skipping validation).

    OpenChoreo autobuild webhook endpoint (POST /api/v1alpha1/autobuild) Bitbucket webhook verification = HMAC-SHA256 with configured secret (reject when secret missing/empty)
  8. Configuration

    Authenticate/verify the incoming webhook using the git provider configured for the target component; do not choose the provider based on the client-supplied request header (e.g., X-Event-Key). Require the authenticated provider to match the git provider configured for the matched component.

    OpenChoreo autobuild webhook endpoint (POST /api/v1alpha1/autobuild) Provider selection for webhook authentication = Must match the git provider configured for the matched component
  9. Compensating control

    Ensure the autobuild webhook endpoint (/api/v1alpha1/autobuild) is reachable only from trusted networks/clients (limit network reachability to prevent unauthenticated triggering of auto-build components).

Event History

Sep 2, 2026
Advisory Published
via GitHub·11:45 PM
Data Sourced
via GitHub·11:45 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed to unauthorized build triggers?

Any auto-build component is affected if an attacker can reach the autobuild webhook endpoint and knows that component's configured repository URL and branch. Component lookup is not limited to a tenant or namespace, so matching components anywhere in the cluster may be targeted.

2

What does an attacker need to trigger a build?

The attacker needs network access to POST /api/v1alpha1/autobuild, the configured repository URL and branch, and can provide a commit SHA for the build. They can send an X-Event-Key header so the request is handled as a Bitbucket webhook without a valid signature.

3

Are GitHub- and GitLab-configured components affected?

Yes. The provider and verification behavior are selected from a client-supplied header rather than the component configuration, so a caller can use the Bitbucket handling path to bypass the HMAC secret protecting GitHub and GitLab webhooks.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203