EUVD-2026-78587
GHSA-f5f4-3hh4-f54m
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Network-reachable webhook with no auth required; high confidentiality from JWT theft enabling token minting; low integrity from scoped token actions; no availability impact.
Primary rating from Vendor (https://github.com/tektoncd/pipelines-as-code).
CVSS VectorVendor: https://github.com/tektoncd/pipelines-as-code
Lifecycle Timeline
3DescriptionCVE.org
Impact
Pipelines-as-Code installations using the GitHub App provider are vulnerable to GitHub App credential exfiltration through the webhook endpoint.
Affected versions accepted the X-GitHub-Enterprise-Host request header as the GitHub Enterprise API host during GitHub App token generation. For GitHub webhook events containing an installation.id, Pipelines-as-Code generated a GitHub App JWT and requested an installation access token before validating the webhook signature or checking that the Enterprise host matched the repository URL in the signed payload.
An attacker who can reach the Pipelines-as-Code webhook endpoint can send a crafted GitHub webhook payload containing an installation ID and set X-GitHub-Enterprise-Host to an attacker-controlled host. During token generation, the controller signs a GitHub App JWT locally and sends it to the selected API host. This can disclose the GitHub App JWT to the attacker-controlled service, allowing the attacker to attempt to mint GitHub App installation access tokens within the JWT validity window, subject to the GitHub App installation and permissions.
The incoming webhook flow also trusted X-GitHub-Enterprise-Host during GitHub App installation lookup and token generation. In that path, exploitation requires a valid incoming webhook secret for the target Repository CR.
Patches
The fix validates the webhook signature before GitHub App token generation, verifies that X-GitHub-Enterprise-Host matches the repository URL in the webhook payload, and stops using the request header to select the GitHub Enterprise host for incoming webhook token requests. For incoming webhooks, the Enterprise host is derived from the configured Repository URL instead.
The fix is available in v0.48.0. Supported backport releases will be added here after release tags are published.
Workarounds
Until a patched release is deployed, operators should block or strip unexpected X-GitHub-Enterprise-Host headers at the ingress or proxy in front of the Pipelines-as-Code webhook endpoint. For GitHub.com installations, reject requests that include this header. For GitHub Enterprise Server installations, allow only the expected Enterprise hostname.
Operators should also restrict access to the webhook endpoint to trusted Git provider sources where possible. If exploitation is suspected, rotate the GitHub App private key and review GitHub App installation token activity.
Credits
Reported and fixed by the Pipelines-as-Code maintainers.
AnalysisAI
GitHub App credential exfiltration in OpenShift Pipelines-as-Code allows unauthenticated network attackers to steal GitHub App JWTs by manipulating the webhook endpoint's trust in the untrusted X-GitHub-Enterprise-Host HTTP request header. Affected installations (v0.43.0-v0.47.x and several earlier branches) generated and dispatched a signed GitHub App JWT to an attacker-controlled host before validating the webhook signature or verifying that the Enterprise host matched the repository URL in the signed payload. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Primary attack path: the attacker must be able to send HTTP requests to the Pipelines-as-Code webhook endpoint - no authentication, webhook secret, or prior knowledge of the target repository is required. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor-assigned CVSS 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N) accurately reflects the primary attack path: the webhook endpoint is network-accessible, the attack requires no authentication, and a single crafted HTTP request is sufficient to trigger JWT exfiltration. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | The primary fix is to upgrade to one of the patched releases: v0.48.0 (latest), v0.42.1, v0.39.6, or v0.37.8, depending on the supported branch in use. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, identify all OpenShift Pipelines-as-Code installations running versions 0.43.0-0.47.x and assess whether webhook endpoints are externally accessible; simultaneously review the scope of permissions assigned to any integrated GitHub Apps. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: ImportantShare
External POC / Exploit Code
Leaving vuln.today