Veeam-Sicherheit: 9,9-CVEs und offengelegte Backup-Server

Die Veeam-Sicherheitsprobleme im Jahr 2026 zeigen, dass Patchen notwendig ist, über die Sicherheit einer Backup-Umgebung aber allein nicht entscheidet. Kritische Schwachstellen, Produktionsdomänen-Mitgliedschaft, Management-Exposition und die Art, wie Administratoren auf Veeam Backup & Replication zugreifen, prägen gemeinsam das tatsächliche Risiko.

Eine Administratoren-Warnung vom 12. März 2026 wies auf mehrere neu offengelegte Schwachstellen in Veeam 12 und 13 hin, darunter Probleme mit einer Bewertung von bis zu CVSS 9,9. Diese Diskussion folgte nur wenige Monate nach einem weiteren kritischen Veeam-Patch-Zyklus im Oktober 2025. Dann fand im Mai 2026 ein weiterer Administrator einen Veeam-Backup-&-Replication-Server, der direkt aus dem Internet erreichbar war, ohne gültiges TLS-Zertifikat. Die Fehler sind unterschiedlich, betreffen aber dieselbe Sicherheitsfrage.

Warum verdienen 9,9-CVEs bei Veeam sofortige Aufmerksamkeit?

Ein CVSS-9,9-Problem auf einem Backup-Management-Server verdient schnelle Aufmerksamkeit, weil der Server in unmittelbarer Nähe zu einigen der wertvollsten Systeme einer Infrastrukturlandschaft sitzt. Er weiß, wo Backups liegen, kommuniziert mit Repositories, koordiniert Proxys und Restore-Operationen und hat oft weitreichende Sichtbarkeit in Virtualisierungs- und Anwendungsumgebungen.

Im Thread vom März 2026 planten Administratoren, die die Warnung erhielten, sofort Patch-Fenster. Ein Teilnehmer rollte gerade Version 13 aus und erkannte, dass die neue Sicherheitsveröffentlichung bedeutete, laufende Arbeit zu überarbeiten. Ein anderer wies darauf hin, dass Veeam für relativ aktuelle Version-12-Installationen kleinere Patch-Pakete anbot, während ältere Builds das komplette Installationsmedium benötigen konnten, bevor der Patch angewendet werden konnte.

Die Diskussion vom Oktober 2025 liefert nützlichen historischen Kontext. CVE-2025-48983 und CVE-2025-48984 wurden beide als CVSS-9,9-Remote-Code-Execution-Probleme diskutiert, die domänenbeigetretene Veeam-Server betreffen. Neben dem Patching ging es dort sofort um die Frage, warum eine authentifizierte Domänenidentität überhaupt einen Pfad zur Backup-Kontrollebene haben sollte.

Dasselbe Prinzip gilt über Virtualisierungs-Backup-Stacks hinweg. Der VMware-Backup-Vergleich konzentriert sich auf Wiederherstellungswerkzeuge, aber jede Backup-Plattform ist ein privilegiertes Management-System und sollte auch so bewertet werden.

Macht Domänenmitgliedschaft einen Veeam-Server unsicher?

Ob Domänenmitgliedschaft unsicher ist, lässt sich nicht mit Ja oder Nein beantworten. Der entscheidende Unterschied in den Administratoren-Diskussionen lag zwischen dem Beitritt von Veeam zur Produktionsdomäne und der Platzierung in einer bewusst isolierten Management-Domäne.

Mehrere Teilnehmer beschrieben zunächst jeden domänenbeigetretenen Veeam-Server als schlechte Praxis. Andere korrigierten diese Aussage und verwiesen auf Veeams eigene Härtungsrichtlinien. Eine isolierte Domäne kann zentrale Authentifizierung, Richtlinienkonsistenz und Auditierung bieten, ohne den Backup-Server direkt an dieselbe Identitäts-Fehlerdomäne wie die Produktions-Workloads zu binden.

Hier muss jede Umgebung abwägen. Eine kleine Umgebung entscheidet sich vielleicht dafür, dass eine Workgroup-Bereitstellung leichter zu isolieren ist und weniger Abhängigkeiten hat. Ein großes Unternehmen braucht möglicherweise zentrale Identität, kann Veeam aber in eine separate administrative Domäne mit kontrolliertem Vertrauen stellen. Die gefährliche Abkürzung besteht darin, die produktive Active-Directory-Umgebung als Standardort für die Backup-Kontrollebene zu behandeln, nur weil das bequem ist.

Bequemlichkeit ist genau das, was Angreifer bei lateraler Bewegung ausnutzen. Der Administrator, der sagte, jede administrative Unannehmlichkeit erzeuge für einen Angreifer eine viel größere Unannehmlichkeit, hat die betriebliche Logik gut auf den Punkt gebracht. Sicherheitsarchitektur fühlt sich oft lästig an, solange alles gesund ist, und zahlt sich aus, wenn eine Vertrauensdomäne kompromittiert wird.

Warum kann Veeam-Sicherheitspatching zu einem betrieblichen Problem werden?

Der Patch selbst mag unkompliziert sein, Zeit verlieren Administratoren eher bei der Wahl des richtigen Patch-Pfads. Im Thread vom Oktober 2025 verglichen Anwender eine reine Patch-EXE, eine Patch-ISO und die vollständige Installations-ISO, je nach installiertem Build.

Ein Administrator berichtete, dass die ISO statt der erwarteten Upgrade-Schaltfläche eine Modify-Schaltfläche anzeigte und dann einen Fehler ausgab, dass bereits eine andere Version installiert sei. Ein anderer Teilnehmer erklärte, dass neuere Patch-Auslieferungsmethoden darauf ausgelegt seien, Download-Größe und temporären Speicherbedarf zu reduzieren. Die Diskussion enthielt auch Witze darüber, dass das komplette Medium rund 15 bis 20 GB erreicht, was lustig ist, bis der Backup-Server nur begrenzten Systemspeicherplatz hat und bereits ein Notfall-Patch-Fenster läuft.

Ermitteln Sie deshalb den genauen installierten Build, bevor Sie irgendetwas herunterladen. Nutzen Sie dann die Release Notes des Herstellers für diesen Build und wählen Sie den unterstützten Patch-Pfad. Gehen Sie nicht davon aus, dass die vollständige ISO immer die sicherste Wahl ist, nur weil sie alles enthält.

Bestätigen Sie nach dem Patchen, dass die Veeam-Dienste starten, die Konsole sich verbindet, Repositories erreichbar sind, geplante Jobs laufen und mindestens ein kleiner Restore-Pfad weiterhin funktioniert. Solange die Wiederherstellung nicht funktioniert, ist die Sicherheitswartung nicht abgeschlossen, auch wenn die Software gepatcht ist.

Warum ist ein öffentlich erreichbarer VBR-Server eine andere Problemklasse?

Ein öffentlich erreichbares Management-Interface von Veeam Backup & Replication erzeugt ein Risiko, das eine Zertifikatserneuerung nicht beheben kann. Der Fall vom Mai 2026 beschrieb einen VBR-Server, der über eine ISP-Subdomain exponiert war und kein gültiges TLS-Zertifikat besaß. Nach der Offenlegung behob der Betreiber offenbar das Zertifikat, während der Dienst weiterhin von außen erreichbar blieb. Damit bleibt das größere Problem bestehen: TLS schützt den Transport und hilft, die Server-Identität zu belegen, aber ein unnötiges öffentliches Management-Interface wird dadurch kein gutes Design.

Der stärkste Kommentar in dieser Diskussion sagte, der VBR-Server solle hinter einer Firewall sitzen und nur über ein internes Netzwerk, ein VPN oder einen kontrollierten Zero-Trust-Zugriffspfad erreichbar sein. Management-Systeme sollten nur wenige Nutzer und wenige, klar definierte Zugangswege haben.

Das wird noch wichtiger, wenn die Backup-Plattform Hypervisoren schützt. Mr.PlanBs Proxmox-Backup-Leitfaden vergleicht Veeam mit Proxmox Backup Server und anderen Tools, aber die Sicherheitsregel ist plattformunabhängig: Das System, das die gesamte Umgebung wiederherstellen kann, sollte nicht wie eine öffentliche Anwendung exponiert sein.

Was sollte nach einer neuen Veeam-Sicherheitswarnung geprüft werden?

Beginnen Sie mit der Inventarisierung. Erfassen Sie den genauen Build von Veeam Backup & Replication, das Betriebssystem, den Domänen- oder Workgroup-Status, die Management-Interfaces, die Repository-Typen und alle externen Netzwerkpfade, die den Server erreichen können.

Trennen Sie dann die Reaktion auf die Schwachstelle von der Reaktion auf die Architektur. Ein Patch schließt ein bekanntes Softwareproblem. Netzwerkisolation, privilegiertes Identitätsdesign, MFA wo unterstützt, eingeschränkte Remote-Administration und Repository-Härtung verringern die Wahrscheinlichkeit, dass die nächste Schwachstelle zu einem leichten Einstieg in die Backup-Umgebung wird.

Auch Konfigurationssicherungen sind wichtig. Eine Sicherheitsreaktion, die sich nur auf die Backup-Dateien konzentriert, kann die Konfigurationsdatenbank, Verschlüsselungspasswörter, Repository-Definitionen, Anmeldedaten und Wiederherstellungsverfahren vergessen, die während eines echten Vorfalls benötigt werden, um diese Backups zu nutzen.

Testen Sie schließlich nach größerer Sicherheitswartung einen Restore. Ein grüner Patch-Bericht sagt wenig darüber, ob Sie danach noch ein vertrauenswürdiges Wiederherstellungssystem haben.

Was würde ich nach diesen Fällen mit einem Veeam-Server tun?

Ich würde den Veeam-Server als hochprivilegierte Management-Ebene behandeln. Ich würde ihn zügig patchen, ihn außerhalb der Produktionsdomäne halten, sofern kein bewusstes isoliertes Domänendesign vorliegt, den Management-Zugriff auf bekannte administrative Pfade beschränken und verifizieren, dass kein VBR-Interface unbeabsichtigt aus dem öffentlichen Internet erreichbar ist.

Ich würde außerdem die Wiederherstellungsschichten unabhängig genug halten, damit ein kompromittiertes Management-System nicht automatisch jede Kopie kontrolliert. Das kann gehärtete Repositories, Object Lock, Offline-Medien oder eine andere für die Umgebung geeignete Wiederherstellungsebene einschließen. Der PBS-Offline-Backup-Leitfaden zeigt dasselbe Prinzip aus Proxmox-Perspektive: Wiederherstellung wird stärker, wenn eine Kontrollebene nicht jede Option löschen kann.

Was Veeam-Sicherheit angeht, ist die wiederkehrende Lektion weniger dramatisch als der CVSS-Wert und dafür nützlicher: Kritische Patches sind wichtig, aber wie viel Schaden die nächste kritische Schwachstelle anrichten kann, entscheidet die Architektur.