OpenShift flaw CVE-2026-1784: low-privilege users can hijack cluster traffic

Red Hat's enterprise container platform "OpenShift" has a flaw where crafting an app-publishing setting (a Route) lets a user slip extra directives into the configuration of the shared router that handles traffic at the entrance (CVE-2026-1784). The CVSS severity is 8.8 out of 10 (High). In environments where a single cluster is shared by several departments or partners, a user who only has rights over their own area could reach into traffic destined for other apps.

An OpenShift "Route" is the setting that publishes an app running inside the cluster at an externally reachable URL (a subdomain and path). That setting is fed into the shared load balancer (the router) standing at the cluster's entrance, where internally it is turned into a configuration file for the popular software HAProxy. Here, the check performed before that conversion was too weak, so values a user supplies can break into the configuration file. This article covers what happens, whether you are affected, and what to do now.

The flaw at a glance

First, the key facts. The defining trait is that the starting point of the attack is not "anyone over the internet," but a user who can log in to the cluster and has enough privilege to create a route in their own area. That is exactly why it bites hardest in environments where many teams share a single cluster.

The reason the CVSS stops at 8.8 rather than a perfect 10.0 is that the attack requires "a login to the cluster" and "permission to create a route." It is not the kind of flaw a stranger can exploit one-sidedly from the internet. Yet that prerequisite is routinely met on shared clusters, because developers creating routes in their own namespace (their assigned working area) is everyday operation. The fact that the impact reaches beyond the attacker's own area (S:C, scope changed) was also weighed, landing the score at a High 8.8.

When the reception sign gets rewritten, where does the traffic go

What makes this flaw nasty is that the stepping stone is not some grand admin privilege, but the everyday "publish my own app" permission a developer already holds. The people who put a price on that are a malicious contractor sharing the same cluster, an initial-access broker who slipped in with a stolen developer account, and ransomware crews hunting corporate container platforms. What they get their hands on is the login IDs and passwords, business data, API tokens, and the contents of inquiry or payment traffic flowing into the internal web app run by the team next door. The moment a crafted route definition is loaded into the shared router, traffic that was meant for a different app is quietly re-pointed to a fake destination the attacker has prepared.

It does not stop at one step. Using the IDs and passwords captured at the fake destination to impersonate a legitimate user, the attacker logs in to internal systems and spreads sideways into other servers and databases. Stolen credentials are resold on the dark web, and the buyer uses them as a foothold to encrypt the whole cluster, halt operations, and extort twice by dangling the "publication" of exfiltrated customer data. On a platform where several partners' systems ride on one cluster, the damage will not end with the single operator.

The cleanup falls on the platform team running the cluster, the systems integrator that built it, and management. If eavesdropped traffic leaks personal data, a duty to report to the data-protection authority and to notify the individuals arises, on top of explanations to co-tenant partners, damages, and lost trust. What never appears in the number 8.8 is the operational cost: once the "entrance" of a shared platform loses trust, every tenant running on top of it falls under suspicion, and recovery may force the whole company's services offline for verification. Whether you can tighten permission design and apply the fix now is what decides the safety of those involved.

What are OpenShift's "Route" and "router" in the first place

OpenShift is Red Hat's enterprise "Kubernetes" platform. Kubernetes is the machinery for running large numbers of apps packed into small boxes (containers), and OpenShift is the product that makes it palatable for enterprises. In large companies, it is common to run "multi-tenant," where one big cluster (a fleet of servers) is shared among several departments or partners, with each team assigned its own working area called a "namespace."

Within that, a "Route" is OpenShift's own setting for publishing an app running inside the cluster at an externally reachable URL. The user specifies "send access arriving at this address and this path to this app" via fields such as spec.host and spec.path. It is the setting a developer writes as a matter of course when putting their app out into the world.

What actually handles those route directions is the "router," the load balancer shared by all tenants that stands at the cluster's entrance. Its true form is the standard software HAProxy, and the routes every tenant creates are all written together into a single HAProxy configuration file. In other words, the values you write in a route are transcribed onto a "reception sign" everyone shares. That is precisely why, when the check before that transcription is weak, extra directives can be slipped onto the sign.

Inside CVE-2026-1784: weak spec.path validation injects HAProxy config

According to the NVD (the U.S. vulnerability database) and Red Hat's note, the problem lies in a route's spec.path field. The NVD describes it as: "the checks performed on the spec.path YAML stanza in a Route document was insufficient and could allow a controlled injection of the HAProxy configuration." Normally spec.path is just a routing string saying "send access arriving at this path here," but because its contents were not strictly validated, directives unintended as a routing path could be slipped in when it is transcribed into the configuration file.

It is classified as CWE-15 (External Control of System or Configuration Setting), the family of flaws where a value a user enters directly sways the system's configuration. Being able to break into the shared router's config means that a setting which should stay confined to your own namespace can reach into how traffic destined for other tenants is handled. In the CVSS breakdown AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, S:C (scope changed) captures exactly this "impact spreads beyond your own area" property, and C:H/I:H/A:H indicates that eavesdropping, tampering, and service disruption are all possible.

The affected product is Red Hat OpenShift Container Platform 4. Red Hat is rolling out updates containing the fix (errata / RHSA) to each supported 4.x release in turn. Whether a fix exists for your version, and its exact number, is best confirmed on Red Hat's official CVE page. Note that this was found and reported by Red Hat itself; it did not come to light through an external breach.

Has it been exploited?

Let us separate what is known from what is not yet confirmed.

Quick check: are you affected?

Even on the same OpenShift, the risk varies with how the cluster is used and how permissions are handed to users. Find your situation in the table below.

The biggest concern is a shared cluster that hands "create a route in your own namespace" widely to developers and contractors. If you use a managed edition in the cloud (Red Hat's ROSA, Microsoft's ARO, etc.), the platform-side fix is handled by the provider, so checking each vendor's security notice is the quickest route.

What IT teams should check right now

The top priority is applying the fix errata that matches your OpenShift version. Check Red Hat's official CVE page for whether an update is out for your version, and apply it on your maintenance schedule. If circumstances prevent an immediate update, a useful stopgap is to review who can create and modify routes. Narrow it to users who truly need it, and check that it is not handed broadly to contractors or temporary accounts.

It also helps to inspect the shared router's HAProxy config and the audit logs of route creation/modification for any unfamiliar spec.path values or unnatural routing directives. For organizations running multi-tenant, this is a good moment to revisit the design itself: "how far should one cluster be shared," and "where should tenants be isolated from one another." To track vulnerabilities in widely used products together, see our roundup of major 2026 H1 vulnerabilities as well.

Around the same time, flaws targeting the "entrance" of app platforms have kept coming. The signing-key leak in an authentication server, Cloud Foundry's CVE-2026-40965, is one of them, and the weight of protecting the roots of a shared platform keeps growing.

FAQ

Summary

CVE-2026-1784, found in OpenShift, is a flaw where weak validation of the spec.path in an app-publishing setting (a Route) lets a user slip extra directives into the HAProxy config of the shared router that handles traffic at the entrance. Because the attack requires "a cluster user able to create routes," the CVSS is 8.8 rather than the maximum — but that prerequisite is routinely met on clusters shared by multiple teams. If the injection succeeds, traffic destined for other tenants can be eavesdropped or re-pointed to another destination. The affected product is OpenShift Container Platform 4, and Red Hat is providing fix errata for the 4.x line. Apply the fix for your version first, and if you cannot update immediately, start by auditing who can create and modify routes.

References

• ▸NVD - CVE-2026-1784 (OpenShift Route spec.path / HAProxy config injection)
• ▸Red Hat - CVE-2026-1784 (affected versions and fix errata)
• ▸Red Hat Bugzilla #2436075
• ▸Red Hat Docs - Configuring Routes (OpenShift 4.20)
• ▸GitHub - openshift/router (HAProxy-based router)
• ▸HAProxy official site