CVE-2026-18617 is being undersold as a DSN injection vulnerability. The real issue is that a namespace-scoped user can manipulate the DSPO operator's security posture without triggering any detection controls—and the operator's RBAC permissions turn that manipulation into cluster-admin access.
The attack works because customExtraParams bridges namespace-scoped input directly into a component running with cluster-wide privileges. When a namespace editor injects 'allow-local-infile=1' into the DSN, the operator reads arbitrary files from its own filesystem and exfiltrates them through MySQL. Combined with the operator's over-privileged service account, the escalation chain (local file read → service account token → cluster-admin) completes silently. No audit log entry distinguishes "namespace editor configuring their pipeline" from "namespace editor pivoting to cluster-admin."
The design assumption that custom database parameters are safe to pass through is the architectural failure. The operator's RBAC manifest was almost certainly authored when DSPO was a cluster-admin-only tool—before namespace-scoped users could influence its configuration. Nobody audited the permissions when the deployment model shifted to multi-tenant OpenShift. The customExtraParams field is a fossil from an era when the operator ran inside a trust boundary that no longer exists.
Three questions should drive your response: First, does your operator accept configuration fields from namespace-scoped users that, if manipulated, could influence security-sensitive behavior of the operator pod itself? Second, when were the operator's RBAC permissions last audited against the current deployment model—specifically, did they survive unchanged from an earlier era? Third, do your admission controls check not just "can this user write this CRD?" but "does writing this CRD require privileges beyond this namespace?"
The fix requires more than parameter stripping. You need a retroactive RBAC audit to identify other permissions that survived from earlier deployment assumptions, and you should assume that other operators built on the same Operator SDK patterns contain analogous customExtraParams-style fields. The SDK makes exposing these fields trivial while making field-level validation effortful—that asymmetry is a design choice with predictable consequences the industry has now observed multiple times.