IBM Portieris CVE-2026-18544

Exploitation requires a valid Kubernetes account with at least pod creation (or equivalent workload resource) permissions within the cluster where IBM Portieris 0.5.0-0.14.2 is deployed as an admission controller. The CVSS vector PR:L confirms low-privilege authenticated access is the threshold - unauthenticated exploitation is not possible. No special non-default Portieris configuration appears required; the flaw exists in the admission controller's core authorization logic for owner references, meaning any cluster relying on Portieris for image policy enforcement is potentially exposed. Exploitation is constrained to environments where Portieris is actually deployed and active; clusters using alternative admission controllers are unaffected.

The CVSS 8.1 score reflects a network-exploitable flaw (AV:N/AC:L) requiring only low-privilege authentication (PR:L), with High Confidentiality and High Integrity impacts - consistent with the ability to run arbitrary, potentially malicious container images inside a cluster. There is no CISA KEV listing and no public POC identified, which moderates near-term exploitation urgency relative to the raw score. However, for organizations using Portieris as a critical security control boundary - particularly those enforcing image signing in regulated, zero-trust, or supply-chain-sensitive environments - the functional impact is severe: the entire control is negated. EPSS data was not provided; without it, exploitation probability cannot be quantitatively assessed. The attack complexity is genuinely low once authenticated access is obtained, meaning any cluster user meeting the PR:L threshold presents a realistic threat actor.

An authenticated Kubernetes user with pod creation rights crafts a pod manifest containing manipulated owner reference metadata and submits it to the API server. Portieris's admission webhook processes the request but fails to correctly authorize the owner reference relationship, causing its image policy logic to be skipped. The attacker's pod - referencing an untrusted, unsigned, or policy-violating container image - is admitted and begins executing within the cluster.