CVE-2026-33022 in pipeline
Summary
by MITRE • 03/20/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/31/2026
The Tekton Pipelines project represents a significant component in Kubernetes-based continuous integration and delivery environments, providing kubernetes-style resources for pipeline declaration. This vulnerability affects multiple release versions spanning from 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, and 1.10.0 and 1.10.1, creating a widespread impact across the project's ecosystem. The denial-of-service vulnerability specifically targets the controller's ability to process TaskRun and PipelineRun resources, allowing any user with permission to create these resources to cause cluster-wide disruptions. This represents a critical security flaw that directly violates the principle of least privilege and system availability, as unauthorized users can effectively disable CI/CD operations across entire clusters.
The technical flaw manifests in the GenerateDeterministicNameFromSpec function which handles name generation for pipeline resources. When users set the .spec.taskRef.resolver or .spec.pipelineRef.resolver fields to strings exceeding 31 characters, the system generates names that exceed the 63-character DNS-1123 label limit imposed by Kubernetes standards. The truncation logic within the implementation contains a critical boundary condition error that panics when encountering a [-1] slice bound, occurring specifically when the generated name contains no spaces to serve as truncation points. This panic condition represents a classic buffer over-read vulnerability, where the code attempts to access memory outside valid bounds. The issue maps directly to CWE-129, which covers improper validation of array index bounds, and demonstrates poor error handling practices that lead to system instability rather than graceful degradation.
The operational impact of this vulnerability extends beyond simple service disruption to create a cascading failure scenario within the Kubernetes cluster. Once triggered, the controller enters a CrashLoopBackOff state during restart attempts because it continuously re-reconciles the problematic resource, preventing any further CI/CD processing until manual intervention occurs. This creates a significant operational burden for DevOps teams, as administrators must manually delete the offending resources to restore service. The vulnerability affects all custom resolver names while leaving built-in resolvers (git, cluster, bundles, hub) unaffected due to their shorter names, creating an asymmetric impact that makes the issue particularly insidious. From an ATT&CK framework perspective, this vulnerability maps to T1499.004, which covers network disruption, and T1566.001, which involves phishing with social engineering, as it can be exploited through unauthorized user access to create service disruption.
The mitigation strategy implemented in patched versions addresses the root cause by modifying the truncation logic to truncate the resolver-name prefix rather than the entire string, preserving the hash suffix that ensures determinism and uniqueness of generated names. This approach maintains the cryptographic properties necessary for the deterministic naming scheme while preventing the boundary condition error that caused the panic. The fix specifically targets versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, and 1.10.2, ensuring that organizations can upgrade to these versions to resolve the issue. Organizations should prioritize immediate patching of affected systems, as the vulnerability allows for cluster-wide denial-of-service attacks with minimal privileges required. The remediation process involves both automated patch management and manual verification of existing resources to prevent future occurrences, particularly focusing on custom resolver configurations that might trigger the vulnerable code path. This vulnerability serves as a critical reminder of the importance of proper input validation and boundary condition checking in distributed systems, particularly those handling user-provided configuration data in cloud-native environments.