Description

Pipelines-as-Code is a CI/CD system that lets users define Tekton pipelines in source code repositories. Prior to 0.37.8, 0.39.6, 0.42.1, and 0.48.0, the GitHub App provider accepts X-GitHub-Enterprise-Host as the API host while processing webhook events containing an installation.id, before webhook signature validation or confirmation that the host matches the repository URL in the signed payload. An unauthenticated attacker who can reach the webhook endpoint can select an attacker-controlled host and cause the controller to send a locally signed GitHub App JWT to that service. The exposed JWT may be used to attempt to mint installation access tokens during its validity window, subject to the GitHub App installation and permissions. The incoming webhook installation-lookup path is also affected, but exploitation of that path requires the valid incoming webhook secret for the target Repository CR. This issue is fixed in versions 0.37.8, 0.39.6, 0.42.1, and 0.48.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-09-15T15:17:17.707Z",
  "pubdate": "2026-09-15T15:17:17.707Z",
  "executiveSummary": "Pipelines-as-Code is susceptible to a security flaw involving improper validation of GitHub API host headers in incoming webhook events. This vulnerability allows an unauthenticated remote attacker to intercept locally signed GitHub App JWTs by forcing the controller to transmit authentication credentials to an attacker-controlled server.\nThe vulnerability type is an Improper Input Validation leading to potential credential leakage. By manipulating the X-GitHub-Enterprise-Host header, an attacker can influence the destination of requests triggered during the webhook processing lifecycle, specifically before signature verification occurs.\nThis issue affects Pipelines-as-Code versions prior to 0.37.8, 0.39.6, 0.42.1, and 0.48.0. The risk is significant as it provides a pathway for an attacker to obtain valid JWTs, which could subsequently be used to mint installation access tokens. Exploitation relies on network reachability to the webhook endpoint. Once a JWT is obtained, the attacker can leverage the privileges associated with the compromised GitHub App installation, potentially gaining unauthorized access to repository data or CI/CD pipelines, depending on the App's configured permissions.",
  "technicalDetails": "The vulnerability resides within the GitHub App provider component of Pipelines-as-Code. The root cause is a logic error where the controller processes the 'X-GitHub-Enterprise-Host' HTTP header to determine the API endpoint for webhook event handling before verifying the authenticity of the webhook request via its cryptographic signature.\nDuring the processing of incoming webhook events that contain an 'installation.id', the application logic extracts the 'X-GitHub-Enterprise-Host' header to route the subsequent API interaction. Because this routing decision occurs prior to the validation of the webhook secret, an attacker can supply an arbitrary host URL. When the controller attempts to handle the payload, it generates and transmits a locally signed GitHub App JWT to the attacker-defined endpoint.\nThe attack flow proceeds as follows: 1) An unauthenticated attacker identifies the publicly exposed webhook endpoint of the Pipelines-as-Code controller. 2) The attacker crafts a malicious webhook request and includes the 'X-GitHub-Enterprise-Host' header, pointing to an attacker-controlled server. 3) The Pipelines-as-Code controller accepts the request and, before performing signature validation, uses the attacker-provided host to initiate an API call. 4) The controller transmits the GitHub App JWT to the attacker's server as part of this request. 5) The attacker captures the JWT, which is valid for the duration of its defined window, and attempts to use it to authenticate against GitHub to mint installation access tokens.\nWhile the 'installation-lookup' path is also susceptible, exploitation of that specific vector requires prior knowledge of the valid incoming webhook secret associated with the target Repository CR. The primary attack vector remains the initial webhook processing stage due to the lack of pre-verification validation. The vulnerability effectively allows an attacker to bypass standard security controls to exfiltrate identity material, which is critical for the integrity of the CI/CD pipeline infrastructure."
}