Proxmox CVE-2023-54391: Wer ist wirklich durch die Lücke gefährdet?

CVE-2023-54391 ist ein gravierender Authentifizierungs-Bypass in Proxmox VE. Die Schlagzeilen à la "Proxmox jetzt sofort aktualisieren" unterschlagen jedoch ein entscheidendes Detail: Viele Proxmox VE 7- und 8-Installationen sind überhaupt nicht verwundbar.

Der betroffene Paketbereich lautet libpve-access-control >= 7.0-7 and < 8.0.4. Das entspricht grob Proxmox VE 7.0 bis 7.4 sowie dem ersten Release von Proxmox VE 8.0. Der fehlerhafte Codepfad wurde am 20. Juli 2023 entfernt, lange bevor das Problem im September 2026 eine offizielle CVE-Nummer erhielt. Wenn auf Ihrem System libpve-access-control 8.0.4 oder neuer läuft, besteht wegen dieser konkreten Lücke kein Anlass zur Panik.

Betreiben Sie allerdings noch Proxmox VE 7, wiegt die Lage schwerer. Der reguläre PVE 7-Zweig erhielt diesen Fix nie, und das Release ist seit langer Zeit aus dem Support. War dessen Management-API aus nicht vertrauenswürdigen Netzwerken erreichbar, handelt es sich hierbei um mehr als eine routinemäßige Patch-Erinnerung. Veraltete, direkt dem Internet ausgesetzte Administrationssoftware ist gefährlich, selbst wenn der Fehler in neueren Versionen bereits vor Jahren behoben wurde.

Was bewirkt CVE-2023-54391 technisch?

CVE-2023-54391 erlaubt es einem nicht authentifizierten Angreifer, die Passwortprüfung für ein aktives Proxmox-Benutzerkonto zu umgehen, sofern für dieses Konto kein zweiter Faktor eingerichtet ist.

Die Schwachstelle liegt im Login-Ablauf von libpve-access-control. Eine normale Proxmox-Anmeldung sendet Zugangsdaten an die Ticket-Schnittstelle. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, antwortet der Server mit einer Challenge, die gelöst werden muss, bevor eine gültige Session erzeugt wird.

Die fehlerhafte Logik akzeptierte Anfragen mit einem tfa-challenge-Feld, ohne ordnungsgemäß zu prüfen, ob der Server diese Challenge zuvor in einem gültigen ersten Authentifizierungsschritt ausgestellt hatte. Bei einem aktiven Konto ohne zweiten Faktor konnte ein Angreifer so die Kennwortprüfung überspringen und ein gültiges Sitzungsticket erhalten. Das schließt hochprivilegierte Konten wie root@pam ein, falls diese aktiv sind und keinen zweiten Faktor nutzen.

VulnCheck stuft die Schwachstelle unter CVSS 4.0 mit einem Score von 9.3 als kritisch ein. Der von der NVD abgeleitete CVSS 3.1 Score liegt bei 9.8. Der Angriff funktioniert über das Netzwerk, erfordert weder vorherige Authentifizierung noch Benutzerinteraktion und hat potenziell schwerwiegende Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Die CVE verdient daher volle Aufmerksamkeit, auch wenn der fehlerhafte Code bereits älter ist.

Welche Proxmox-Versionen sind tatsächlich verwundbar?

Orientieren Sie sich an der Paketversion, denn die Hauptversionsnummer von Proxmox VE allein reicht zur Beurteilung nicht aus. Der Sicherheitshinweis von Proxmox definiert den betroffenen Bereich wie folgt:

libpve-access-control >= 7.0-7 and < 8.0.4

Dieser Bereich entspricht im Wesentlichen:

• Proxmox VE 7.0 bis 7.4
• dem anfänglichen Proxmox VE 8.0 Release

Die Fehlerbehebung ist enthalten in:

libpve-access-control 8.0.4

Dieses Paket wurde bereits am 20. Juli 2023 veröffentlicht. Deshalb ist die Pauschalaussage "PVE 8 ist verwundbar" irreführend. Ein System, das nach Juli 2023 reguläre Updates für PVE 8 erhalten hat, nutzt längst eine neuere Paketversion. Ein PVE 8.1, 8.2, 8.3, 8.4 oder Proxmox VE 9 System mit normalen Updates ist von dieser CVE nicht betroffen. Proxmox bestätigt in seinem Hinweis ausdrücklich, dass kein aktuell unterstütztes Proxmox VE-Release verwundbar ist.

Im September 2026 hat Proxmox VE 8 selbst das Ende des Supports erreicht, und PVE 9 ist das aktuelle unterstützte Major-Release. Daraus ergeben sich zwei getrennte Fragen:

1. Existiert genau diese CVE auf der Maschine?
2. Läuft auf dem System noch ein offiziell unterstütztes Proxmox-Release?

Ein spätes PVE 8 System kann vor CVE-2023-54391 sicher sein, bleibt aber dennoch ein End-of-Life-System ohne reguläre Sicherheitsaktualisierungen.

Wie prüfen Sie, ob Ihr Host betroffen ist?

Kontrollieren Sie das installierte Paket libpve-access-control direkt. Ein einfacher Befehl lautet:

dpkg-query -W libpve-access-control

Achten Sie auf Versionen älter als 8.0.4, die gleichzeitig 7.0-7 oder höher sind.

Eine ausführlichere Prüfung aus der technischen Diskussion lautet:

V=$(dpkg-query -W -f='${Version}' libpve-access-control 2>/dev/null)
echo "libpve-access-control: ${V:-not installed}"
dpkg --compare-versions "$V" lt 8.0.4   && echo ">>> AFFECTED"   || echo ">>> not affected"

Der Vergleich der Paketversion liefert Ihnen eine verlässlichere Aussage als die reine Systembezeichnung "PVE 8", da Paketversionen und Hauptreleases nicht eins zu eins übereinstimmen.

Wenn Sie bereits auf einem unterstützten Proxmox VE 9 System mit aktuellem Patchstand arbeiten, können Sie diese CVE abhaken. Finden Sie hingegen eine alte PVE 7 Installation, wird ein simples apt update && apt full-upgrade innerhalb des PVE 7 Zweigs das Problem nicht beheben.

Warum kann ein voll aktualisierter PVE 7-Host verwundbar sein?

Niemand wusste, dass es sich um eine Sicherheitslücke handelte, als der Code entfernt wurde. Die fehlerhafte Logik entfiel im Juli 2023 im Rahmen regulärer Entwicklungsarbeiten. Proxmox erklärte, dass der Auth-Bypass damals weder intern entdeckt noch extern gemeldet worden war, weshalb die Änderung nicht als Sicherheitspatch eingestuft wurde. Sicherheitspatches werden für einen Backport in ältere unterstützte Zweige geprüft. Eine normale Code-Überarbeitung wird in der Regel nicht rückportiert, wenn niemand weiß, dass sie ein kritisches Sicherheitsleck schließt.

Als CVE-2023-54391 am 1. September 2026 offiziell veröffentlicht wurde, war Proxmox VE 7 bereits seit mehr als 2 Jahren End-of-Life, und der reguläre PVE 7 Paketkanal enthielt nach wie vor die anfällige Logik. Einer der Sicherheitsforscher betonte später genau diesen Umstand: Ein vollständig durchaktualisierter PVE 7 Host kann weiterhin betroffen sein, weil der Fix nie in den regulären Update-Pfad von PVE 7 gelangte.

Proxmox hat für Administratoren, die ein großes Versionsupgrade nicht sofort durchführen können, einen Hotfix bereitgestellt. Die dauerhafte Lösung besteht jedoch darin, PVE 7 zu verlassen. Normale Updates genügen hierfür nicht, Sie müssen den unterstützten Upgrade-Pfad beschreiten.

Gab es im September 2026 echte Angriffe?

CrowdSec verzeichnete Traffic, der Angriffsmustern entsprach, auch wenn nicht jeder Treffer zu einem erfolgreichen Einbruch führte. Im Bericht vom 7. September hieß es, dass 133 eindeutige IP-Adressen seit dem 4. September, dem Tag der Regelscharfschaltung, Anfragen passend zum CVE-Muster gesendet hatten. Das ist ein handfester Beleg für aktive Scan- und Ausnutzungsversuche, bedeutet aber keineswegs 133 bestätigte Kompromittierungen.

Sobald ein Exploit-Muster öffentlich bekannt ist, durchsuchen automatisierte Scanner riesige Adressbereiche nach verwundbaren Systemen. Ein Großteil der Ziele ist gepatcht, durch Firewalls geschützt, nicht existent oder anderweitig immun. Für einen alten Host mit offenem Port 8006 im Internet ist die Lage dennoch ernst, da eine simple, unauthentifizierte Anfrage genau das ist, was automatisierte Scanner rasch aufspüren.

Mehrere Administratoren berichteten in der Diskussion zudem von verdächtigen Vorfällen auf alten Proxmox-Systemen, einschließlich veränderter Passwörter und mutmaßlich gehackter Hosts. Sofern ein Vorfall nicht forensisch auf diese CVE zurückgeführt wurde, bleiben das Einzelfallberichte. Die Erfahrungen anderer beweisen nicht, dass Ihr System kompromittiert wurde, aber wenn Sie einen verwundbaren, erreichbaren Host betrieben haben, liefert das triftige Gründe für eine gründliche Prüfung.

Schützt eine Zwei-Faktor-Authentifizierung vor dem Fehler?

Sie verändert die Voraussetzungen für den Angriff, ersetzt aber kein Upgrade.

Die CVE-Beschreibung hält fest, dass der Angreifer sich als aktiver Benutzer ohne konfigurierten zweiten Faktor authentifizieren kann. Ein Konto mit korrekt eingerichteter Zwei-Faktor-Authentifizierung entspricht nicht dem einfachsten verwundbaren Fall aus der Warnung, was ein sinnvolles Defense-in-Depth-Element darstellt. Es macht einen EOL-Hypervisor jedoch keineswegs rundum sicher.

Ein Proxmox-Host verfügt oft über mehrere aktive Benutzer, API-Token, Dienstkonten und administrative Identitäten. Fehlt auch nur einem einzigen verwertbaren Konto der zweite Faktor, besitzt der Angreifer weiterhin eine Einstiegsmöglichkeit. Eine wirksame Absicherung erfordert daher mehrere Ebenen:

• Upgraden oder die Notfall-Mitigation des Herstellers anwenden
• Management-Zugriff aus nicht vertrauenswürdigen Netzen kappen
• MFA für alle administrativen Benutzer vorschreiben
• Unnötige aktive Konten überprüfen und deaktivieren
• API- und GUI-Zugriffe über Netzwerkrichtlinien einschränken

Greifen diese Ebenen ineinander, entscheidet nicht mehr ein einzelner Fehler über die Sicherheit des Gesamtsystems.

Sollte Port 8006 jemals öffentlich im Internet stehen?

Für praktisch jedes normale Setup lautet die Antwort: Nein. Die Proxmox-Weboberfläche und die externe API werden von pveproxy bereitgestellt, in der Regel auf TCP-Port 8006. Diese Schnittstelle kann virtuelle Maschinen und Container anlegen, löschen, starten, stoppen, umkonfigurieren und Konsolensitzungen öffnen. Es handelt sich um eine Management-Ebene. Behandelt man sie wie eine gewöhnliche öffentliche Website, gibt man Angreifern direkten Zugriff auf einen der am höchsten privilegierten Dienste im gesamten Netzwerk.

Die größte Einigkeit in der Fachdiskussion herrschte nicht über diese spezifische CVE, sondern über das Design von Management-Netzwerken. Die bewährte Praxis lautet, Proxmox-Verwaltungsschnittstellen in ein dediziertes Management-Netzwerk oder VLAN zu legen und genau zu beschränken, wer darauf zugreifen darf. Administratoren können sich aus der Ferne über ein VPN, einen abgesicherten Jump-Host oder eine kontrollierte Zugriffsschicht verbinden.

Die Erreichbarkeit ist hier der entscheidende Faktor. Kann ein Scanner aus dem Internet keine Verbindung zur Management-API aufbauen, lässt sich eine unauthentifizierte API-Schwachstelle aus der Ferne kaum ausnutzen. Ein Patch bleibt Pflicht, doch Netzwerksegmentierung sorgt dafür, dass eine unbekannte Lücke erst eine weitere Barriere überwinden muss, bevor sie zum echten Vorfall wird.

Für weitere Einblicke in die Plattform und deren Netzwerkdesign lohnt sich die Mr.PlanB Proxmox-Übersicht.

Reicht ein Management-VLAN allein aus?

Nein, denn ein VLAN für sich allein erzwingt keinerlei Schutz. Sie benötigen ein Management-Segment in Kombination mit Firewall-Regeln, die den Zugriff strikt begrenzen.

Normale Client-Geräte, IoT-Systeme, öffentlich erreichbare Anwendungs-VMs, Gäste-WLANs und DMZ-Workloads haben keinen Grund, Verbindungen zur Proxmox-Verwaltungsoberfläche aufzubauen. Eine Administrations-Workstation oder ein Jump-Host benötigt Zugriff. Ein Monitoring-System braucht vielleicht eng begrenzte API-Rechte, und ein Backup- oder Automatisierungssystem benötigt bestimmte Management-Endpunkte. Blockieren Sie alles andere.

Ein Administrator beschrieb sein Management-Segment als vollständig ungeroutet, abgesehen von einem kontrollierten Administrationspfad. Ein anderer betonte, dass selbst interne Benutzernetze Verwaltungsschnittstellen nicht standardmäßig sehen dürfen. Beide Ansätze gehen in die richtige Richtung.

Gehen Sie nicht davon aus, das Internet sei böse und das lokale LAN vertrauenswürdig. Ein kompromittierter Laptop, eine verwundbare Web-Applikation, ein infiziertes IoT-Gerät oder entwendete VPN-Zugangsdaten machen ein internes Netz schnell zum Angriffsvektor. Wenden Sie das Prinzip der geringsten Rechte sowohl zwischen Netzwerkzonen als auch zwischen Benutzerkonten an.

Was tun, wenn ein betroffener Host öffentlich erreichbar war?

Behandeln Sie die Situation als potenziellen Sicherheitsvorfall und nicht bloß als verspätete Patch-Aufgabe. Schränken Sie zuerst den Zugriff ein. Kappen Sie, sofern möglich, sofort den öffentlichen Zugriff auf Port 8006 per Firewall, Upstream-ACL, VPN-Zwang oder Managementnetzwerk, damit nicht vertrauenswürdige Netze den Host nicht länger direkt erreichen können.

Führen Sie anschließend ein Upgrade auf ein unterstütztes Proxmox-Release durch, oder folgen Sie den Herstelleranweisungen, falls betriebliche Gründe ein sofortiges Major-Upgrade ausschließen. Untersuchen Sie das System: Überprüfen Sie aktive Benutzer und Authentifizierungseinstellungen. Suchen Sie nach unerwarteten Benutzern, geänderten Passwörtern, API-Tokens, autorisierten SSH-Schlüsseln und ungeklärten Konfigurationsänderungen. Durchforsten Sie die Proxmox-Task-Historie und Systemlogs nach unbekannten Administrationsaktionen und prüfen Sie Firewall-Regeln, Storage-Definitionen, VM-Konfigurationen, Backup-Einstellungen und Cronjobs.

Rotieren Sie alle Zugangsdaten, die kompromittiert worden sein könnten. Hielt der Host Geheimnisse vor, denen Gastsysteme oder externe Dienste vertrauten, sollten diese ebenfalls erneuert werden. Haben Sie den konkreten Verdacht eines Einbruchs, sichern Sie die Logdateien vor einer Bereinigung für forensische Zwecke.

Bei einem Authentifizierungs-Bypass sieht ein erfolgreicher Angreifer nach der ersten Anfrage wie ein regulär angemeldeter Administrator aus. Dass keine fehlgeschlagenen Anmeldeversuche im Log stehen, hat daher wenig Aussagekraft. War der Host verwundbar und erreichbar, beweist das Ausbleiben einer offensichtlichen Warnmeldung keineswegs, dass nichts passiert ist.

Ein Proxmox Health Check hilft dabei, Konfigurationsschwächen aufzudecken, bei einem konkreten Einbruchsverdacht ist jedoch vollwertiges Incident-Response nötig, das weit über reine Konfigurationsanalysen hinausgeht.

War die Warnung "PROXMOX JETZT AKTUALISIEREN" zu reißerisch?

Die Dringlichkeit war für bestimmte Setups absolut berechtigt, das Auslassen der Versionsdetails verzerrte die Botschaft jedoch spürbar. Die Schwachstelle ist hochkritisch. Wenn ein nicht authentifizierter Angreifer ohne Kenntnis des Passworts potenziell zu root@pam werden kann, ist das ein gravierender Vorfall. Und dass CrowdSec kurz nach der Veröffentlichung passenden Exploit-Traffic registrierte, verlangt ebenfalls Aufmerksamkeit.

Dennoch sollte ein Administrator auf einem aktuellen PVE 9 oder einer gepatchten späteren PVE 8-Installation nach dem Lesen einer solchen Schlagzeile nicht glauben müssen, sein Host habe sich gerade einen 3 Jahre alten Auth-Bypass eingefangen.

Eine treffendere Warnung hätte gelautet: Wer PVE 7 oder ein frühes PVE 8.0-System mit libpve-access-control unter 8.0.4 betreibt, muss sein System jetzt prüfen. War dieser Host aus unsicheren Netzen erreichbar, untersuchen Sie ihn auf Kompromittierung. Setzen Sie ein aktuelles, unterstütztes PVE-Release ein, liegt diese CVE längst hinter Ihnen. Diese Fassung ist weniger dramatisch, dafür fachlich präzise und umsetzbar.

Die Verwaltungsebene wiegt schwerer als eine einzelne CVE

CVE-2023-54391 ist insofern ungewöhnlich, als sie erst Jahre nach der Beseitigung des Codes in neueren Proxmox-Versionen öffentlich wurde. Manche Administratoren hatten vor langer Zeit ein Upgrade durchgeführt und damit unbemerkt einen kritischen Auth-Bypass beseitigt. Andere blieben auf PVE 7 und blieben verwundbar, ebenfalls ohne es zu wissen.

Niemand muss jedes Update in der Minute seines Erscheinens einspielen, denn Änderungen an Infrastruktur verlangen Tests. Major-Upgrades auf unbestimmte Zeit aufzuschieben, fordert jedoch seinen Tribut bei der Sicherheit, und eine offene Verwaltungsebene treibt diese Kosten drastisch in die Höhe.

Halten Sie Proxmox auf einem unterstützten Release, verbannen Sie die Managementoberfläche aus dem öffentlichen Internet, nutzen Sie MFA und segmentieren Sie den Administrationsverkehr. Bevor Sie auf Sicherheits-Schlagzeilen reagieren, ermitteln Sie die exakte Paketversion auf Ihren Systemen.

Sollte ein nicht mehr unterstützter Hypervisor bei Ihnen noch laufen, weil "er seit Jahren problemlos funktioniert", rufen Sie sich in Erinnerung: Diese CVE schlummerte jahrelang unbemerkt in Altsystemen, auch bei jenen, die sich ganz bewusst gegen ein Upgrade entschieden hatten.