Kritische Sicherheitslücken in Veeam Backup & Replication

Im 12er-Zweig sind laut Veeam alle Builds bis einschließlich 12.3.2.4165 betroffen. Abgesichert ist dieser Entwicklungszweig erst ab Version 12.3.2.4465. Im 13er-Zweig sind 13.0.1.1071 und alle früheren 13er-Builds betroffen; behoben wurden die Schwachstellen mit Version 13.0.1.2067. Veeam weist außerdem darauf hin, dass Kunden Patches ohne Verzögerung einspielen sollten, weil veröffentlichte Fixes regelmäßig per Reverse Engineering analysiert werden und dadurch schnell neue Angriffe auf ungepatchte Systeme entstehen können.

Der Kern des Problems ist nicht nur die Anzahl der Lücken, sondern ihre Nähe zum „Kronjuwel“ der Infrastruktur: dem Backup-Server. In Version 12 erlauben CVE-2026-21666 und CVE-2026-21667 authentifizierten Domain-Usern die Ausführung von Schadcode auf dem Backup-Server. In Version 13 ermöglicht CVE-2026-21669 dasselbe. Hinzu kommt mit CVE-2026-21708 eine weitere kritische Schwachstelle, über die ein Benutzer mit der Rolle „Backup Viewer“ Code als postgres ausführen kann.

Daneben existieren Lücken, die für Angreifer strategisch besonders wertvoll sind: CVE-2026-21668 erlaubt die Manipulation beliebiger Dateien in Backup-Repositories, CVE-2026-21670 ermöglicht das Auslesen gespeicherter SSH-Credentials, und CVE-2026-21672 eröffnet eine lokale Rechteausweitung auf Windows-basierten Veeam-Servern. In HA-Umgebungen der Veeam Software Appliance kommt mit CVE-2026-21671 noch eine weitere kritische RCE-Schwachstelle hinzu, die Benutzer mit Backup-Administrator-Rolle ausnutzen können.

Das macht die Lage vor allem aus Sicht der Cyber-Resilience brisant: Wer bereits einen Account im Active Directory oder in Veeam kompromittiert hat, kann sich über die Backup-Infrastruktur weiter in das Rechenzentrum ausbreiten, Wiederherstellungspunkte manipulieren oder die Wiederanlauffähigkeit gezielt sabotieren. Sicherheitsmedien wie BleepingComputer und CSO weisen zudem darauf hin, dass Backup-Server seit Jahren ein bevorzugtes Ziel von Ransomware-Akteuren sind, weil sich damit sowohl Daten zerstören als auch Wiederherstellungen verhindern lassen.

1. Patch-Stand sofort prüfen und aktualisieren
Wer Veeam Backup & Replication 12 einsetzt, sollte mindestens auf 12.3.2.4465 aktualisieren. Für Version 13 ist 13.0.1.2067 der notwendige Zielstand. Dabei sollte nicht nur der zentrale Backup-Server betrachtet werden, sondern die gesamte Veeam-Landschaft mit abhängigen Komponenten, Rollen und Anbindungen. Unsupported Builds sollten vorsorglich als verwundbar behandelt werden.

2. Rollen und Berechtigungen überprüfen
Die Advisories zeigen deutlich, dass „authentifiziert“ nicht gleich „harmlos“ ist. Wenn ein Domain-User, ein niedrig privilegierter Benutzer oder ein Backup Viewer bereits ausreichen kann, um kritische Folgen auszulösen, müssen Rollenmodelle konsequent überprüft werden. Backup Admin, Backup Operator und Backup Viewer sollten nur dort vergeben sein, wo sie tatsächlich notwendig sind. Service-Accounts gehören sauber getrennt, lokal privilegierte Zugriffe minimiert und Management-Zugänge zusätzlich abgesichert.

3. Backup-Infrastruktur härten und segmentieren
Backup-Systeme dürfen nicht wie gewöhnliche Infrastruktur behandelt werden. Sinnvoll ist eine klare Trennung in eigene Management- oder Security-Zonen, der Zugriff über definierte Administrationspfade wie Jump Hosts und eine strikte Begrenzung erlaubter Verbindungen per Firewall und ACL. Ebenso wichtig sind unveränderbare oder immutable Repositories, damit Angreifer selbst bei Teilzugriffen nicht ohne Weiteres Wiederherstellungspunkte manipulieren oder löschen können. Die technische Schwachstelle mag mit dem Patch geschlossen sein, das strukturelle Risiko bleibt ohne Härtung bestehen.

4. Monitoring und Incident Response nachziehen
Wer jetzt nur patcht, aber nicht hinschaut, verschenkt wertvolle Zeit. Zentrale Logs, Erkennung ungewöhnlicher Anmeldungen, Rollenänderungen, Massenlöschungen oder Repository-Zugriffe sollten fest in Monitoring und SIEM verankert sein. Gleichzeitig lohnt sich ein Blick zurück: Wurden verdächtige Zugriffe auf Veeam-Server, Repositories oder hinterlegte SSH-Zugänge bereits sichtbar? Da Veeam selbst vor einer schnellen Ausnutzung nach Veröffentlichung warnt, ist ein reines „Update und weiter“ zu kurz gedacht.

5. Restore-Fähigkeit praktisch testen
Die wichtigste Frage lautet nicht nur, ob ein Patch eingespielt wurde, sondern ob saubere und unveränderte Backups tatsächlich wiederherstellbar sind. Gerade bei Schwachstellen, die Dateimanipulation in Repositories oder Zugriff auf Zugangsdaten ermöglichen, sollten Restore-Tests kurzfristig eingeplant werden. Nur so lässt sich verlässlich prüfen, ob die eigene Recovery-Strategie im Ernstfall trägt.

Die aktuellen Veeam-Lücken zeigen einmal mehr: Backup-Infrastrukturen sind längst kein rein operatives IT-Thema mehr, sondern ein zentrales Sicherheitsobjekt. Wer dort Schwachstellen, überprivilegierte Rollen oder mangelnde Segmentierung zulässt, riskiert im Angriffsfall nicht nur Datenverlust, sondern den Verlust der gesamten Wiederherstellungsfähigkeit. Genau deshalb sollten Backup-Umgebungen wie hochprivilegierte Kernsysteme behandelt werden – mit Patch-Disziplin, minimalen Rechten, Härtung, Monitoring und regelmäßigen Recovery-Tests.

Für Verantwortliche gilt jetzt: priorisieren, patchen, prüfen, härten. Die geschlossenen Schwachstellen in Veeam Backup & Replication sind kritisch, weil sie direkt das System betreffen, das im Ernstfall die letzte Verteidigungslinie darstellt. Wer seine Veeam-Umgebung jetzt sauber aktualisiert und zugleich Berechtigungen, Architektur und Überwachung überprüft, reduziert nicht nur das akute Risiko – sondern stärkt die eigene Resilienz nachhaltig.