Fehlende Rechteprüfung in der API Fehler in OpenStack Manila lässt Fremde öffentliche Freigaben steuern

Von Melanie Staudacher 3 min Lesedauer

Anbieter zum Thema

Angemeldete Nutzer eines beliebigen Projekts können in OpenStack Manila öffentliche Freigaben fremder Projekte manipulieren und etwa Zu­griffs­regeln ändern. Korrigiert sind die Versionen 20.0.3, 21.0.3, 22.0.2 und 23.0.1.

Aufgrund einer Schwachstelle in Manila können angemeldete Nutzer projektübergreifend Berechtigungen öffentlicher Dateifreigaben verändern und dadurch vertrauliche Daten auslesen, manipulieren oder rechtmäßigen Nutzern den Zugriff entziehen.(Bild:  kentoh - stock.adobe.com)
Aufgrund einer Schwachstelle in Manila können angemeldete Nutzer projektübergreifend Berechtigungen öffentlicher Dateifreigaben verändern und dadurch vertrauliche Daten auslesen, manipulieren oder rechtmäßigen Nutzern den Zugriff entziehen.
(Bild: kentoh - stock.adobe.com)

Aufgrund einer Schwachstelle in Manila von OpenStack prüfen mehrere Funktionen der Programmierschnittstelle bei öffentlichen Freigaben („Public Shares“) nicht, ob der Aufrufende tatsächlich Eigentümer der Freigabe ist. Die API-Controller autorisieren die Vorgänge basierend auf dem Projektkontext des Aufrufenden, laden dann jedoch eine fremde öffentliche Freigabe, ohne eine erneute Autorisierung gegenüber dem tatsächlichen Eigentümer der Freigabe durchzuführen. Über die Sicherheitslücke EUVD-2026-107046 / CVE-2026-71195 (CVSS-Score 9.9, EPSS-Score* 0.48) kann deshalb jedes angemeldete Projektmitglied auf jede öffentliche Freigabe zugreifen und sie verändern. Manila ist der Dienst für gemeinsam genutzte Dateisysteme der Cloud-Plattform OpenStack.

Zahlreiche Aktionen möglich

Laut Enisa können angemeldete Nutzer eines fremden Projekts auf öffentlichen Freigaben diese Aktionen ausführen:

  • Zugriff gewähren („allow_access“): Lese- und Schreibzugriff auf die Daten einer fremden Freigabe vergeben.
  • Zugriff entziehen („deny_access“): Bestehende Zugriffsregeln des Eigentümers widerrufen.
  • Zugriffsstufe erhöhen („update_access“): zum Beispiel von „ro“ (nur lesen) auf „rw“ (lesen und schreiben).
  • Sicherung anlegen („create_share_backup“): Daten über ein Backup unter dem eigenen Projekt abgreifen.
  • Freigabe löschen und wiederherstellen („soft_delete“, „restore“): eine fremde Freigabe in den Papierkorb verschieben oder den Löschvorgang des Eigentümers stören.
  • Metadaten der Exportorte ändern: Metadaten fremder Exportorte anlegen, ändern und löschen.
  • Zugriffsregeln auflisten: IP-Adressen, Benutzernamen und CephFS-Schlüssel einsehen.

Wie schwer die Aktionen wiegen, besprachen zwei Entwickler im Bug-Tracker von OpenStack. Das ist eine öffentliche Fehlerdatenbank auf der Plattform Launchpad, in der Entwickler Fehler melden und besprechen. Die Änderung der Zugriffsregeln wird für das größte Problem gehalten, weil ein Angreifer damit Daten einer Freigabe lesen und dem Eigentümer den Zugang entziehen kann. Die Änderung der Metadaten von Exportorten halten die Entwickler für weniger schwerwiegend, da diese Metadaten nur Beschriftungen sind und nicht ans Speichersystem weitergegeben werden.

Ob geänderte Zugriffsregeln tatsächlich auf dem Speichersystem ankommen, hängt laut Sicherheitshinweis von OpenStack vom eingesetzten Backend ab. Löschen, Vergrößern, Verkleinern und Snapshots sind nach den Tests der Entwickler bereits durch bestehende Richtlinien geschützt. Die Schwachstelle betrifft Installationen, die öffentliche Freigaben nutzen.

Betroffen sind laut OpenStack diese Versionen von Manila:

  • Manila 1.0.0 bis vor 20.0.3
  • Manila 21.0.0 bis vor 21.0.3
  • Manila 22.0.0 bis vor 22.0.2
  • Manila 23.0.0

Die Patches sind:

  • Manila 20.0.x (Epoxy): Update auf 20.0.3 oder höher
  • Manila 21.0.x (Flamingo): Update auf 21.0.3 oder höher
  • Manila 22.0.x (Gazpacho): Update auf 22.0.2 oder höher
  • Manila 23.0.x (Hibiscus): Update auf 23.0.1 oder höher

Die Patches ergänzen die Prüfung des Eigentümers bei Zugriffsregeln, Sicherungen, Replikaten, dem Löschen in den Papierkorb und dem Wiederherstellen öffentlicher Freigaben. Die Schnittstellen für Metadaten sind nun auf die Freigabe aus der URL begrenzt. Für fremde Exportorte liefert die API jetzt den Fehler 404 („nicht gefunden“) statt 403 („nicht erlaubt“), damit niemand erfährt, ob die Freigabe existiert. Zusätzlich gibt es Anpassungen am Test-Plugin „manila-tempest-plugin“. Der Sicherheitshinweis verlinkt außerdem die einzelnen Korrekturen für jeden Release-Zweig im Code-Review-System.

Langwierige Offenlegung

Chen YuXiang vom Institute of Computing Technology der Chinesischen Akademie der Wissenschaften meldete den Fehler am 21. Juli 2026 im Bug-Tracker. Die Meldung war zunächst nicht öffentlich, erst am 20. Oktober gab das Team den Bug und seine Kommentare frei. Dort lässt sich der Verlauf nachlesen. Goutham Pacha Ravi und Carlos da Silva, laut Sicherheits­hinweis beide von Red Hat, fanden weitere betroffene Wege auf öffentlichen Freigaben. Ein Sicherheitsforscher namens Yuliang Xiao meldete unabhängig davon ein Problem bei der Schnittstelle für Metadaten. Das OpenStack-Team bestätigte den Fehler am 23. Juli.

Doch die Veröffentlichung verzögerte sich aus einem unbekannten Grund. Laut einem Kommentar des Sicherheitsteams vom 25. September gab es bis nach dem Erscheinen von Hibiscus, der OpenStack-Ausgabe 2026.2 mit Manila 23.0.x, keine Sicherheitshinweise. Am 7. Oktober schickte das Sicherheitsteam die Korrekturen an nachgelagerte Beteiligte. Die öffentliche Freigabe am 20. Oktober legte das Team einen Tag nach hinten, weil laut Goutham Pacha Ravi das Treffen „OpenInfra Project Teams Gathering“ anstand.

* Hinweis zum EPSS-Score: Das Exploit Prediction Scoring System zeigt die Wahrscheinlichkeit in Prozent an, mit der eine Schwachstelle innerhalb der nächsten 30 Tage ausgenutzt wird. Der ent­sprechende Score kann sich im Laufe der Zeit verändern. Sofern nicht anders angegeben, beziehen wir uns auf den Stand des EPSS-Scores zum Zeitpunkt der Veröffentlichung des Artikels.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

(ID:50995058)