CVE-2026-1784: OpenShift Ingress Operator — RCE via HAProxy config injection in the Route spec.path
2 June 2026. Red Hat has published CVE-2026-1784, a remote code execution in the OpenShift ingress operator (ose-cluster-ingress-operator). A Route makes pods reachable at a subdomain through HAProxy — and the checks on a Route document's spec.path field were insufficient, so controlled content can flow into the HAProxy configuration generated for the shared router. A tenant allowed to create or edit Route objects in its namespace can thereby manipulate the cluster-wide router's HAProxy config; CVSS 8.8 with Scope: Changed, because the impact leaves the tenant's own namespace. The fix ships via Red Hat errata for the relevant OpenShift 4.x line.
TL;DR — the 90-second summary
What was published?
CVE-2026-1784 (Red Hat, 02 June 2026). Class: config injection → remote code execution. Mechanism: the spec.path field of an OpenShift Route object is insufficiently validated; controlled text flows into the HAProxy configuration generated by the ose-cluster-ingress-operator for the shared router and can inject directives there.
How severe?
High — Red Hat: CVSS v3.1 8.8 (AV:L/AC:L/PR:L/S:C/C:H/I:H/A:H), CWE-15 (External Control of System or Configuration Setting). Entry condition: write access to Route objects in a namespace (a standard tenant right in shared clusters). Scope: Changed — the impact leaves the tenant namespace and hits the cluster-wide ingress.
Which OpenShift versions are affected?
Red Hat OpenShift Container Platform 4.x via the ose-cluster-ingress-operator (HAProxy-based router). The exact list of fixed errata versions per 4.x minor is in the Red Hat errata/RHSA for the CVE — check it per cluster before the patch run.
Am I affected?
You are affected if you run OpenShift (self-hosted, ROSA, ARO, Dedicated) with the standard HAProxy router and several teams/tenants may create Route objects. Single-tenant clusters where only platform administration writes routes have a smaller blast radius — the patch is still mandatory.
Immediate mitigation?
Move to the errata version provided for your 4.x line (cluster update via the OpenShift update channel). Until then: restrict route creation via admission control (e.g. a validating policy on spec.path that allows only a strict path schema) and review which ServiceAccounts/groups hold routes write access.
Criticality?
See hero badge high (Red Hat CVSS 8.8). No publicly documented in-the-wild exploitation as of 02 June, no KEV listing. The exploit path is methodically clear (controlled spec.path → HAProxy directive); act promptly in multi-tenant clusters.
What happened
On 2 June 2026 Red Hat published CVE-2026-1784 for the OpenShift ingress operator. The operator (ose-cluster-ingress-operator) manages the HAProxy-based router that distributes external requests to the pods in the cluster. The central abstraction for this is the Route object: a tenant describes the subdomain and path under which its service should be reachable, and the operator translates these objects into an HAProxy configuration.
The bug sits in exactly this translation. The checks on a Route document's spec.path field were insufficient, so tenant-controlled content from spec.path could flow into the generated HAProxy configuration without neutralising the special characters or line structures that HAProxy interprets as configuration syntax. That turns an otherwise harmless routing field into a configuration injection: the attacker writes not just a path but smuggles additional HAProxy directives into the shared router's config.
The real severity comes from the shared nature of the router. The HAProxy router is a cluster-wide component used by all tenants together. A route lives in a tenant's namespace, but its effect via the injected config lives in the router pod responsible for the entire cluster ingress. That is exactly what the CVSS vector reflects with Scope: Changed: a low-privileged actor (PR:L — write access to Route is an ordinary tenant right in shared clusters) achieves an effect outside its security scope. With C:H/I:H/A:H the worst-case consequence is code execution in the router context, i.e. full access to the ingress path of all tenants.
The fix corrects the validation of the spec.path field so that tenant-controlled content can no longer be interpreted as HAProxy syntax. It ships via Red Hat errata (RHSA) for the relevant OpenShift 4.x line; the exact fixed build versions per minor are in the Red Hat CVE entry and the associated errata.
Technical assessment
Structurally, CVE-2026-1784 is a classic template/config-injection finding at a trust boundary between tenant and platform. The ingress operator takes declarative, tenant-written objects (Route) and renders an imperative configuration file (haproxy.config) for a privileged, shared component. Every field that flows unescaped from the tenant object into that file is a potential injection point — the same class as SQL injection (data interpreted as code) or the classic nginx/Apache config-injection flaws via unclean annotation handling in other ingress controllers.
The second point is the scope asymmetry that makes this class particularly nasty in Kubernetes/OpenShift. RBAC separates tenants cleanly at the object level: a tenant may write Route objects in its namespace but not in others. That separation does not help here, because all routes are rendered into the same shared HAProxy config. The security boundary RBAC draws at the API level is torn down again at the render level. The generic lesson: where many low-privileged actors feed into a shared privileged artifact generation, neutralisation must sit at the render step, not at the RBAC boundary.
Third, the entry condition for triage. PR:L and AV:L mean concretely: the attacker needs a valid account with routes write access in some namespace — not cluster admin, not network access to internal components. In a typical multi-tenant OpenShift (several teams, CI ServiceAccounts, self-service namespaces) that is the norm. In a single-tenant cluster where only platform administration writes routes, the blast radius is smaller — the attacker would already need platform rights. An oc get rolebindings,clusterrolebindings -A looking at the routes verb answers who can even enter the path.
Who is affected
Affected
Not affected
Condition
OpenShift 4.x with the standard HAProxy router (ose-cluster-ingress-operator) before the errata fix
Clusters on the fixed errata version of the relevant 4.x line
Patch level of the ingress operator / router
Multi-tenant clusters where several teams/CI ServiceAccounts may write Route objects
Single-tenant clusters where only platform administration writes routes
Distribution of the routes write right (RBAC)
Self-hosted OCP, ROSA, ARO, OpenShift Dedicated with the classic router
Clusters with exclusively Gateway-API/third-party ingress without the HAProxy router path
Ingress architecture in use
Important for context: the flaw affects the router, not the individual application. So you do not patch a workload but the cluster (ingress operator). If you run several clusters, treat each as its own affected asset; a fixed cluster says nothing about the others.
Impact and immediate measures
The impact is not “one compromised route” but “a compromisable ingress layer for the whole cluster”. Whoever can run code in the router context or manipulate the HAProxy config sits on the path through which all tenants' external traffic flows — with the corresponding options for redirection, eavesdropping and denial of service.
Operational Decision Block
Patch immediately if: a production multi-tenant cluster is affected in which non-administrative teams or CI ServiceAccounts may write Route objects.
A maintenance window suffices if: a single-tenant cluster is affected in which only platform administration writes routes — the patch stays mandatory, the acute lever is just smaller.
Additionally harden if the patch is not immediately possible: place a validating admission policy (OpenShift admission / Kyverno / Gatekeeper) on Route.spec.path that allows only a strict path schema (e.g. ^/[A-Za-z0-9/_-]*$) and rejects anything with HAProxy special characters or line breaks.
In this order. First, inventory: record every OpenShift cluster and its 4.x minor version, compare the ingress operator's errata level against the Red Hat CVE entry. Second, RBAC review: oc get rolebindings,clusterrolebindings -A -o wide and check which subjects hold the routes write right — that is the list of actors who can enter the exploit path. Third, patch via the cluster update channel to the fixed errata version. Fourth, stopgap admission policy for clusters that cannot patch immediately. Fifth, audit existing routes: check existing Route objects for suspicious spec.path values with special characters, line breaks or HAProxy keywords.
This article reflects my technical and strategic assessment. It is not legal advice and not a data-protection impact assessment.
Detection / verification
Detection has two layers: “am I on a vulnerable operator level” (the patch question) and “has someone already created a suspicious route” (the audit question).
Check snippets (copy/paste):
# 1) Which OpenShift version / ingress operator level?
oc version
oc get clusteroperator ingress -o jsonpath='{.status.versions}'
# 2) Who may write routes? (exploit-path holders)
oc get clusterrolebindings,rolebindings -A -o wide | grep -iE 'route|edit|admin'
# 3) Check existing routes for suspicious spec.path values
oc get route -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.path}{"\n"}{end}' \
| grep -nE '[{};#]|http-request|acl |backend |server '
# 4) Router pods (audit)
oc -n openshift-ingress get pods
What is suspicious:spec.path values containing line breaks, curly braces, semicolons, # comments or HAProxy keywords (http-request, acl, backend, server, bind). A legitimate path is a simple URL path without these characters. For ongoing detection, run an admission policy in audit mode that logs such values before blocking them.
Operator recommendation
Mittelstand
Anyone consuming OpenShift as a managed offering (ROSA, ARO, OpenShift Dedicated) should first check whether the provider has already patched the ingress operator — for managed offerings the cluster-operator patch often sits with the provider. For self-run clusters: schedule the update via the standard update channel and set the admission policy as a stopgap until then. The RBAC review is the quick win here: historically, more ServiceAccounts are often allowed to write routes than necessary.
Enterprise / multi-tenant
On shared platforms, CVE-2026-1784 is a reason to harden the tenant-to-router boundary fundamentally: validating admission policies on Route.spec.path (and related fields) as a permanent control, not just a stopgap; least-privilege review of the routes rights; and, where possible, sharded routers per tenant class so an injection does not hit the entire cluster-wide ingress.
Declarative stacks / GitOps
If you roll out routes via GitOps (Argo CD / Flux), add path validation in the CI pipeline (policy-as-code, e.g. Conftest/OPA against the Route manifests) — so a malicious spec.path is rejected in the pull request before it reaches the cluster.
Frequently asked questions about CVE-2026-1784
We use the Gateway API instead of Routes — does this affect us?+
The specific finding hangs on the Route object and the HAProxy router. Pure Gateway-API/third-party ingress paths without the classic router are not affected via this CVE — but check whether the HAProxy router still runs in parallel in your cluster.
Does a Web Application Firewall help?+
Only to a limited extent. The attack runs via the Kubernetes API (writing a Route object), not via HTTP request smuggling at the application. The effective control is admission control at the API, not the WAF in the data path.
How do I detect an exploitation attempt?+
By Route.spec.path values with characters that have no place in a URL path — line breaks, {};#, or HAProxy keywords like http-request/acl/backend. The detection snippet above lists such routes cluster-wide.
Are ROSA/ARO/Dedicated clusters affected?+
Yes, provided they use the classic HAProxy router. For managed offerings the provider often patches the cluster operator — check the status with your provider and add an admission policy where you have control yourself.
Is RBAC enough to mitigate the flaw?+
RBAC shrinks the blast radius (whoever cannot write routes cannot inject) but does not close the flaw. Because all routes are rendered into the same shared HAProxy config, the actual control is neutralisation at the render step (the patch) or an admission policy on spec.path.
Do I have to patch every application or just the cluster?+
Just the cluster. The flaw sits in the ingress operator/router, not in the workloads. You move the ose-cluster-ingress-operator to the fixed errata version of your 4.x line — the individual applications stay unchanged.
Bottom line
CVE-2026-1784 is the recurring lesson of the multi-tenant platform: a security boundary cleanly drawn at the API level (RBAC) can collapse again at the render level (shared HAProxy config) when tenant-controlled content flows unescaped into a privileged artifact. The fix is a normal cluster update; the stopgap is an admission policy on spec.path; the lasting gain is the discipline of treating every tenant-to-platform render point as an injection boundary. Risk soberly: high for shared clusters with distributed route rights, smaller for strictly single-tenant clusters — triage via oc get rolebindings separates the two classes in minutes.
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.
![[Translate to English:] Foto von Kai Ole Hartwig.](/fileadmin/_processed_/e/9/csm_ole-neu_8000c3dfab.avif)