CVE-2026-1784: OpenShift Ingress-Operator — RCE über HAProxy-Config-Injection im Route-spec.path

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

CVE-2026-1784 (Red Hat, 02.06.2026). Klasse: Config-Injection → Remote Code Execution. Mechanismus: Das Feld spec.path eines OpenShift-Route-Objekts wird unzureichend validiert; kontrollierter Text fließt in die vom ose-cluster-ingress-operator generierte HAProxy-Konfiguration des gemeinsamen Routers und kann dort Direktiven einschleusen.

Wie schwer?

Hoch — 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). Eintrittsschwelle: Schreibrecht auf Route-Objekte in einem Namespace (Standard-Tenant-Recht in geteilten Clustern). Scope: Changed — die Wirkung verlässt den Tenant-Namespace und trifft den cluster-weiten Ingress.

Welche OpenShift-Versionen sind betroffen?

Red Hat OpenShift Container Platform 4.x über den ose-cluster-ingress-operator (HAProxy-basierter Router). Die exakte Liste der gefixten Errata-Versionen pro 4.x-Minor steht in der Red-Hat-Errata/RHSA zum CVE — diese ist vor dem Patch-Lauf je Cluster zu prüfen.

Bin ich als Moselwal-Kunde betroffen?

Betroffen sind Sie, wenn Sie OpenShift (selbst-gehostet, ROSA, ARO, Dedicated) mit dem Standard-HAProxy-Router betreiben und mehrere Teams/Tenants Route-Objekte anlegen dürfen. Reine Single-Tenant-Cluster, in denen nur die Plattform-Administration Routes schreibt, haben einen kleineren Trefferkorridor — der Patch bleibt trotzdem Pflicht.

Sofort-Mitigation?

Auf die für Ihre 4.x-Linie bereitgestellte Errata-Version heben (Cluster-Update über den OpenShift-Update-Kanal). Bis dahin: Route-Erstellung über Admission-Control (z. B. eine validierende Policy auf spec.path, die nur ein striktes Pfad-Schema erlaubt) einschränken und prüfen, welche ServiceAccounts/Gruppen routes-Schreibrechte haben.

Kritikalität?

Siehe Hero-Badge high (Red-Hat-CVSS 8.8). Keine öffentlich dokumentierte In-the-wild-Ausnutzung Stand 02.06., keine KEV-Aufnahme. Der Exploit-Pfad ist methodisch klar (kontrollierter spec.path → HAProxy-Direktive); in Multi-Tenant-Clustern zeitnah handeln.

 

Was ist passiert

Red Hat hat am 2. Juni 2026 CVE-2026-1784 für den OpenShift-Ingress-Operator veröffentlicht. Der Operator (ose-cluster-ingress-operator) verwaltet den HAProxy-basierten Router, der Anfragen von außen an die Pods im Cluster verteilt. Die zentrale Abstraktion dafür ist das Route-Objekt: ein Tenant beschreibt darin, unter welcher Subdomain und welchem Pfad sein Service erreichbar sein soll, und der Operator übersetzt diese Objekte in eine HAProxy-Konfiguration.

Der Bug sitzt in genau dieser Übersetzung. Die Prüfungen auf dem spec.path-Feld eines Route-Dokuments waren unzureichend, sodass vom Tenant kontrollierter Inhalt aus spec.path in die generierte HAProxy-Konfiguration fließen konnte, ohne dass die Sonderzeichen oder Zeilenstrukturen neutralisiert wurden, die HAProxy als Konfigurations-Syntax interpretiert. Damit lässt sich aus einem an sich harmlosen Routing-Feld eine Konfigurations-Injektion machen: Der Angreifer schreibt nicht nur einen Pfad, sondern schmuggelt zusätzliche HAProxy-Direktiven in die Config des gemeinsamen Routers.

Der eigentliche Schweregrad entsteht aus der geteilten Natur des Routers. Der HAProxy-Router ist eine cluster-weite, von allen Tenants gemeinsam genutzte Komponente. Eine Route lebt im Namespace eines Tenants, ihre Wirkung über die injizierte Config aber im Router-Pod, der für den gesamten Cluster-Ingress zuständig ist. Genau das spiegelt der CVSS-Vektor mit Scope: Changed wider: ein niedrig privilegierter Akteur (PR:L — Schreibrecht auf Route ist in geteilten Clustern ein gewöhnliches Tenant-Recht) erreicht eine Wirkung außerhalb seines Sicherheits-Scopes. Mit C:H/I:H/A:H ist die Folge im Worst Case Code-Ausführung im Router-Kontext, also Vollzugriff auf den Ingress-Pfad aller Tenants.

Der Fix korrigiert die Validierung des spec.path-Felds, sodass tenant-kontrollierter Inhalt nicht mehr als HAProxy-Syntax interpretiert werden kann. Er wird über die Red-Hat-Errata (RHSA) der jeweiligen OpenShift-4.x-Linie ausgeliefert; die exakten gefixten Build-Versionen pro Minor stehen im Red-Hat-CVE-Eintrag und der zugehörigen Errata.

Technische Einordnung

Strukturell ist CVE-2026-1784 ein klassischer Template-/Config-Injection-Befund an einer Vertrauensgrenze zwischen Tenant und Plattform. Der Ingress-Operator nimmt deklarative, tenant-geschriebene Objekte (Route) und rendert daraus eine imperative Konfigurationsdatei (haproxy.config) für eine privilegierte, geteilte Komponente. Jedes Feld, das aus dem Tenant-Objekt unescaped in diese Datei fließt, ist potenziell eine Injection-Stelle — dieselbe Klasse wie SQL-Injection (Daten werden als Code interpretiert) oder wie die klassischen Nginx-/Apache-Config-Injection-Lücken über unsaubere Annotation-Verarbeitung in anderen Ingress-Controllern.

Der zweite Punkt ist die Scope-Asymmetrie, die diese Klasse in Kubernetes/OpenShift besonders unangenehm macht. RBAC trennt Tenants sauber auf Objekt-Ebene: ein Tenant darf Route-Objekte in seinem Namespace schreiben, aber nicht in fremde. Diese Trennung hilft hier nichts, weil alle Routes in dieselbe geteilte HAProxy-Config gerendert werden. Die Sicherheitsgrenze, die RBAC auf der API-Ebene zieht, wird auf der Render-Ebene wieder eingerissen. Das ist die generische Lehre: Wo viele gering privilegierte Akteure in eine gemeinsame privilegierte Artefakt-Generierung einspeisen, muss die Neutralisierung am Render-Schritt sitzen, nicht an der RBAC-Grenze.

Drittens, die Eintrittsschwelle für die Triage. PR:L und AV:L bedeuten konkret: der Angreifer braucht ein gültiges Konto mit routes-Schreibrecht in irgendeinem Namespace — kein Cluster-Admin, kein Netzwerkzugang zu internen Komponenten. In einem typischen Multi-Tenant-OpenShift (mehrere Teams, CI-ServiceAccounts, self-service Namespaces) ist das der Normalfall. In einem Single-Tenant-Cluster, in dem nur die Plattform-Administration Routes schreibt, ist der Trefferkorridor kleiner — der Angreifer müsste dann bereits Plattform-Rechte haben. Ein oc get rolebindings,clusterrolebindings -A mit Blick auf das routes-Verb beantwortet die Frage, wer den Pfad überhaupt betreten kann.

Wer ist betroffen

Wichtig für die Einordnung: Die Lücke betrifft den Router, nicht die einzelne Anwendung. Sie patchen also nicht eine Workload, sondern den Cluster (Ingress-Operator). Wer mehrere Cluster betreibt, behandelt jeden Cluster als eigenes betroffenes Asset; ein gefixter Cluster sagt nichts über die anderen.

Auswirkungen und Sofortmaßnahmen

Die Auswirkung ist nicht „eine kompromittierte Route“, sondern „eine kompromittierbare Ingress-Schicht für den ganzen Cluster“. Wer Code im Router-Kontext ausführen oder die HAProxy-Config manipulieren kann, sitzt auf dem Pfad, über den der gesamte externe Verkehr aller Tenants läuft — mit den entsprechenden Möglichkeiten zu Umleitung, Mitlesen und Denial of Service.

Operational Decision Block

• Sofort patchen, wenn: ein produktiver Multi-Tenant-Cluster betroffen ist, in dem nicht-administrative Teams oder CI-ServiceAccounts Route-Objekte schreiben dürfen.
• Wartungsfenster genügt, wenn: ein Single-Tenant-Cluster betroffen ist, in dem ausschließlich die Plattform-Administration Routes schreibt — der Patch bleibt Pflicht, der akute Hebel ist aber kleiner.
• Zusätzlich absichern, wenn der Patch nicht sofort möglich ist: eine validierende Admission-Policy (OpenShift-Admission / Kyverno / Gatekeeper) auf Route.spec.path legen, die nur ein striktes Pfad-Schema (z. B. ^/[A-Za-z0-9/_-]*$) erlaubt und alles mit HAProxy-Sonderzeichen oder Zeilenumbrüchen ablehnt.

In dieser Reihenfolge. Erstens, Inventur: jeden OpenShift-Cluster und seine 4.x-Minor-Version erfassen, den Errata-Stand des Ingress-Operators gegen den Red-Hat-CVE-Eintrag abgleichen. Zweitens, RBAC-Sichtung: oc get rolebindings,clusterrolebindings -A -o wide und prüfen, welche Subjekte das routes-Schreibrecht haben — das ist die Liste der Akteure, die den Exploit-Pfad betreten können. Drittens, Patch über den Cluster-Update-Kanal auf die gefixte Errata-Version. Viertens, Stopgap-Admission-Policy für Cluster, die nicht sofort patchen. Fünftens, Audit der bestehenden Routes: vorhandene Route-Objekte auf auffällige spec.path-Werte mit Sonderzeichen, Zeilenumbrüchen oder HAProxy-Schlüsselwörtern prüfen.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Detection / Prüfung

Die Detection hat zwei Ebenen: „bin ich auf einem verwundbaren Operator-Stand“ (Patch-Frage) und „hat jemand bereits eine auffällige Route angelegt“ (Audit-Frage).

Prüf-Snippets (Copy/Paste):

# 1) Welche OpenShift-Version / Ingress-Operator-Stand?
oc version
oc get clusteroperator ingress -o jsonpath='{.status.versions}'

# 2) Wer darf Routes schreiben? (Exploit-Pfad-Inhaber)
oc get clusterrolebindings,rolebindings -A -o wide | grep -iE 'route|edit|admin'

# 3) Bestehende Routes auf auffällige spec.path-Werte prüfen
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

Was auffällig ist:spec.path-Werte, die Zeilenumbrüche, geschweifte Klammern, Semikolons, #-Kommentare oder HAProxy-Schlüsselwörter (http-request, acl, backend, server, bind) enthalten. Ein legitimer Pfad ist ein simpler URL-Pfad ohne diese Zeichen. Für laufende Detection eine Admission-Policy als Audit-Modus fahren, die solche Werte protokolliert, bevor sie blockiert werden.

Betreiberempfehlung

Mittelstand

Wer OpenShift als Managed-Variante (ROSA, ARO, OpenShift Dedicated) bezieht, prüft zuerst, ob der Provider den Ingress-Operator bereits gepatcht hat — bei Managed-Angeboten liegt der Cluster-Operator-Patch oft beim Betreiber. Für selbst betriebene Cluster gilt: Update über den Standard-Update-Kanal einplanen und bis dahin die Admission-Policy als Stopgap setzen. Die RBAC-Sichtung ist hier der schnelle Gewinn: oft dürfen historisch mehr ServiceAccounts Routes schreiben als nötig.

Enterprise / Multi-Tenant

In geteilten Plattformen ist CVE-2026-1784 ein Anlass, die Tenant-zu-Router-Grenze grundsätzlich zu härten: validierende Admission-Policies auf Route.spec.path (und verwandte Felder) als Dauer-Kontrolle, nicht nur als Stopgap; Least-Privilege-Review der routes-Rechte; und, wo möglich, sharded Router pro Tenant-Klasse, damit eine Injection nicht den gesamten cluster-weiten Ingress trifft.

Deklarative Stacks / GitOps

Wer Routes über GitOps (Argo CD / Flux) ausrollt, ergänzt die Pfad-Validierung in der CI-Pipeline (Policy-as-Code, z. B. Conftest/OPA gegen die Route-Manifeste) — so wird ein bösartiger spec.path schon im Pull-Request abgelehnt, bevor er den Cluster erreicht.

Fazit

CVE-2026-1784 ist die wiederkehrende Lektion der Multi-Tenant-Plattform: Eine Sicherheitsgrenze, die auf der API-Ebene (RBAC) sauber gezogen ist, kann auf der Render-Ebene (geteilte HAProxy-Config) wieder zusammenfallen, wenn tenant-kontrollierter Inhalt unescaped in ein privilegiertes Artefakt fließt. Der Fix ist ein normales Cluster-Update; der Stopgap ist eine Admission-Policy auf spec.path; der bleibende Gewinn ist die Disziplin, jede Tenant-zu-Plattform-Render-Stelle als Injection-Grenze zu behandeln. Risiko nüchtern: hoch für geteilte Cluster mit verteilten Route-Rechten, kleiner für strikt single-tenant betriebene Cluster — die Triage über oc get rolebindings trennt die beiden Klassen in Minuten.

Quellen

• Red Hat — CVE-2026-1784 (ose-cluster-ingress-operator: RCE through HAProxy configuration injection; CVSS 8.8, Errata-Verweise)
• OpenCVE — CVE-2026-1784 (Beschreibung, CVSS-Vektor AV:L/AC:L/PR:L/S:C/C:H/I:H/A:H, CWE-15, Stand 02.06.2026)
• Red Hat OpenShift — Dokumentation Ingress/Routes (Kontext zum HAProxy-Router und Route-Objekt)