Описание
Capsule: CapsuleConfiguration NodeMetadata regex fields lack webhook validation, allowing MustCompile panic on all Node admission requests
Summary
CapsuleConfiguration.Spec.NodeMetadata.ForbiddenLabels.Regex and ForbiddenAnnotations.Regex are never validated by any admission webhook. A Cluster Admin can persist a malformed regex to etcd without being blocked. Once stored, every Node CREATE, UPDATE, or PATCH request triggers regexp.MustCompile() in pkg/api/forbidden_list.go:36, which panics and crashes the node admission webhook — causing a cluster-wide Denial of Service for all Node operations.
Root cause
internal/webhook/tenant/validation/ contains dedicated regex validators for every Tenant regex field (hostname, storageclass, ingressclass, containerregistry, etc.). internal/webhook/cfg/ contains no regex validator at all — only owners.go, serviceaccount.go, and warnings.go.
The downstream consumer internal/webhook/node/user_metadata.go calls:
Which routes to pkg/api/forbidden_list.go:36:
Unlike regexp.Compile, regexp.MustCompile panics instead of returning an error. Since no webhook validates the CapsuleConfiguration regex fields before storage, a malformed value reaches MustCompile on every Node admission request.
Comparison with existing CVEs
GHSA-f94q-w3w8-cj67 and GHSA-gxjc-74v5-3vx3 affect individual Tenant fields — their validators existed but checked the wrong field. This issue is different: no validator exists at all for CapsuleConfiguration regex fields, and the blast radius is cluster-wide (all Nodes), not scoped to one tenant.
PoC
Expected output:
Fix
Add a node_metadata_regex.go handler to internal/webhook/cfg/ following the same pattern as forbidden_annotations_regex.go:
Impact
A Cluster Admin (or compromised admin account) can update CapsuleConfiguration
with a malformed NodeMetadata regex (e.g., [invalid-regex(). The update is
accepted without validation and persisted to etcd. Once stored, every subsequent
Node admission request triggers regexp.MustCompile() with the invalid pattern,
causing the Capsule node webhook to panic.
Affected operations (cluster-wide):
- Node labeling, annotations, and taints (
kubectl label/annotate/taint node) - Cluster autoscaler operations (cannot register or remove nodes)
- Cloud provider node lifecycle management (metadata sync, status updates)
- Node maintenance workflows (cordon, drain, uncordon)
Severity: This is a cluster-wide Denial of Service affecting all Node infrastructure operations. Unlike tenant-scoped CVEs (GHSA-f94q-w3w8-cj67, GHSA-gxjc-74v5-3vx3) that impact only Ingress or Namespace operations within a single tenant, this vulnerability blocks the entire cluster's ability to manage nodes.
The cluster cannot scale, perform maintenance, or process any node metadata changes until a Cluster Admin manually corrects the CapsuleConfiguration—requiring direct kubectl access with valid YAML.
Пакеты
github.com/projectcapsule/capsule
<= 0.13.7
0.13.8
Связанные уязвимости
Capsule is a multi-tenancy and policy-based framework for Kubernetes. Prior to 0.13.8, CapsuleConfiguration.Spec.NodeMetadata.ForbiddenLabels.Regex and CapsuleConfiguration.Spec.NodeMetadata.ForbiddenAnnotations.Regex were not validated by the configuration admission webhook, allowing a Cluster Admin to store a malformed regex that later reached regexp.MustCompile in pkg/api/forbidden_list.go through internal/webhook/node/user_metadata.go and crashed the node admission webhook on Node create, update, or patch requests. This issue is fixed in version 0.13.8.