| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/tektoncd/pipeline | ≥ 0.43.0, < 1.0.2≥ 1.1.0, < 1.3.4≥ 1.10.0, < 1.11.1≥ 1.2.0, < 1.3.4≥ 1.4.0, < 1.6.2≥ 1.7.0, < 1.9.3 | 1.0.21.3.41.11.11.6.21.9.3 |
| tekton pipelines | ≥ 0.43.0, < 1.11.0 | 1.11.0 |
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
severity MEDIUM (provisional CVSS 5.3–6.5) (signing request tampering)
repro (canonical)
negative control
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
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeimpact
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:
workarounds anchor verificationpolicy resource patterns so they must match the full source string. example:
^https://github.com/tektoncd/catalog\\.git$best, oleh