Capsule CVE-2026-61794

Requires Capsule 0.13.0 through 0.13.6 and an actor with permission to update a Tenant custom resource (tenant owner or cluster admin with Tenant write access) - this is a privileged, largely self-inflicted denial of service. The specific trigger is setting Spec.NamespaceOptions.ForbiddenAnnotations.Regex to a value that is not a valid Go regexp (e.g. '(', '[', '(?P<') while leaving ForbiddenLabels.Regex valid so the update webhook accepts it; the panic only manifests later, on namespace create/update for the affected tenant. Limiting factors: high privilege requirement (PR:H, no unauthenticated path), impact confined to the affected tenant's namespace operations rather than the whole cluster, and no confidentiality or integrity impact.

This is a genuine but low-urgency availability issue, not a high-impact priority. The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H, base 6.8) correctly reflects a pure denial-of-service (C:N/I:N) that requires high privileges (PR:H) - specifically the ability to update a Tenant custom resource in Capsule. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis' (the linked PR contains only e2e regression tests, which validate the fix rather than weaponize the flaw). The signals are internally consistent: a config-validation bug reachable only by a privileged tenant/cluster administrator, whose worst outcome is that Capsule denies namespace create/update operations for the affected tenant. The tag 'Information Disclosure' CONFLICTS with the vector (C:N means no confidentiality impact) - this is a mislabeling, not a confidentiality issue. The S:C (scope change) rating is defensible (a webhook mis-validation causes denial in downstream namespace operations) but arguable; S:U would also be reasonable, marginally lowering the score.

A user with rights to update a Tenant object (e.g., a delegated tenant owner or cluster admin) sets ForbiddenAnnotations.Regex to a malformed pattern such as '(' while keeping the labels regex valid; the update webhook mistakenly validates only ForbiddenLabels.Regex and accepts it. Later, any namespace create or update for that tenant reaches pkg/api/forbidden_list.go, where regexp.MustCompile panics on the stored bad expression and blocks the operation, denying namespace management for the tenant. No public exploit code exists; the only demonstration is the vendor's e2e test using invalid regexes like '(', '[', '*invalid'.