CVE-2026-25542 is a medium-severity (CVSS 6.5) CWE-185 vulnerability in github.com/tektoncd/pipeline. A fix is available for github.com/tektoncd/pipeline — see the affected versions and patch details below.
Tekton Pipelines: VerificationPolicy regex pattern bypass via substring matching
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-25542.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-25542 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/tektoncd/pipeline🐹github.com/tektoncd/pipeline🐹github.com/tektoncd/pipeline🐹github.com/tektoncd/pipeline🐹github.com/tektoncd/pipelineReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
hey guys,
triage contract this is a first-screen summary; deterministic proof is in the proof bundle (canonical.log/control.log/witness.txt).
summary
trusted resources verification policies match a resource source string (refSource.URI) against spec.resources[].pattern using regexp.MatchString. in go, regexp.MatchString reports a match if the pattern matches anywhere in the string, so common unanchored patterns (including examples in tekton documentation) can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. this can cause an unintended policy match and change which verification mode/keys apply.
pins
- repo: https://github.com/tektoncd/pipeline
- commit: 0133513db03dadb3cb08801d6b0330badcb63830
- callsite: pkg/trustedresources/verify.go:118-137 (getMatchedPolicies)
severity MEDIUM (provisional CVSS 5.3–6.5) (signing request tampering)
repro (canonical)
- command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make canonical
- expected: cap not reached; canonical does not emit the vulnerability markers.
- actual: cap reached; canonical emits the vulnerability markers.
- canonical markers (mandatory): [CALLSITE_HIT] + [PROOF_MARKER]
negative control
- command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make control
- expected: cap not reached under the same harness; control emits the control marker and does not emit the vulnerability markers.
- control markers (mandatory): [CALLSITE_HIT] + [NC_MARKER]
fix
consider making matching safe-by-default by requiring full-string matches (or validating patterns and documenting substring semantics clearly). one option is to anchor patterns before matching (e.g., wrap pattern as ^(?:pattern)$ when not already anchored), or to provide a separate field for exact match vs regex match.
fix accepted when: under the same harness, canonical still hits [CALLSITE_HIT] but does not emit [PROOF_MARKER].
proof bundle pointers
- bundle: poc.zip
- bundle convention: zip extracts under a single top-level folder (poc-F-TEKTON-REGEX-001/) to avoid collisions
- contains: canonical.log, control.log, witness.txt
- extracted paths: after extraction, see ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt
- verify: compare shasum -a 256 for canonical.log/control.log/fix.patch/test source against witness.txt
- supported-mode note: if your supported integration uses verified https app-links/universal links only, provide the supported tag/branch and we can retest on that pin.
impact
an attacker can craft a trusted resources source string that embeds a trusted substring and still matches an unanchored verificationpolicy spec.resources[].pattern, even if the policy is intended to constrain matches to a specific trusted source. this occurs because regexp.MatchString succeeds on substring matches, so patterns like https://github.com/tektoncd/catalog.git match attacker-controlled sources such as https://evil.com/?x=https://github.com/tektoncd/catalog.git.
affected: deployments using trusted resources verification with unanchored verificationpolicy patterns, where an attacker can influence the refSource.URI value used for policy matching.
not affected: deployments that anchor all patterns (^...$) or otherwise enforce full-string matching; deployments where attackers cannot influence refSource.URI.
steps to reproduce
unzip -q -o poc.zip -d /tmp/poc-tekton-regex-001
cd /tmp/poc-tekton-regex-001/poc-F-TEKTON-REGEX-001
bash ./run.sh canonical | tee /tmp/tekton-regex-001-canonical.log
bash ./run.sh control | tee /tmp/tekton-regex-001-control.log
grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-canonical.log && grep -n '\\[NC_MARKER\\]' /tmp/tekton-regex-001-control.log && ! grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-control.log
suggested patch options:
- make matching safe-by-default by anchoring patterns before matching (or by validating and rejecting unanchored patterns).
- document the substring semantics explicitly and update documentation examples to include anchors.
workarounds anchor verificationpolicy resource patterns so they must match the full source string. example:
^https://github.com/tektoncd/catalog\\.git$
best, oleh
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/tektoncd/pipeline | ≥ 0.43.0&&< 1.0.2 | 1.0.2go get github.com/tektoncd/pipeline@v1.0.2 |
| 🐹Go | github.com/tektoncd/pipeline | ≥ 1.2.0&&< 1.3.4 | 1.3.4go get github.com/tektoncd/pipeline@v1.3.4 |
| 🐹Go | github.com/tektoncd/pipeline | ≥ 1.4.0&&< 1.6.2 | 1.6.2go get github.com/tektoncd/pipeline@v1.6.2 |
| 🐹Go | github.com/tektoncd/pipeline | ≥ 1.7.0&&< 1.9.3 | 1.9.3go get github.com/tektoncd/pipeline@v1.9.3 |
| 🐹Go | github.com/tektoncd/pipeline | ≥ 1.10.0&&< 1.11.1 | 1.11.1go get github.com/tektoncd/pipeline@v1.11.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/tektoncd/pipeline, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/tektoncd/pipeline to 1.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-25542 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-25542 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-25542. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-25542 in your dependencies?
O3 Security finds CVE-2026-25542 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.