Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCluster admin submits Tenant update with malformed AllowedHostnames.Regex
-
DeliveryWebhook validates stale old value, accepts bad config
-
ExploitBroken regex persisted to Tenant spec
-
ExecutionTenant Ingress create/update evaluates invalid pattern
-
PersistAll hostnames treated as unmatched
-
ImpactIngress operations denied for tenant (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Incorrect comparison
|
| Exploitation Conditions | Requires an actor with permission to update Tenant custom resources (effectively cluster-administrator level, per the description and PR:H) to submit a malformed AllowedHostnames.Regex on an *update* to an existing Tenant - the create path and the initial valid state are unaffected because the bug only mis-compares old vs new on OnUpdate. Impact is limited to tenants that use IngressOptions.AllowedHostnames.Regex; the resulting Ingress lockout persists only until an administrator repairs the Tenant configuration. Not exploitable by unprivileged tenant users or unauthenticated remote attackers, and only present in Capsule 0.13.0 through 0.13.6. |
| Impact | This is a genuine but LOW-priority defect, not a high-real-risk issue despite the 6.8 CVSS. The CVSS vector (AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H) confirms a pure availability impact (C:N/I:N) requiring high privileges (PR:H). Critically, the 'attacker' per the description is a *cluster administrator* - the actor who stores the malformed AllowedHostnames.Regex is already the most-privileged principal in the cluster, so the flaw is closer to a self-inflicted misconfiguration hazard than a cross-privilege attack. No EPSS score, no CISA KEV listing, and no public exploit code were provided: no public exploit identified at time of analysis. The S:C (scope-changed) claim is defensible in that the broken Tenant config later blocks Ingress operations for tenant users/namespaces distinct from the config author, but it is debatable. There are no conflicting signals in the data; the CVSS network vector is consistent with the Kubernetes webhook/API-server delivery path. CWE-697 (Incorrect Comparison) accurately maps to the reversed new/old parameter comparison. |
| Exploit ScenarioDerived | A cluster administrator submits a Tenant update setting Spec.IngressOptions.AllowedHostnames.Regex to a malformed pattern (e.g. '('). Because hostnameRegexHandler.OnUpdate compares the stale previous value instead of the submitted one, the validating webhook accepts the update and persists the broken regex. Later, any tenant Ingress create/update evaluates the invalid pattern, silently treats every hostname as unmatched, and blocks all Ingress operations for that tenant until an admin manually repairs the Tenant. No public exploit code was provided. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
In Capsule 0.13.0 through 0.13.6, the Tenant validating admission webhook's hostnameRegexHandler.OnUpdate passes the new and old Tenant objects in the wrong order, so an update is validated against the previously stored AllowedHostnames.Regex rather than the newly submitted one; a cluster administrator can therefore persist a malformed regex that the webhook should have rejected. Because the Ingress hostname validator in validate_hostnames.go discards the regular-expression compilation error and treats every hostname as unmatched, the affected tenant's Ingress create and update operations are subsequently blocked until an administrator repairs the Tenant spec. The issue requires Tenant update privileges (PR:H in the assessed CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H vector), is confined to tenants that use IngressOptions.AllowedHostnames.Regex, and no public exploit code has been identified at time of analysis; it is fixed in 0.13.7.
RemediationAI
Vendor-released patch: upgrade Project Capsule to 0.13.7 (https://github.com/projectcapsule/capsule/releases/tag/v0.13.7), which contains the fix from PR https://github.com/projectcapsule/capsule/pull/1983 and commit 8d89d6865df6f41c7faa22fc9e807a57b01bfd0e; the fix corrects the new/old parameter ordering in hostnameRegexHandler.OnUpdate and adds proper regex-compilation checks. Where immediate upgrade is not possible, administrators can break the failure chain by editing the affected Tenant to remove or correct the malformed Spec.IngressOptions.AllowedHostnames.Regex - doing so restores Ingress creation for that tenant but also lifts the hostname allow-listing constraint until the regex is reinstated correctly, so the corrected pattern should be reapplied promptly. As a preventive compensating control, tighten Kubernetes RBAC so that only a small, trusted set of administrators holds update/patch rights on capsule.clastix.io Tenant custom resources (or the v1beta2 equivalent), since the issue is only reachable by a principal with Tenant update privileges and cannot be triggered by unprivileged tenant users or unauthenticated remote callers; the trade-off is that legitimate tenant self-service changes to ingress hostname policy must then be routed through that administrative group. No vendor-released patch is required beyond 0.13.7 and no separate workaround changes are needed once that version is deployed.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Capsule is a multi-tenancy and policy framework layered on top of Kubernetes, implemented largely as controller-runtime admission webhooks plus controllers that reconcile Tenant custom resources into namespaces, RBAC, and network/ingress policy. The defect is CWE-697 (Incorrect Comparison): in internal/webhook/tenant/validation/hostname_regex.go, the OnUpdate handler receives the new and old Tenant parameters in reversed positions, so the admission check compiles and validates the stale AllowedHostnames.Regex from the existing object instead of the value being submitted. This is strictly an update-path bug - the create path and the initial valid state are unaffected - and it means the webhook can accept an invalid regular expression (for example an unbalanced parenthesis) that it would otherwise reject. The second half of the failure chain lives in validate_hostnames.go, which evaluates the stored pattern against incoming Ingress hostnames but ignores the error returned by the regex evaluation; an uncompilable pattern therefore matches nothing, and every Ingress for that tenant is denied. The fix in v0.13.7 also hardens the sibling forbidden-labels and forbidden-annotations regex handlers so that empty expressions are skipped and invalid expressions are denied with an explicit 'unable to compile regex' message, indicating the root cause was a shared weakness in regex validation within these admission handlers. The CPE cpe:2.3:a:projectcapsule:capsule:*:*:*:*:*:*:*:* is an unbounded wildcard that does not encode the actual 0.13.0-0.13.6 range, so version scoping must come from the advisory rather than the CPE string.
Know when Capsule gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H
Requires Tenant-update (cluster-admin) privilege so PR:H; network Kubernetes API path AV:N/AC:L; pure availability A:H with C:N/I:N; S:C since the broken config denies Ingress to separate tenant namespaces.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
Capsule is a multi-tenancy and policy-based framework for Kubernetes. From 0.13.0 until 0.13.7, hostnameRegexHandler.OnUpdate in internal/webhook/tenant/validation/hostname_regex.go reverses the new and old Tenant parameters and validates the previous AllowedHostnames.Regex instead of the submitted value. A cluster administrator can therefore store a malformed AllowedHostnames.Regex after the webhook accepts the update based on stale valid state. Subsequent Ingress creation or update reaches validate_hostnames.go, which evaluates the malformed pattern, ignores the regular-expression error, and treats every hostname as unmatched, blocking Ingress operations for the affected tenant until an administrator repairs the Tenant configuration. This issue is fixed in version 0.13.7.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Capsule is a multi-tenancy and policy-based framework for Kubernetes. Rated high severity (CVSS 8.8), this vulnerability
Capsule, the Kubernetes multi-tenancy and policy framework (projectcapsule/capsule), mishandles case-insensitive sorting
Capsule 0.13.0 through 0.13.6 accepts a malformed ForbiddenAnnotations.Regex on Tenant updates because the update webhoo
Privilege escalation in Capsule (Kubernetes multi-tenancy framework) versions 0.13.0-0.13.7 allows authenticated Tenant
Capsule is a multi-tenancy and policy-based framework for Kubernetes. Rated high severity (CVSS 8.8), this vulnerability
Capsule's node admission webhook can be crashed cluster-wide by a Cluster Admin who stores a malformed regular expressio
capsule-proxy is a reverse proxy for Capsule kubernetes multi-tenancy framework. Rated medium severity (CVSS 4.3), this
EUVD-2026-83166
GHSA-f94q-w3w8-cj67
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB