YuSMP Group
YuSMP Group Redaktion YuSMP Group · Softwareentwicklung, Cloud & DevOps und Sicherheitsaudits für Unternehmen im DACH-Raum
Techniker prüft im abgedunkelten Serverraum einen Server mit dem Tablet, im Vordergrund steht eine Aufklärungsdrohne auf einem Tisch

Die kurze Antwort

Angreifer haben bei Quantum Systems nicht die Drohnen attackiert, sondern den Verteilweg für Software-Updates. Die manipulierte Datei erreichte Server der Bundeswehr und weiterer Kunden, wurde dort aber bei einer Prüfung abgefangen. Laut Unternehmen ist die Bedrohung eingedämmt, die Flotte fliegt wieder.

Für Softwareanbieter im Mittelstand ist das die eigentliche Nachricht: Wer Updates ausliefert, betreibt kritische Infrastruktur für seine Kunden. Signierschlüssel, Build-Pipeline und Update-Server gehören deshalb regelmäßig in einen Penetrationstest und Sicherheitsaudit, nicht nur die Anwendung selbst.

Was ist bei Quantum Systems passiert?

Quantum Systems hat nach eigenen Angaben Ende Oktober einen Vorfall durch „feindliche Akteure“ festgestellt und ihn am Donnerstagabend, 12. November, öffentlich gemacht. Das Handelsblatt beschreibt das Unternehmen als milliardenschweres Münchner Start-up, das unter anderem Aufklärungs- und Abwehrdrohnen herstellt und die Bundeswehr beliefert.

Nach Recherchen des Bayerischen Rundfunks war der Angriff raffiniert orchestriert. Die Täter spielten Schadsoftware auf Server des Herstellers. Diese hätte bei einem Update die Drohnen infizieren und sie zumindest zeitweise unbrauchbar machen sollen. Das konnte verhindert werden. Berichten von Spiegel und Financial Times zufolge war die Datei als Update für Qbase getarnt, die Software zur Missionsplanung der Aufklärungsdrohne Vector.

Wie hat die Bundeswehr reagiert?

Die Bundeswehr erklärte laut Unternehmen von Freitagnachmittag bis Anfang der folgenden Woche ein Flugverbot für die Drohnen in Deutschland. Nach Angaben von Quantum Systems war sie der einzige Kunde, der die Systeme sicherheitshalber aus dem Verkehr zog. Inzwischen fliegen auch die Bundeswehr-Drohnen wieder. Das Verteidigungsministerium äußerte sich nicht.

ZeitpunktEreignis
Ende Oktober 2026Quantum Systems entdeckt Schadsoftware auf einem internen Update-Server
DanachManipulierte Datei erreicht Server von Bundeswehr und weiteren Kunden, wird bei einer Prüfung erkannt
Freitag bis Anfang der FolgewocheFlugverbot der Bundeswehr für die Drohnen in Deutschland
12. November 2026Unternehmen bestätigt den Angriff öffentlich, Bedrohung laut eigener Aussage eingedämmt
13. November 2026Verfassungsschutz, MAD und BSI ermitteln, Täter weiter unbekannt

Warum ist der Update-Server so ein lohnendes Ziel?

Ein Update-Server ist ein Vertrauensanker: Kunden installieren, was ihr Lieferant schickt, oft automatisch und mit weitreichenden Rechten. Wer diesen Kanal kapert, muss nicht jedes Zielsystem einzeln knacken, sondern lässt sich vom Hersteller selbst hineintragen, bis in Netze, die nach außen abgeschottet sind.

Genau so funktionieren Angriffe auf die Software-Lieferkette. Bei Quantum Systems griff am Ende eine Kontrolle beim Kunden. Das ist ein gutes Zeichen für die Prüfprozesse der Bundeswehr, aber kein Konzept, auf das sich Anbieter verlassen sollten. Ziel muss sein, dass eine manipulierte Datei gar nicht erst als gültiges Update durchgeht. Das ist zuerst eine Aufgabe für Cloud & DevOps: Build-Pipeline, Artefakt-Speicher und Verteilung gehören gehärtet und voneinander getrennt.

Welche Schutzmaßnahmen sollten Softwareanbieter prüfen?

Fünf Maßnahmen begrenzen den Schaden, falls ein Server in der Update-Kette kompromittiert wird:

  1. Updates kryptografisch signieren. Der Client installiert nur Pakete mit gültiger Signatur. Der private Schlüssel liegt in einem Hardware-Sicherheitsmodul, nicht auf dem Build- oder Update-Server.
  2. Bauen und Verteilen trennen. Wer den Download-Server übernimmt, darf damit keine neuen Pakete signieren können. Getrennte Zugänge und Rollen begrenzen den Schaden.
  3. Herkunft nachweisbar machen. Eine Software-Stückliste (SBOM) und nachvollziehbare Builds zeigen, was in einem Paket steckt. Ein Abhängigkeits-Audit mit SBOM ist ein schneller Einstieg.
  4. Gestaffelt ausrollen. Updates erst an eine kleine Gruppe, mit Überwachung und Rückrollplan, bevor die ganze Kundenbasis sie erhält.
  5. Den Ernstfall üben. Wer informiert Kunden, wer meldet an Behörden, wer sperrt den Verteilweg? Das muss vor dem Vorfall feststehen, nicht danach.

Für Kunden gilt die Umkehrung: Updates kritischer Systeme nicht ungeprüft durchreichen, sondern in einer Testumgebung abnehmen. Im Fall Quantum Systems hat genau diese Prüfung Schlimmeres verhindert.

Welche Meldepflichten gelten bei so einem Vorfall?

Seit dem 11. September 2026 greifen die ersten Pflichten des Cyber Resilience Act: Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb von 24 Stunden melden. Details dazu stehen in unserem Beitrag zur CRA-Meldepflicht. Für Betreiber wichtiger und besonders wichtiger Einrichtungen kommen die NIS2-Pflichten hinzu.

Ein kompromittierter Update-Kanal ist dabei kein Randfall. Er betrifft potenziell alle Kunden gleichzeitig, und die 24-Stunden-Frist lässt wenig Zeit für interne Abstimmung. Wer Firmware oder Software für Maschinen und Anlagen liefert, findet in der Embedded- und Firmware-Entwicklung die gleichen Fragen: Signatur, sicherer Bootvorgang, kontrollierte Aktualisierung im Feld.

Wie ernst ist die Bedrohungslage in Deutschland?

Der bayerische Wirtschaftsstaatssekretär Tobias Gotthardt sagte laut tagesschau, der Vorfall zeige das Ausmaß der Bedrohung durch sogenannte hybride Angriffe, also Sabotage, Desinformation und Cyberattacken gegen wichtige Einrichtungen. Der Digitalverband Bitkom schätzt die Schäden durch Cybercrime bei deutschen Unternehmen auf bis zu 200 Milliarden Euro pro Jahr.

Quantum Systems arbeitet nach eigenen Angaben eng mit Verfassungsschutz, Militärgeheimdienst MAD und dem Bundesamt für Sicherheit in der Informationstechnik (BSI) zusammen. Einen Täter haben die Behörden bisher nicht öffentlich benannt.

Häufige Fragen

Was ist bei Quantum Systems passiert?

Der Drohnenhersteller aus Gilching bei München hat Ende Oktober 2026 einen Angriff durch nach eigenen Angaben feindliche Akteure festgestellt. Laut Medienberichten lag auf einem internen Update-Server Schadsoftware, getarnt als reguläres Update der Missionsplanungssoftware Qbase. Das Unternehmen erklärte die Bedrohung am 12. November für eingedämmt.

Waren die Drohnen selbst infiziert?

Nach den bisherigen Berichten nicht. Die manipulierte Datei erreichte zwar Server der Bundeswehr und weiterer Kunden, wurde aber bei einer Prüfung entdeckt, bevor sie auf Drohnen gelangte. Quantum Systems betont, der Betrieb der Systeme sei mit keinem Risiko verbunden.

Warum sind Update-Server ein beliebtes Angriffsziel?

Kunden installieren Updates ihres Lieferanten in der Regel mit hohem Vertrauen und oft automatisiert. Wer den Verteilweg kontrolliert, erreicht viele Systeme auf einmal, auch in abgeschotteten Netzen. Deshalb gelten Build- und Update-Infrastruktur als Teil der Software-Lieferkette, die eigens geschützt werden muss.

Welche Meldepflichten gelten bei einem solchen Vorfall?

Das hängt vom Unternehmen und Produkt ab. Hersteller von Produkten mit digitalen Elementen müssen nach dem Cyber Resilience Act seit dem 11. September 2026 aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb von 24 Stunden melden. Für Betreiber wichtiger und besonders wichtiger Einrichtungen kommen die NIS2-Pflichten hinzu.

Quellen zum Angriff auf Quantum Systems

Handelsblatt — Drohnenhersteller Quantum Systems meldet massiven Cyberangriff (12. November 2026)
tagesschau.de — Cyberangriff auf Quantum Systems: Wie wurde der Drohnenhersteller zum Ziel? (13. November 2026)