Das Wichtigste in 30 Sekunden
- In Proxmox VE 7 reicht ein einzelner Login-Parameter, um die Passwortprüfung komplett zu überspringen — Ergebnis: root ohne Passwort.
- Proxmox hat die Warnung PSA-2026-00043-1 am 1. September veröffentlicht, die Lücke trägt die Kennung CVE-2023-54391.
- Es gibt einen öffentlichen Exploit, und die Lücke wird ausgenutzt: Betroffene berichten von verschlüsselten Hosts, Lösegeldforderungen und heimlich installierten Krypto-Minern.
- Betroffen ist das Paket
libpve-access-controlvon 7.0-7 bis vor 8.0.4 — also Proxmox VE 7.0 bis 7.4 und die allerersten 8.0-Installationen.
Wenn in deinem Keller, im Rack oder bei einem Kunden noch ein Proxmox VE 7 läuft, dann ist das hier deine wichtigste Aufgabe für heute. Denn die Lücke, um die es geht, braucht keinen Trick, keine Vorbereitung und kein Passwort. Sie braucht nur, dass die Weboberfläche erreichbar ist.
Ein Parameter, und die Passwortprüfung ist weg
Der Anmeldevorgang von Proxmox läuft über einen einzigen Aufruf: POST /api2/json/access/ticket. Dort schickst du normalerweise Benutzername und Passwort hin und bekommst ein Ticket zurück, mit dem du dich im Webinterface bewegst.
In diesem Aufruf gibt es zusätzlich den Parameter tfa-challenge. Der ist eigentlich für Konten mit zweitem Faktor gedacht. Das Problem: Bei Konten ohne zweiten Faktor wurde dieser Parameter nie geprüft. Schickt ein Angreifer ihn einfach mit — der Inhalt ist beliebig —, dann überspringt die Anmeldung die Passwortprüfung vollständig.
Das Ergebnis ist so schlicht wie brutal: Der Angreifer landet als jeder aktivierte Benutzer ohne Zwei-Faktor-Authentifizierung im System. Und in einer Standardinstallation ist das root@pam.
Der Patch war schon 2023 da — nur wusste keiner, dass es einer war
Der bemerkenswerteste Teil der Geschichte: Die betroffene Codestelle wurde bereits im Juli 2023 geändert. Damals war aber niemandem klar, dass es sich um einen Sicherheitsfix handelt. Deshalb gab es keine Warnung, keinen Hinweis im Changelog und keine CVE-Nummer. Die kam erst drei Jahre später — und trägt bis heute die Jahreszahl 2023 im Namen.
Für dich heißt das: Wenn dein Host irgendwann nach Mitte 2023 auf eine aktuelle 8er- oder 9er-Version aktualisiert wurde, hast du den Fix längst mitgenommen, ohne es zu merken. Wer dagegen bei 7.x hängen geblieben ist, sitzt auf einer offenen Tür.
Es ist kein Gedankenspiel mehr
Aufgefallen ist die Sache über das Proxmox-Forum: Ende August meldete ein Nutzer, dass seine Proxmox-VE-7-Installation verschlüsselt wurde und Lösegeld gefordert wird. Proxmox selbst schreibt, man habe innerhalb von zwei Tagen viele voneinander unabhängige Meldungen erhalten, die ebenfalls von einer Ausnutzung in der Praxis berichten.
Inzwischen kursiert ein öffentlicher Proof of Concept. Damit ist die Hemmschwelle praktisch bei Null: Wer eine Liste offener Proxmox-Oberflächen hat, kann sie in Serie durchprobieren. Neben Verschlüsselung wurden auch untergeschobene Krypto-Miner beobachtet — also der zweite klassische Weg, aus fremder Rechenleistung Geld zu machen.
So prüfst du in zwei Minuten, ob du betroffen bist
Melde dich per SSH auf dem Host an und schau dir zuerst die Version an:
pveversion
dpkg -l libpve-access-controlSteht dort eine 7er-Version von Proxmox VE oder eine Version von libpve-access-control, die kleiner als 8.0.4 ist, dann bist du dran. Auch die ganz frühen 8.0-Installationen gehören dazu — das überrascht viele, die sich wegen der 8 in Sicherheit wiegen.
Was du jetzt in dieser Reihenfolge tun solltest
- Weboberfläche vom Internet nehmen. Port 8006 hat auf einer öffentlichen Adresse nichts verloren. Wenn du von außen ran musst, dann über VPN oder einen SSH-Tunnel auf
DEINE-SERVER-IP. Das ist die Sofortmaßnahme, noch vor dem Update. - Aktualisieren. Proxmox VE 7 ist am Ende seines Lebenszyklus. Der saubere Weg ist der Sprung auf eine gepflegte 8er- oder 9er-Version. Das ist Arbeit, aber es ist die einzige Lösung, die auch morgen noch hält.
- Zwei-Faktor für root aktivieren. Die Lücke greift nur bei Konten ohne zweiten Faktor. Ein Hardware-Schlüssel oder TOTP am root-Konto ist ohnehin gute Praxis.
- Nach Spuren suchen. Ungewöhnliche Cronjobs, fremde SSH-Schlüssel in
/root/.ssh/authorized_keys, Prozesse mit dauerhaft hoher CPU-Last, neue Benutzer oder API-Tokens in der Proxmox-Rechteverwaltung. Wer schon drin war, hinterlässt meistens eine Hintertür. - Backups prüfen — aber offline. Ein Backup, das der Host selbst beschreiben kann, ist bei Verschlüsselungsangriffen oft mit betroffen. Eine Kopie, die nicht dauerhaft am Netz hängt, ist Gold wert.
Die Lehre, die über Proxmox hinausgeht
Diese Lücke ist ein Lehrstück in zwei Richtungen. Erstens: End-of-Life ist kein Papierkram. Ein System ohne Sicherheitsupdates ist keine sparsame Entscheidung, sondern eine Wette — und diese Wette wurde gerade verloren. Zweitens: Verwaltungsoberflächen gehören nicht ins offene Netz. Egal ob Proxmox, ein NAS oder eine Firewall-Zentrale: Die Konsole ist das wertvollste Ziel auf deinem Server, und sie ist auch die, die am häufigsten aus Bequemlichkeit offen steht.
Wenn du heute Abend nur eine Sache machst: Tippe pveversion und schau auf die erste Zahl.
Häufige Fragen
Bin ich auch mit Proxmox VE 8 oder 9 betroffen?
Nur, wenn du eine der allerersten 8.0-Installationen fährst und das Paket libpve-access-control älter als 8.0.4 ist. Alles ab 8.0.4 und damit praktisch jede gepflegte 8er- oder 9er-Installation ist nicht betroffen. Prüfe es mit dpkg -l libpve-access-control statt mit dem Bauchgefühl.
Reicht es, wenn mein Proxmox nur im Heimnetz erreichbar ist?
Das Risiko sinkt deutlich, ist aber nicht null. Ein infizierter Rechner, ein Gastgerät im WLAN oder ein gekaperter Container im gleichen Netz kann die Lücke genauso nutzen. Außerdem gibt es erstaunlich viele Portweiterleitungen, die irgendwann für einen Test eingerichtet und dann vergessen wurden.
Hilft es, wenn ich Zwei-Faktor aktiviere, statt zu aktualisieren?
Zwei-Faktor entzieht der Lücke die Grundlage, weil der ungeprüfte Parameter nur bei Konten ohne zweiten Faktor greift. Als Notbremse ist das sinnvoll. Als Dauerlösung nicht: Proxmox VE 7 bekommt keine Sicherheitsupdates mehr, und die nächste Lücke wird dann nicht mehr geschlossen.
Woran erkenne ich, ob jemand die Lücke bei mir schon genutzt hat?
Typische Zeichen sind neue Benutzer oder API-Tokens in der Rechteverwaltung, fremde SSH-Schlüssel, unbekannte Cronjobs, dauerhaft hohe CPU-Last durch Miner und Lücken in den Logs. Wenn du Zweifel hast, ist eine Neuinstallation mit Wiederherstellung aus einem sauberen, offline gelagerten Backup der ehrlichere Weg als Suchen und Hoffen.