CVE-2026-1784: OpenShift Route Path Traversal Vulnerability

CVE-2026-1784 Overview

CVE-2026-1784 affects the Route resource in OpenShift, which exposes pods at a subdomain through HAProxy. The vulnerability stems from insufficient validation of the spec.path YAML stanza within a Route document. An authenticated user with permission to create or modify Route resources can inject arbitrary HAProxy configuration directives. The flaw is classified under [CWE-15] (External Control of System or Configuration Setting). Successful exploitation impacts the confidentiality, integrity, and availability of the routing tier and the workloads it serves.

Critical Impact
Controlled injection of HAProxy configuration through spec.path enables a low-privileged tenant to alter routing behavior for the entire cluster ingress layer.

Affected Products

Red Hat OpenShift Route resource handling
HAProxy-based ingress controllers deployed by OpenShift
Multi-tenant OpenShift clusters where users can create Route objects

Discovery Timeline

2026-06-02 - CVE-2026-1784 published to NVD
2026-06-02 - Last updated in NVD database

Technical Details for CVE-2026-1784

Vulnerability Analysis

The OpenShift Route resource lets tenants declare how external traffic reaches pods through a subdomain managed by an HAProxy ingress controller. The Route admission and rendering logic translates fields such as spec.host, spec.path, and TLS settings into HAProxy backend and ACL directives. The spec.path field is intended to constrain routing to a URL prefix.

The validation applied to spec.path does not adequately restrict characters and sequences that carry meaning inside the generated HAProxy configuration. As a result, crafted path values are written into the rendered configuration verbatim. The injected content executes within the HAProxy process context once the configuration is reloaded.

The attack requires local access with low privileges and no user interaction. The scope changes because a tenant-controlled Route impacts the shared ingress process and other tenants routed through the same HAProxy instance.

Root Cause

The root cause is improper neutralization of input used to construct a configuration file. The Route controller treats spec.path as a routing prefix but writes it into HAProxy directives without enforcing a strict character set or escaping reserved tokens. This allows configuration directives, ACL expressions, or backend overrides to be embedded inside what should be a path literal.

Attack Vector

An authenticated user with rights to create or update a Route in any namespace submits a Route manifest containing a malicious spec.path value. When the ingress controller reconciles the Route and reloads HAProxy, the injected directives become part of the active configuration. The attacker can redirect traffic, expose internal backends, weaken TLS handling, or disrupt routing for other tenants. Exploitation does not require network-level access to the ingress node because the injection happens through the Kubernetes API. Refer to the Red Hat CVE Advisory and the Red Hat Bug Report for vendor-specific technical detail.

Detection Methods for CVE-2026-1784

Indicators of Compromise

Route objects whose spec.path contains whitespace, newline characters, backticks, or HAProxy keywords such as acl, http-request, use_backend, or bind.
Unexpected backends, ACLs, or http-request rules appearing in the rendered haproxy.config on router pods.
HAProxy reload events that correlate in time with Route create or update events from low-privileged service accounts.

Detection Strategies

Audit the Kubernetes API server log for routes.route.openshift.io create and update events and parse the spec.path value for non-path characters.
Diff the rendered HAProxy configuration on router pods against a known-good baseline after each reconciliation.
Apply an admission policy that rejects Route objects whose spec.path does not match a strict regular expression for URL paths.

Monitoring Recommendations

Forward router pod logs and HAProxy reload events to a centralized logging pipeline and alert on parser errors or unusual directive counts.
Monitor identity activity for users or service accounts that create Route resources outside of normal change windows.
Track ingress traffic patterns for sudden shifts in backend selection or TLS termination behavior that may indicate configuration tampering.

How to Mitigate CVE-2026-1784

Immediate Actions Required

Apply the Red Hat security update for the OpenShift router component as referenced in the Red Hat CVE Advisory.
Restrict the routes.route.openshift.io create and update verbs to trusted namespaces and identities using RBAC.
Review existing Route objects across all namespaces for malformed spec.path values and remove or remediate any suspicious entries.

Patch Information

Red Hat tracks the fix through the advisory and bug entries listed above. Consult the Red Hat Bug Report for the specific OpenShift versions and router image tags that contain the corrected validation for spec.path. Update both the cluster control plane and the ingress router image to a fixed release, then force a router rollout to pick up the new validation logic.

Workarounds

Deploy a validating admission webhook or OPA/Gatekeeper policy that enforces a strict path regex such as ^/[A-Za-z0-9._~!$&'()*+,;=:@/%-]*$ on Route spec.path.
Limit Route creation to a small set of platform administrators until the patched router image is deployed cluster-wide.
Segment tenants across dedicated ingress controllers so that any successful injection is contained to a single tenant's HAProxy instance.

bash

# Example Gatekeeper-style constraint snippet enforcing a safe path pattern
# Reject Route objects whose spec.path contains characters outside the URL path set
spec:
  match:
    kinds:
      - apiGroups: ["route.openshift.io"]
        kinds: ["Route"]
  parameters:
    pattern: "^/[A-Za-z0-9._~!$&'()*+,;=:@/%-]*$"