CVE-2026-73840: Unauthenticated Webhook Signature Bypass and Git-Provider Confusion in OpenChoreo

The Kubernetes-native developer platform OpenChoreo exposes a REST API endpoint /api/v1alpha1/autobuild designed to consume Git webhook requests. This endpoint automates target repository rebuilds when upstream developers perform code modifications.

To handle multi-tenant developer configurations, the ingestion handler detects whether incoming payloads originate from GitHub, GitLab, or Bitbucket. It resolves the specific git provider based on client-supplied headers and routes the payload to corresponding cryptographic signature checks.

Due to design flaws, the endpoint did not require a signature for Bitbucket requests, nor did it verify that the authenticated incoming webhook matched the target repository's host platform. These errors allow an attacker to spoof headers and initiate builds on unrelated, securely-configured GitHub repositories.

The root cause of this vulnerability lies in the logic of the webhook dispatcher and the failure to enforce consistent state. The vulnerability is characterized by three core architecture mistakes that must all align to allow exploitation.

First, the header analysis in internal/openchoreo-api/api/handlers/webhook_handler.go uses client-supplied headers to detect the provider. If the header X-Event-Key is present, the handler routes the execution flow into the Bitbucket integration path.

Second, the Bitbucket provider implementation in internal/openchoreo-api/services/git/bitbucket.go assumed Bitbucket did not use cryptographic signing. Consequently, if no webhook signature header was present, or if the bitbucket-secret was unconfigured, the implementation evaluated the check as successful and returned nil instead of failing closed.

Third, the webhook processor did not check if the webhook provider matched the repository's host provider. If an attacker configured a webhook with the X-Event-Key header but provided the repository URL of a GitHub target, the system routed the validation to the Bitbucket parser, bypassed the signature check, matched the URL, and triggered the GitHub build.

In the vulnerable version of webhook_handler.go, Bitbucket webhooks did not request signature verification, leaving the signature header parameter blank:

case params.XEventKey != nil && *params.XEventKey != "":
    // The second parameter (signature header) is blank, skipping HMAC checks
    return git.ProviderBitbucket, "", "bitbucket-secret", true

In the patched implementation, the router enforces the presence of the X-Hub-Signature header for Bitbucket payload evaluation:

case params.XEventKey != nil && *params.XEventKey != "":
    // The signature header is now explicitly required
    return git.ProviderBitbucket, "X-Hub-Signature", "bitbucket-secret", true

To ensure consistent and constant-time signature validation, a new shared cryptographic module was introduced in services/git/signature.go:

package git
 
import (
  "crypto/hmac"
  "crypto/sha256"
  "encoding/hex"
  "fmt"
  "strings"
)
 
func verifyHMACSHA256(payload []byte, signature, secret string) error {
  if secret == "" {
    return fmt.Errorf("webhook secret not configured")
  }
  if signature == "" {
    return fmt.Errorf("missing signature header")
  }
  if !strings.HasPrefix(signature, "sha256=") {
    return fmt.Errorf("invalid signature format")
  }
  signature = strings.TrimPrefix(signature, "sha256=")
 
  mac := hmac.New(sha256.New, []byte(secret))
  mac.Write(payload)
  expectedMAC := hex.EncodeToString(mac.Sum(nil))
 
  if !hmac.Equal([]byte(signature), []byte(expectedMAC)) {
    return fmt.Errorf("invalid signature")
  }
  return nil
}

Additionally, the patch enforces provider consistency in webhook_processor.go by checking the domain of the target repository URL and rejecting mismatched webhook events:

if expected := providerFromRepoURL(repoURL); expected != "" && string(expected) != event.Provider {
  s.logger.Info("Skipping component: provider mismatch",
    "component", comp.Name,
    "expectedProvider", expected,
    "webhookProvider", event.Provider)
  continue
}

To exploit this vulnerability, an attacker must first identify the target Git repository URL and active branch mapped inside the OpenChoreo environment. No valid user credentials or authentication tokens are required.

The attacker crafts a custom JSON payload representing a standard repository push event. This payload contains the target's repository URL and target branch. The attacker then assigns an arbitrary commit SHA within this payload.

The attacker transmits the request to /api/v1alpha1/autobuild with the X-Event-Key: repo:push header. The system maps the event to the Bitbucket provider module. Because there is no signature configuration, the check returns success, and the system matches the URL and schedules the unauthorized build on the backend.

This vulnerability scored 5.3 on the CVSS v3.1 scale. The impact vector is categorized as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.

While this attack does not directly leak sensitive source code or application secrets, it allows unauthenticated entities to trigger resource-intensive pipelines on demand. Repeated execution can lead to severe resource exhaustion, denial-of-service on build runners, and increased container compute fees.

Because the platform triggers pipelines using the user-defined, arbitrary commit SHA, there is a risk that untrusted commit changes can be introduced into systems that do not perform strict verification, bypassing the platform workflow restrictions.

Remediation requires upgrading the OpenChoreo platform to the patched versions. The fixes are integrated into releases 1.0.3, 1.1.3, and 1.2.0-rc.2.

Applying this patch introduces a breaking change for existing Bitbucket integrations. Administrators must configure a secret token under the bitbucket-secret key inside the platform's git-webhook-secrets resource. Correspondingly, the Bitbucket repository's webhook configuration must be updated to output matching HMAC-SHA256 signatures.

If you are unable to patch immediately, block access to /api/v1alpha1/autobuild at the ingress or WAF layer for any IP ranges outside the official Git provider CIDR blocks.