{"schema_version":"1.9.0","id":"CVE-2026-33022","published":"2026-03-20T07:48:15.383Z","modified":"2026-08-12T03:51:37.122249363Z","aliases":["GHSA-cv4x-93xx-wgfj","GO-2026-4730"],"related":["CGA-vg29-rqrr-7pq3","SUSE-SU-2026:1135-1","openSUSE-SU-2026:21483-1"],"summary":"Tekton Pipelines: Controller can panic when setting long resolver names in TaskRun/PipelineRun","details":"Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines. Versions 0.60.0 through 1.0.0, 1.1.0 through 1.3.2, 1.4.0 through 1.6.0, 1.7.0 through 1.9.0, 1.10.0, and 1.10.1 have a denial-of-service vulnerability in that allows any user who can create a TaskRun or PipelineRun to crash the controller cluster-wide by setting .spec.taskRef.resolver (or .spec.pipelineRef.resolver) to a string of 31+ characters. The crash occurs because GenerateDeterministicNameFromSpec produces a name exceeding the 63-character DNS-1123 label limit, and its truncation logic panics on a [-1] slice bound since the generated name contains no spaces. Once crashed, the controller enters a CrashLoopBackOff on restart (as it re-reconciles the offending resource), blocking all CI/CD reconciliation until the resource is manually deleted. Built-in resolvers (git, cluster, bundles, hub) are unaffected due to their short names, but any custom resolver name triggers the bug. The fix truncates the resolver-name prefix instead of the full string, preserving the hash suffix for determinism and uniqueness. This issue has been patched in versions 1.0.1, 1.3.3, 1.6.1, 1.9.2 and 1.10.2.","affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/tektoncd/pipeline","events":[{"introduced":"d649ded4ca0c48759273d7278c1022edce247fe7"},{"fixed":"ec7755031a183b345cf9e64bea0e0505c1b9cb78"},{"introduced":"43c0bb99fa768ff711ad92445c43179b93232877"},{"fixed":"10fa538f9a2b6d01c75138f1ed7ba3da0e34687c"},{"introduced":"eaf7dc1dca3e314c26d14caff8207026a2dfade7"},{"fixed":"3fb58318e1805be7bdaaafcb23e42ade2edbf59c"},{"introduced":"478d30f0a799663216cd225cf826e0b1efdadee3"},{"fixed":"3ca7bc6e6dd1d97f80b84f78370d91edaf023cbd"},{"introduced":"9db88e0a3f072ade16ad0d88f1fd6a391281cf39"},{"fixed":"cdb4e1e97a4f3170f9bc2cbfff83a6c8107bc3db"},{"fixed":"5eead3f859b9f938e86039e4d29185092c1d4ee6"}],"database_specific":{"cpe":"cpe:2.3:a:linuxfoundation:tekton_pipelines:*:*:*:*:*:go:*:*","extracted_events":[{"introduced":"0.60.0"},{"fixed":"1.0.1"},{"introduced":"1.1.0"},{"fixed":"1.3.3"},{"introduced":"1.4.0"},{"fixed":"1.6.1"},{"introduced":"1.7.0"},{"fixed":"1.9.2"},{"introduced":"1.10.0"},{"fixed":"1.10.2"}],"source":["CPE_RANGE","REFERENCES"]}}],"versions":["v1.9.1","v1.10.1","v1.10.0","v1.9.0","v1.6.0","v1.7.0","v1.5.0","v1.3.2","v1.4.0","v1.3.1","v1.3.0","v1.2.0","v1.0.0","v1.1.0","v0.70.0","v0.69.0","v0.68.0","v0.66.0","v0.65.0","v0.64.0","v0.63.0","v0.62.0","v0.61.0","v0.60.0"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-33022.json"}}],"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/33xxx/CVE-2026-33022.json"},{"type":"ADVISORY","url":"https://github.com/tektoncd/pipeline/security/advisories/GHSA-cv4x-93xx-wgfj"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-33022"},{"type":"FIX","url":"https://github.com/tektoncd/pipeline/commit/5eead3f859b9f938e86039e4d29185092c1d4ee6"}],"database_specific":{"cna_assigner":"GitHub_M","cwe_ids":["CWE-129"],"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/33xxx/CVE-2026-33022.json"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}