Ansible Operator Plugins EUVD-2026-102157

Requires an authenticated Kubernetes user (PR:L) who holds permission to create or modify a custom resource reconciled by an affected Ansible-based operator (e.g., components shipped in Red Hat Ansible Automation Platform 2, Advanced Cluster Management for Kubernetes 2, or the Migration Toolkit operators). The specific condition is that the operator passes attacker-controllable CR spec values into Ansible/Jinja2 template evaluation without sanitization, so exploitation depends on the operator consuming those fields - this aligns with the vendor's AC:H rating. Limiting factors: the attacker must already possess valid cluster credentials with CR write access in a managed namespace; purely anonymous or read-only users cannot trigger it, and operators that do not expose user-controlled values to templating are not affected.

This is a genuinely high-priority flaw rather than a CVSS-inflated one, but with an important authentication caveat. The CVSS vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H, score 8.5) confirms a network-reachable, authenticated (PR:L) attack requiring no user interaction, with a scope change (S:C) and full confidentiality/integrity/availability impact - consistent with the description's claim that a low-privileged Kubernetes user can escalate to the operator's cluster-wide service account. The high value comes from the scope change plus the privilege-escalation outcome: a minor tenant foothold converts into cluster-admin-equivalent control. However, no EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active exploitation or mass-scanning pressure; this currently reads as a serious-but-not-yet-weaponized issue. The vendor's AC:H rating tempers the picture - it implies exploitation is not trivially reliable (likely depending on which CR fields the operator passes unsanitized into Jinja2). The one signal to reconcile: AV:N is accurate in that the Kubernetes API is network-facing, but exploitation still requires authenticated API access with permission to create or modify the relevant custom resources, so realistic exposure is to users/tenants who already hold some cluster credentials, not the anonymous internet. No SSVC decision data was supplied.

A low-privileged tenant with permission to create or edit a custom resource in a namespace managed by a vulnerable Ansible-based operator submits a CR whose spec values embed a Jinja2 expression. The operator processes those values without sanitization, evaluating the expression inside the operator pod and running attacker-controlled code under the operator's service account, which holds cluster-wide permissions. No public exploit was identified at time of analysis, and the vendor-assigned AC:H suggests exploitation reliability depends on which CR fields reach the template engine.