Kritische Proxmox-Lücke ermöglicht Login ohne Passwort
Eine kritische Schwachstelle in Proxmox VE 7 erlaubt die Anmeldung an verwundbaren Systemen ohne gültiges Passwort. Besonders ungewöhnlich: Der Fehler wurde bereits 2023 unbeabsichtigt behoben, ohne dass seine Sicherheitsrelevanz bekannt war. Nun sorgen Berichte über kompromittierte Proxmox-Hosts für Aufmerksamkeit. Administratoren sollten insbesondere öffentlich erreichbare Managementschnittstellen und den Versionsstand von libpve-access-control überprüfen.
Eine kritische Schwachstelle in älteren Versionen von Proxmox VE erlaubt Angreifern, die Authentifizierung an der Verwaltungsoberfläche zu umgehen. Betroffen sind Proxmox VE 7 sowie frühe Installationen von Proxmox VE 8 mit einer verwundbaren Version von libpve-access-control. Besonders brisant: Der Fehler wurde bereits 2023 eher zufällig durch eine Überarbeitung des Codes behoben, ohne dass damals bekannt war, dass damit eine Sicherheitslücke geschlossen wurde. Nun berichten Administratoren von kompromittierten und teilweise durch Ransomware beschädigten Systemen.
Die unter CVE-2023-54391 geführte Schwachstelle betrifft das Proxmox-Paket libpve-access-control ab Version 7.0-7 bis vor Version 8.0.4. Das entspricht laut Proxmox ungefähr Proxmox VE 7.0 bis einschließlich 7.4 sowie der ursprünglichen Version 8.0. Aktuell unterstützte Proxmox-VE-Versionen sind nicht betroffen.
VulnCheck bewertet die Schwachstelle nach CVSS 3.1 mit 9,8 von 10 Punkten, nach CVSS 4.0 mit 9,3 Punkten. Als Ursache ist CWE-304 ("Missing Critical Step in Authentication") angegeben.
Wie lässt sich die Proxmox-Authentifizierung umgehen?
Der Fehler steckt in der Behandlung der Zwei-Faktor-Authentifizierung. Die Anmeldung an der Proxmox-API erfolgt unter anderem über den API-Endpunkt /api2/json/access/ticket. Dabei kann ein Parameter namens tfa-challenge zum Einsatz kommen.
Bei verwundbaren Versionen lässt sich dieser Parameter so verwenden, dass ein entscheidender Schritt der eigentlichen Authentifizierung übersprungen wird. Ein nicht authentifizierter Angreifer kann dadurch eine Sitzung für einen vorhandenen und aktivierten Benutzer erhalten, sofern für dessen Konto kein zweiter Faktor eingerichtet ist. Ein gültiges Passwort benötigt der Angreifer dafür nicht.
Das ist insbesondere deshalb gefährlich, weil darunter auf vielen Installationen hochprivilegierte Konten fallen können. Erreicht ein Angreifer auf diesem Weg beispielsweise ein administratives Konto, ist eine vollständige Übernahme des Virtualisierungshosts möglich.
Voraussetzung für einen Angriff ist allerdings, dass der Angreifer die Proxmox-Verwaltung beziehungsweise deren API erreichen kann. Standardmäßig lauscht die Weboberfläche auf TCP-Port 8006. Direkt aus dem Internet erreichbare Managementoberflächen stellen daher das größte Risiko dar.
Welche Proxmox-Versionen sind betroffen?
Entscheidend ist weniger die angezeigte Proxmox-VE-Version als der Versionsstand des Pakets libpve-access-control. Verwundbar sind laut Advisory:
libpve-access-control >= 7.0-7 und < 8.0.4
Dies betrifft im Wesentlichen Proxmox VE 7.0 bis 7.4 und der Vollständigkeit halber die erste Version von Proxmox VE 8.0. Proxmox VE 7 befindet sich bereits seit Juli 2024 außerhalb des regulären Lebenszyklus. Keine aktuell unterstützte Proxmox-VE-Version ist nach Angaben des Herstellers betroffen.
Administratoren können die installierte Paketversion beispielsweise mit folgendem Befehl kontrollieren:
dpkg-query -W -f '${Version}\n' libpve-access-control
Einen ausführlicheren Überblick über die installierten Proxmox-Pakete liefert:
pveversion -v
Liegt libpve-access-control mindestens in Version 7.0-7, aber unterhalb von 8.0.4, muss das System als verwundbar betrachtet werden.
Warum wurde die Schwachstelle drei Jahre lang übersehen?
Ungewöhnlich ist die Geschichte hinter CVE-2023-54391. Der verwundbare Code wurde bereits im Juli 2023 verändert. Im Zuge einer Überarbeitung der Zwei-Faktor-Authentifizierung verschwand dabei auch die Möglichkeit zum Authentication Bypass.
Allerdings wusste zu diesem Zeitpunkt offenbar niemand, dass überhaupt eine Sicherheitslücke existierte. Proxmox zufolge war die Änderung weder als Security-Fix gedacht noch war das Problem zuvor intern oder extern gemeldet worden. Entsprechend wurde die Änderung auch nicht als sicherheitsrelevant erkannt und nicht auf den damals noch gepflegten Proxmox-VE-7-Zweig zurückportiert.
Damit entstand eine ungewöhnliche Situation: Neuere Installationen waren seit 2023 faktisch geschützt, obwohl es weder ein Security Advisory noch eine CVE für den Fehler gab. Ältere Systeme blieben dagegen verwundbar.
Der Vorfall verdeutlicht damit auch ein grundsätzliches Problem beim Betrieb von End-of-Life-Systemen: Nicht jede sicherheitsrelevante Codeänderung wird zum Zeitpunkt ihrer Veröffentlichung als solche erkannt. Wer nur auf Security Advisories reagiert, erhält deshalb nicht zwangsläufig jede relevante Fehlerkorrektur. Regelmäßige Versionsaktualisierungen bleiben auch dann wichtig, wenn für eine ältere Installation vermeintlich keine offenen Sicherheitslücken bekannt sind.
Wird die Proxmox-Lücke bereits ausgenutzt?
Hier ist eine vorsichtige Einordnung notwendig. Ausgangspunkt der aktuellen Untersuchung waren Berichte im Proxmox-Supportforum. Am 31. August meldeten Administratoren dort kompromittierte Proxmox-VE-7-Systeme. Unter anderem ist von beschädigten beziehungsweise verschlüsselten Speichersystemen und Lösegeldforderungen die Rede.
Daraus lässt sich derzeit jedoch nicht zweifelsfrei ableiten, dass CVE-2023-54391 bei allen gemeldeten Angriffen der Einstiegspunkt war. Einige Nutzer nannten Versionen, die nach Herstellerangaben nicht von der Schwachstelle betroffen sind. Proxmox selbst hat eine Ausnutzung von CVE-2023-54391 in diesen konkreten Fällen bislang nicht abschließend bestätigt.
Für die praktische Gefahreneinschätzung spielt diese Unsicherheit allerdings nur eine begrenzte Rolle: Die Authentifizierungsumgehung ist nachvollziehbar und über das Netzwerk erreichbar. Emerging Threats veröffentlichte am 1. September zudem bereits eine IDS-Signatur zur Erkennung entsprechender Zugriffsversuche. Das belegt zumindest, dass sich der Angriff technisch reproduzieren lässt.
Wie sollten Administratoren reagieren?
Die wichtigste Maßnahme besteht darin, verwundbare Proxmox-Systeme nicht mehr direkt über Port 8006 aus dem Internet erreichbar zu machen. Die Verwaltungsoberfläche sollte grundsätzlich ausschließlich über ein internes Managementnetz, ein VPN oder entsprechend restriktive Firewall-Regeln zugänglich sein.
Administratoren sollten anschließend prüfen, welche Version von libpve-access-control installiert ist. Für noch produktiv eingesetzte Proxmox-VE-7-Systeme empfiehlt sich die Migration auf eine aktuell unterstützte Version. Ein dauerhaftes Festhalten an Proxmox VE 7 ist schon aufgrund des seit Juli 2024 erreichten End-of-Life keine sinnvolle Lösung.
Eine zusätzlich eingerichtete Zwei-Faktor-Authentifizierung bietet nach der Beschreibung von CVE-2023-54391 ebenfalls Schutz vor genau diesem Angriffspfad: Die Schwachstelle betrifft aktivierte Benutzer ohne konfigurierten zweiten Faktor. Darauf sollten sich Administratoren allerdings nicht als Ersatz für ein Update oder eine abgeschottete Managementschnittstelle verlassen.
Was ist nach einem vermuteten Angriff zu tun?
Bei einem möglicherweise kompromittierten Host sollten Administratoren insbesondere die Zugriffe auf die Proxmox-API untersuchen. Relevant ist unter anderem:
/var/log/pveproxy/access.log
Gesucht werden sollten ungewöhnliche erfolgreiche Authentifizierungen, insbesondere für die Realms @pam und @pve. Außerdem empfiehlt sich eine Kontrolle auf unbekannte Benutzerkonten, API-Tokens und SSH-Schlüssel.
Die Berichte im Proxmox-Forum zeigen zudem, dass Angreifer nach einer Übernahme offenbar versucht haben, ihre Spuren zu verwischen und Systeme beziehungsweise virtuelle Datenträger zu beschädigen. Allerdings unterscheiden sich die Beobachtungen der Betroffenen, sodass einzelne Indicators of Compromise derzeit nicht pauschal CVE-2023-54391 zugerechnet werden sollten.
Besteht der Verdacht auf einen erfolgreichen Zugriff mit Root-Rechten, sollte ein Host nicht allein durch das Entfernen auffälliger Dateien wieder als vertrauenswürdig gelten. Sinnvoll sind die Sicherung forensisch relevanter Daten und anschließend – abhängig vom Befund – eine Neuinstallation beziehungsweise Wiederherstellung aus einem nachweislich sauberen Backup.
CVE-Jahreszahl kann Administratoren in die Irre führen
Eine weitere Besonderheit steckt im Namen CVE-2023-54391. Obwohl die Schwachstelle erst am 1. September 2026 veröffentlicht wurde, trägt sie eine CVE-Nummer aus dem Jahr 2023. Der Fehler war schließlich bereits in diesem Jahr durch die Codeänderung verschwunden.
Das kann automatisierte Schwachstellenprozesse beeinträchtigen. Filtert ein Unternehmen beispielsweise ausschließlich nach CVEs aus den vergangenen zwölf oder 24 Monaten, könnte CVE-2023-54391 trotz ihrer Veröffentlichung im September 2026 aus dem Raster fallen. Die Jahreszahl einer CVE ist daher nicht zwangsläufig mit dem Zeitpunkt ihrer öffentlichen Bekanntgabe gleichzusetzen.
Der Proxmox-Fall liefert damit gleich zwei Argumente für ein konsequentes Lifecycle-Management: End-of-Life-Systeme erhalten nicht nur keine regulären Sicherheitskorrekturen mehr – unbekannte Sicherheitsprobleme können zudem längst in neueren Versionen verschwunden sein, ohne jemals als Schwachstelle dokumentiert worden zu sein. Für Betreiber noch öffentlich erreichbarer Proxmox-VE-7-Systeme sollte die Migration daher spätestens jetzt höchste Priorität haben.