CVE-2026-15467 in the trustyai operator's LMEvalJob controller is being framed as a privilege escalation via sidecar containers. That's the surface-level reading. The deeper issue is that the operator has become the attack surface for bypassing cluster-wide security policies that administrators believe are enforced on all workloads—including PodSecurity admission, OPA/Gatekeeper, and PodSecurityPolicies.
When you grant an operator CREATE/UPDATE permissions on pods, admission webhooks simply do not fire on the operator's writes. The operator operates in a trust domain where policy enforcement was never designed to land. This means every operator that synthesizes pod specs from user-supplied CRD fields is a potential policy bypass vector. The LMEvalJob controller accepts sidecar configurations from users and writes them directly into pod specs without those inputs passing back through admission. The cluster sees an authenticated user creating a custom resource; it does not see that user's input flowing through a trusted operator to generate a workload that sidesteps every policy gate.
This is not a new vulnerability class—it's the third mutation of the same genetic flaw. PodSecurityPolicy was deprecated precisely because operators could synthesize pods that bypassed it. The ecosystem replaced PSP with PodSecurity Admission and policy engines like Gatekeeper, but the root cause was never addressed: operators with elevated service account permissions writing pod specs will always route around workload-level enforcement. The trust boundary assumption— that operators function as the enforcement point themselves—rotted as operators evolved from reconciliation loops into ergonomic API surfaces that accept user-controlled pod spec fields.
For clusters running trustyai in production AI pipelines, the impact extends beyond arbitrary code execution. An attacker with permission to create LMEvalJob resources can inject sidecars into evaluation workloads, intercepting model inputs, poisoning outputs, or exfiltrating training data. This converts limited CRD permissions into a cluster-level compromise vector.
Check your operators now: examine whether any controller with pod CREATE/UPDATE permissions accepts user-supplied fields that map directly to pod spec (containers, volumes, security contexts, sidecars). If the CRD exposes these fields, they bypass admission regardless of how hardened your cluster policies are. The fix for this CVE may be straightforward—constrain the sidecar injection logic—but the systemic risk is that the operator trust model and the cluster policy model were never reconciled architecturally, and that gap has been accumulating since the operator pattern began.