Kritische Lücken treffen Veeam, Terraform MCP und Django : Elf Schwachstellen gefährden Backup-Verwaltung, KI-gestützte Infrastruktursteuerung und Webanwendungen

Besonders kritisch sind drei Schwachstellen: In der Veeam Service Provider Console kann ein nicht angemeldeter Angreifer Zugangsdaten eines verwalteten Agenten erlangen. Der Terraform MCP Server kann in gemeinsam genutzten Installationen Tokens verschiedener Mandanten vermischen. Und bei GeoDjango können manipulierte räumliche Abfragen Dateien schreiben und unter bestimmten Bedingungen Code ausführen.

Veeam: Agent imitieren und Zugangsdaten übernehmen

Die Veeam Service Provider Console (VSPC) dient Hosting-Anbietern und Managed Service Providern zur zentralen Verwaltung der Backup-Systeme ihrer Kunden. Version 9.3.0.35057 schließt vier Schwachstellen; betroffen sind Version 9.2.1.33875 und ältere Builds der Versionsreihe 9 (vgl. List of Security Fixes and Improvements in VSPC). Am schwersten wiegt CVE-2026-58073 mit einem Common Vulnerability Score (CVSS) von 9,5: Ein Angreifer kann sich ohne Anmeldung als verwalteter Agent ausgeben und dessen Zugangsdaten erhalten. Die Einstufung weist allerdings eine hohe Angriffskomplexität aus: „Nicht authentifiziert“ bedeutet daher nicht automatisch, dass sich die Lücke einfach ausnutzen lässt. CVE-2026-58072 erreicht 9,0 Punkte. Ein Benutzer mit niedrigen Rechten kann beliebige Dateien auf dem Managementserver ablegen. Landet eine Datei an einer ausführbaren oder später geladenen Stelle, ist Remote-Code-Execution (RCE) möglich.

Hinzu kommen:

• CVE-2026-58067: nicht-authentifizierter Denial of Service (DoS) durch Erschöpfung des Arbeitsspeichers
• CVE-2026-58071: vorübergehender Zugriff auf die weitergeleitete Appliance-Programmierschnittstelle mit den Rechten eines Portal-Administrators

Veeam empfiehlt das Update aufVSPC 9.3.0.35057. Die Patch-Serie folgt nur wenige Monate auf CVE-2026-32998, eine weitere kritische RCE-Lücke in der Konsole.

Terraform MCP: Wenn Mandanten fremde Tokens erhalten

Der Terraform MCP Server verbindet KI-Assistenten über das Model-Context-Protocol (MCP) mit Terraform Cloud oder Terraform Enterprise. Die drei Schwachstellen betreffen ausschließlich den Streamable-HTTP-Modus für zentrale Mehrbenutzerinstallationen – lokal über Standard-Input/Output (stdio) betriebene Einzelplatzkonfigurationen sind nicht betroffen. Alle Fehler sind ab Version 1.1.0 behoben.

CVE-2026-16498 ist mit 10,0 bewertet und betrifft den zustandslosen HTTP-Modus. Die zugrunde liegende MCP-Bibliothek vergab dort keine eindeutigen Sitzungskennungen. Da der Server seinen Zwischenspeicher anhand dieser Kennungen trennt, konnte das Terraform-Token eines Mandanten für spätere Anfragen anderer Nutzer wiederverwendet werden – unabhängig davon, welches Token diese übermittelten. CVE-2026-16496 betrifft den standardmäßig aktiven Mehrbenutzermodus: Der Server speicherte die Terraform-Verbindung eines Nutzers nur unter dessen MCP-Sitzungs-ID, prüfte aber nicht zusätzlich, zu welchem Zugangstoken sie gehörte. Erlangte ein Angreifer die Sitzungs-ID eines anderen Nutzers, konnte er dessen gespeicherte Terraform-Verbindung übernehmen, Befehle mit dessen Rechten ausführen und auf die für dieses Konto freigegebenen Ressourcen zugreifen. Und CVE-2026-14869 ermöglicht Server-Side-Request-Forgery (SSRF): Eine vom Client vorgegebene Terraform-Adresse wurde zwar im HTTP-Header blockiert, nicht jedoch als Abfrageparameter. Ein nicht angemeldeter Angreifer konnte den Server dadurch veranlassen, sein hinterlegtes Bearer-Token an einen fremden Endpunkt zu senden. (HashiCorp Discuss)

Die CVSS-Werte dürfen hierbei allerdings nicht isoliert betrachtet werden: Die 10,0-Lücke betrifft nur ausdrücklich aktivierte zustandslose Installationen, während die mit 8,9 bewertete Schwachstelle im üblichen zentralen Betriebsmodus liegt. Betreiber sollten auf Version 1.1.0 oder neuer wechseln. Bis dahin sind der HTTP-Endpunkt auf vertrauenswürdige Nutzer zu beschränken und MCP-Sitzungs-IDs wie Zugangsdaten zu behandeln.

GeoDjango: Dateiablage über räumliche Abfragen

Django 6.0.8 und 5.2.17 beheben vier Schwachstellen. Die schwerwiegendste davon (CVE-2026-15307) betrifft GeoDjango, die Erweiterung für geografische Daten. Angreifer konnten speziell präparierte Werte in räumliche Datenbankabfragen einschleusen – GeoDjango behandelte diese unter bestimmten Umständen als Rasterdaten und übergab sie an die Bibliothek GDALRaster. Je nach eingesetztem Treiber konnte der Server dadurch Dateien auf dem System speichern oder Verbindungen zu externen Servern herstellen. Wurde eine manipulierte Datei an einem Ort abgelegt, von dem die Anwendung später Code lädt, war im schlimmsten Fall die Ausführung fremden Codes möglich. Der dokumentierte Angriffsweg setzt ein Mitarbeiterkonto mit Leserechten für ein im Administrationsbereich registriertes Modell mit Geodatenfeld voraus. Der Patch verbietet Wörterbuchobjekte sowie Zeichenketten, die keine gültigen GEOSGeometry-Werte darstellen. Diese Änderung kann jedoch bestehende Anwendungen beeinträchtigen.

Die drei weiteren Django-Lücken sind:

• CVE-2026-15920: gespeichertes Cross-Site Scripting (XSS) durch unsichere URLField-Werte im Administrationsbereich
• CVE-2026-15830: DoS durch tief verschachtelte GEOMETRYCOLLECTION-Objekte; Django begrenzt diese nun auf 198
• CVE-2026-15337: erhöhter Speicherverbrauch durch sehr lange Sprachcodes; Werte über 500 Zeichen werden jetzt abgewiesen

Die Django Software Foundation rät zum sofortigen Wechsel auf Django 6.0.8 oder 5.2.17 – nicht mehr unterstützte Zweige wie 5.1, 5.0 und 4.2 wurden nicht geprüft und könnten ebenfalls betroffen sein.

Djangos Funktionen für geografische Daten sind bereits seit einiger Zeit im Blick von Angreifern. Im Februar schloss das Projekt mit CVE-2026-1207 eine SQL-Injection-Lücke in PostGIS-Rasterabfragen. CrowdSec beobachtete später auch tatsächliche Angriffsversuche: Nach Veröffentlichung einer Erkennungsregel am 18. Februar wurden am 26. Februar die ersten Attacken registriert. Danach suchten Angreifer fortlaufend nach öffentlich erreichbaren Django-Anwendungen, die PostGIS verwenden. Die damalige Schwachstelle ließ sich allerdings nur ausnutzen, wenn die Anwendung PostGIS einsetzte und Angreifer bestimmte Eingaben in einer passenden Datenbankabfrage beeinflussen konnten. Die Scans zeigten daher zunächst nur, welche Systeme grundsätzlich infrage kamen.

Auch bei der neuen GeoDjango-Lücke reicht das bloße Auffinden einer betroffenen Anwendung nicht aus. Für den bekannten Angriffsweg benötigt der Täter zusätzlich ein Mitarbeiterkonto mit den passenden Leserechten. Die Scans liefern also noch keinen direkten Zugang. Sie zeigen aber, dass Angreifer GeoDjango gezielt nach verwertbaren Schwachstellen untersuchen.

Konfiguration bestimmt die tatsächliche Gefahr

Die elf hier vorgestellten Schwachstellen betreffen sehr unterschiedliche Angriffsflächen: Veeam exponiert eine zentrale, mandantenfähige Backup-Verwaltung, Terraform MCP verbindet KI-Systeme mit privilegierten Infrastrukturzugängen und GeoDjango verarbeitet komplexe externe Datenformate. Priorität sollten Systeme erhalten, die aus dem Internet erreichbar sind, mehreren Mandanten dienen oder besonders weitreichende Tokens und Verwaltungsrechte besitzen.

Newsletter-Hinweis: Sie interessieren sich für Informationen zu heiklen Schwachstellen? Unter https://www.datakontext.com/newsletter können Sie kostenfrei den wöchentlichen “Cyberlage | Threat Watch Newsletter” der <kes> in Zusammenarbeit mit ConSecur abonnieren.