GitHub Security Advisory: GHSA-rmx9-2pp3-xhcr
Package: github.com/tektoncd/pipeline (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-185: Incorrect Regular Expression
Vulnerable versions: >= 0.43.0, < 1.11.0
Patched in: 1.11.0

Summary: Tekton Pipelines has VerificationPolicy regex pattern bypass via substring matching

Details:
## Summary

The Trusted Resources verification system matches a resource source string (`refSource.URI`) against `spec.resources[].pattern` using Go's `regexp.MatchString`. In Go, `regexp.MatchString` reports a match if the pattern matches **anywhere** in the input string. As a result, common unanchored patterns—including examples found in Tekton documentation—can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. This may cause an unintended policy match and alter which verification mode or keys are applied.

## Affected Component

- **Repository:** <https://github.com/tektoncd/pipeline>
- **Commit:** `0133513db03dadb3cb08301d6b0330badcb63830`
- **Call site:** `pkg/trustedresources/verify.go:118–137` (`getMatchedPolicies`)

## 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. For example, a pattern such as `https://github.com/tektoncd/catalog.git` would match an attacker-controlled source like `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`.

## Reproduction

### Canonical (Demonstrates Vulnerability)

```bash
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
```

- **Expected (secure):** Capability not reached; canonical does not emit vulnerability markers.
- **Actual (vulnerable):** Capability reached; canonical emits vulnerability markers.
- **Canonical markers (mandatory):** `[CALLSITE_HIT]` + `[PROOF_MARKER]`

### Negative Control

```bash
bash ./run.sh control | tee /tmp/tekton-regex-001-control.log
```

- **Expected:** Capability not reached under the same harness; control emits the control marker and does not emit vulnerability markers.
- **Control markers (mandatory):** `[CALLSITE_HIT]` + `[NC_MARKER]`

### Verification

```bash
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 Fix

It is recommended to make matching safe-by-default by requiring full-string matches, or by validating patterns and clearly documenting substring semantics. Possible approaches include:

1. **Anchor patterns before matching** — e.g., wrap `pattern` as `^(?:pattern)$` when not already an