CRI-O: Sandbox-Zustandsvergiftung über Pod-Annotationen kann Runtime-Socket offenlegen

Zusammenfassung

Eine Schwachstelle an der Vertrauensgrenze in der Persistenz des Sandbox-Zustands von CRI-O erlaubt es, dass durch Angreifer beeinflusste Pod-Annotationen oder Labels die reservierten Sandbox-Verwaltungsdaten von CRI-O überschreiben. Nach einem Neustart von CRI-O oder des Nodes kann ein späteres Neuerstellen eines Containers in dieser Sandbox eine Host-seitige Runtime-Management-Ressource innerhalb des Containers offenlegen, was einen Container-Ausbruch ermöglichen kann. Voraussetzung sind die Berechtigung zum Erstellen oder Ändern von Pods sowie ein Neustart und eine Neuerstellung des Containers; die Angriffskomplexität ist hoch.

Betroffen

• Red Hat OpenShift Container Platform 4.16 (CRI-O-1.29.x-Pakete; laut CVE-Eintrag sind Versionen vor 1.29.13-16.rhaos4.16.git84cfdc6.el8 betroffen)
• Red Hat OpenShift Container Platform 5 (standardmässig als betroffen aufgeführt)
• Upstream-Versionen von CRI-O, die reservierte Sandbox-Metadaten zusammen mit nicht vertrauenswürdigen Annotationen speichern und als vertrauenswürdig neu laden (genaue Upstream-Bereiche unbekannt)

Behoben in

• Red Hat OpenShift Container Platform 4.16: RHSA-2026:89713 (OpenShift Container Platform 4.16.74 RPM-Pakete, cri-o-1.29.13-16.rhaos4.16.git84cfdc6)
• Upstream: Backports laut Berichten in v1.34.12 sowie in den Branches release-1.25 und release-1.32
• Andere Distributionen und Branches: Unbekannt.

Umgehung

• Es gibt keine vollständige Workaround-Lösung.
• Beschränken Sie über RBAC- oder Admission-Richtlinien, wer Pods erstellen oder ändern und beliebige Annotationen setzen darf.
• Reduzieren Sie unnötige Neustarts von CRI-O und Node-Neustarts.
• Überwachen Sie nach Runtime-Neustarts auf ungewöhnliche Container-Mounts (zum Beispiel unter /dev/shm).

Ausnutzung

• Keine Hinweise auf eine Ausnutzung gefunden.
• CISA SSVC: Exploitation none, Automatable no, Technical Impact total.
• Laut einem Tracker ist kein öffentlicher Proof of Concept bekannt.
• Status als aktiv ausgenutzte Schwachstelle: Nicht verifiziert.

Unsere Empfehlung

• Prüfen Sie, wo CRI-O in Ihrer Umgebung läuft (OpenShift, RKE2, verwaltete Kubernetes-Nodes, RHEL mit cri-o).
• Spielen Sie den Herstellerpatch ein, etwa RHSA-2026:89713 für OpenShift 4.16, über den offiziellen Update-Kanal ein.
• Beschränken Sie bis zur Behebung das Erstellen von Pods und das Setzen von Annotationen und überwachen Sie nach Neustarts auf unerwartete Mounts.
• Priorisieren Sie Cluster mit Mandanten oder nicht vertrauenswürdigen Workloads sowie CI-Runner, die nicht vertrauenswürdige Images ausführen.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

Links zu fremden Seiten, von uns nicht geprüft – Exploit-Code kann Schadsoftware enthalten. Nur in isolierten Testumgebungen verwenden.

• Proof of Concept auf GitHub (1 Repositories) iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).
  TeamN4C/SG-2026-0026

Quellen der Recherche

• Red Hat CVE record CVE-2026-62146 access.redhat.com
• Red Hat Errata RHSA-2026:89713 access.redhat.com
• Red Hat Bugzilla 2499618 bugzilla.redhat.com
• GitHub Security Advisory GHSA-6wmc-5877-hgc9 github.com
• CRI-O upstream fix pull request 10403 github.com
• CRI-O backport pull request 10408 github.com

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 02.11.2026 07:34.