Ein präparierter Dateiname reicht: Simcenter Nastran patcht kritischen Speicherfehler

Ein präparierter Dateiname als Einfallstor

Ein einzelner Dateiname reicht aus, um Simcenter Nastran aus der Bahn zu werfen. Laut dem Sicherheitshinweis von CISA und Siemens verarbeitet die Berechnungssoftware bestimmte Zeichenketten als Dateiargument, ohne deren Länge ausreichend zu prüfen. Wird eine überlange, manipulierte Zeichenkette übergeben, läuft der reservierte Speicherbereich auf dem Stapel über – ein klassischer Fehler, der in der Baubranche des Maschinenbaus genauso wenig ausgestorben ist wie schlecht sitzende Schutzbrillen.

Damit der Fehler überhaupt zieht, muss jemand die betroffene Anwendung mit genau diesem präparierten Argument starten. Das setzt keine Netzwerklücke voraus, sondern eine Person, die eine Datei öffnet, ein Skript ausführt oder ein Kommando übernimmt, das sie für harmlos hält. Wer in Konstruktionsabteilungen regelmäßig Modelldateien aus E-Mails, Zulieferer-Portalen oder Projektlaufwerken lädt, hat das Einfallstor bereits im Alltag installiert, ganz ohne bösen Willen.

Bemerkenswert ist, wie unauffällig der Auslöser bleibt. Es braucht keinen sichtbar defekten Anhang, keine Warnmeldung des Virenscanners und keinen ungewöhnlichen Dateinamen mit krummen Endungen. Die schädliche Zeichenkette steckt im normalen Dateiargument, das die Anwendung ohnehin verarbeitet – ein Detail, das klassische Awareness-Schulungen kaum abdecken, weil sie meist auf offensichtlich verdächtige Anhänge zielen und nicht auf technisch unauffällige Simulationsdaten.

Wer glaubt, ein aktueller Virenscanner würde solche Dateien ohnehin abfangen, verwechselt Signaturerkennung mit Ursachenbekämpfung. Der Fehler liegt im Programmcode von Simcenter Nastran selbst, nicht in einem erkennbaren Schadprogramm-Muster – ein Grund, warum klassische Endpunkt-Schutzsoftware hier typischerweise still bleibt, bis der Schaden bereits entstanden ist.

Vom Stapelüberlauf zur Codeausführung

CISA verzeichnet die Lücke als CVE-2026-59086 mit einem CVSS-Basiswert von 7,8 – hoch genug, um sie nicht als Randnotiz zu behandeln, aber lokal genug, um keine automatische Massenausbreitung übers Internet zu erlauben. Der Angriffsvektor verlangt lokalen Zugriff und eine Interaktion der Nutzerin oder des Nutzers; wer die Datei nicht öffnet, bleibt verschont. Genau das macht die Lücke tückisch: Sie wirkt harmlos, bis ein einziger Klick auf die falsche Baugruppe genügt.

Gelingt der Überlauf, kann eine Angreiferin Code im Kontext des laufenden Prozesses ausführen – nicht mit frei erfundenen Rechten, sondern mit denen, die die Ingenieurin oder der Ingenieur beim Start der Anwendung ohnehin mitbringt. In vielen Konstruktionsumgebungen sind das administrative oder zumindest weitreichende lokale Rechte, weil Lizenzserver, Plugins und Compiler-Toolchains sonst ständig anecken. Der Sprung von einer beschädigten Speicherstruktur zu einer funktionierenden Hintertür ist damit kürzer, als man einem CAD-Werkzeug zutrauen möchte.

Praktisch bedeutet das für Vorfallsteams: Ein abgestürzter Nastran-Prozess ist nicht automatisch ein harmloser Bug-Report an den Support, sondern verdient eine kurze forensische Nachschau, wenn die zugrunde liegende Eingabedatei aus einer externen Quelle stammte. Ein Absturz mit ungewöhnlichem Speicherbild kurz vor Projektabgabe ist selten der ideale Zeitpunkt für Detektivarbeit, aber genau dann passiert er erfahrungsgemäß am häufigsten.

Wer den Angriffsvektor kühl durchrechnet, erkennt außerdem den kleinen Trost dieser Lücke: Sie eignet sich schlecht für breit gestreute Kampagnen, weil sie eine gezielte, dateibasierte Interaktion braucht. Für gezielte Angriffe auf einzelne Zulieferer oder Projektteams ist sie dagegen ideal geeignet – präzise, unauffällig und mit hoher Erfolgswahrscheinlichkeit, sobald die Zieldatei einmal geöffnet wurde.

Wer wirklich im Fadenkreuz steht

Betroffen sind laut Advisory Simcenter Nastran und Simcenter Femap in allen Versionen vor V2606 – zwei Werkzeuge, die in der Fertigungsindustrie, der Verteidigungsindustrie, der Energiewirtschaft, dem Gesundheitswesen und im Transportwesen strukturelle Simulationen rechnen. Das ist keine Nischensoftware für Hobbybastler, sondern ein Werkbank-Standard dort, wo Bauteile vor dem Prototyp bereits am Bildschirm brechen sollen, nicht erst im echten Betrieb.

Wie schnell ein einzelner Advisory-Eintrag operative Konsequenzen bekommt, zeigt sich auch in anderen kritischen Infrastrukturen: In unserer Einordnung eines zuvor aktiv ausgenutzten CISA-Advisorys ließ sich beobachten, wie schnell aus einer als moderat eingestuften Lücke ein reales Einfallstor wird, sobald Angreifer die betroffene Software gezielt suchen. Für Simcenter-Umgebungen bedeutet das: Wer glaubt, Simulationswerkzeuge seien für Kriminelle uninteressant, verwechselt fehlendes Interesse mit fehlender Angriffsfläche.

Interessant ist zudem die geografische Streuung laut Advisory: Die Einsatzländer reichen weltweit, während der Firmensitz des Herstellers in Deutschland liegt. Für global verteilte Engineering-Teams bedeutet das, dass ein Patch-Rollout selten an einem einzigen Standort endet, sondern über Zeitzonen, Sprachbarrieren und unterschiedliche IT-Governance-Strukturen hinweg koordiniert werden muss – ein organisatorisches Problem, das technisch betrachtet trivial klingt und praktisch selten trivial ist.

Besonders unangenehm wird es dort, wo Simcenter Nastran in automatisierte Freigabeprozesse eingebunden ist: Wenn ein Berechnungsergebnis über Serienfreigaben oder Zertifizierungen entscheidet, wirkt sich ein manipuliertes Ergebnis nicht nur auf einen einzelnen Arbeitsplatz aus, sondern potenziell auf die gesamte nachgelagerte Lieferkette eines Bauteils.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA defender hand removes a malformed shard from a glass simulation lattice and restores the missing structure with a clean fitted piece under cool inspection light. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed, readable text, labels, numbers, captions, UI, dashboards, screens.

Engineering-Arbeitsplätze sind die Angriffsfläche

Der eigentliche Übertragungsweg führt über den Arbeitsplatz der Konstrukteurin, nicht über einen offenen Port. Modelldateien wandern zwischen Zulieferern, Partnerfirmen und internen Teams, oft per E-Mail-Anhang oder über Freigabeordner, die niemand mehr im Detail kontrolliert. Eine kompromittierte Nastran-Eingabedatei sieht dabei aus wie jede andere Berechnungsdatei – bis sie geöffnet wird und den Stapelüberlauf auslöst.

Für Sicherheitsverantwortliche heißt das: Die Angriffsfläche liegt nicht am Perimeter, sondern auf jedem Rechner, auf dem Simcenter Nastran oder Femap installiert ist und Dateien aus externen Quellen verarbeitet. Wer Engineering-Workstations wie gewöhnliche Büro-PCs behandelt, unterschätzt, wie viele vertrauenswürdig aussehende Dateien dort täglich ohne zweiten Blick geöffnet werden.

Ein zusätzliches Risiko entsteht durch Automatisierung: Viele Simulationsumgebungen verarbeiten Eingabedateien per Batch-Skript, ohne dass eine Person die Datei je einzeln zu Gesicht bekommt. Läuft ein solcher Job unbeaufsichtigt über Nacht, kann der Stapelüberlauf ausgelöst werden, bevor überhaupt jemand die Ergebnisse prüft – und genau in diesem Moment fehlt der menschliche Blick, der sonst wenigstens gelegentlich Alarm schlägt.

Wer Engineering-Arbeitsplätze bislang nur nach Antivirus-Status und Festplattenverschlüsselung bewertet hat, sollte die Liste um eine Frage erweitern: Welche Anwendungen öffnen dort externe Modelldateien automatisch, und wer hat diese Automatisierung zuletzt überprüft? Genau an dieser Stelle wird aus einer bekannten Softwarelücke ein echtes betriebliches Risiko.

Der Patch: Update auf V2606 schließt die Lücke

Siemens hat die Lücke bereits behoben und rät im Advisory ausdrücklich zum Umstieg auf Version V2606 oder neuer. Der Hersteller stuft die Schwachstelle als CWE-121 ein, einen klassischen Stack-based Buffer Overflow – ein Fehlerbild, das in der Softwarebranche seit Jahrzehnten bekannt ist und trotzdem regelmäßig wieder auftaucht, sobald Eingabeprüfungen an einer unerwarteten Stelle fehlen.

Das Update selbst ist die unspektakulärste und zugleich wirksamste Gegenmaßnahme: Es schließt den fehlerhaften Prüfpfad direkt an der Quelle, statt drumherum zu flicken. Wer produktive Simulationsumgebungen betreibt, sollte das Rollout dennoch planen statt hastig durchzudrücken – Lizenzserver, Batch-Jobs und Zulieferer-Schnittstellen reagieren erfahrungsgemäß empfindlich auf übereilte Versionssprünge mitten im Projektzyklus.

Wer aus organisatorischen Gründen nicht sofort auf V2606 wechseln kann, sollte den Kreis der Personen und Skripte, die externe Modelldateien öffnen dürfen, so klein wie möglich halten und diese Schritte dokumentieren. Ein befristeter Kompensationsplan ist besser als ein unbefristetes Aufschieben, denn Advisories dieser Art verschwinden nicht von selbst, nur weil das Update gerade unbequem in den Sprint passt.

Ein Blick in die Versionshistorie des Advisorys lohnt sich zudem: Die ursprüngliche Veröffentlichung deckte zunächst nur Simcenter Nastran ab, eine spätere Überarbeitung ergänzte Simcenter Femap mit demselben Fix. Wer nach der ersten Meldung nur eines der beiden Produkte aktualisiert hat, sollte die eigene Inventarliste sicherheitshalber noch einmal gegen die aktuelle Fassung des Advisorys abgleichen.

Netzwerksegmentierung als zusätzliche Rückversicherung

CISA ergänzt im Advisory die üblichen, aber deshalb nicht weniger wichtigen Grundregeln: Steuerungs- und Simulationsnetze von Bürolandschaften trennen, Fernzugriffe ausschließlich über gehärtete VPN-Verbindungen führen und keine Systeme ungeschützt ans offene Internet hängen. Für Simulationsumgebungen kommt eine zusätzliche Regel hinzu, die selten in Checklisten steht: Eingehende Modelldateien aus externen Quellen sollten vor dem Öffnen in isolierten Umgebungen geprüft werden, statt direkt auf dem produktiven Arbeitsplatz zu landen.

Ähnliche Lehren lassen sich aus Vorfällen bei anderer Fernzugriffs- und Verwaltungssoftware ziehen. Nach dem Hotfix für eine aktiv ausgenutzte Login-Lücke in N-central zeigte sich, dass Zugriffskontrollen und schnelles Patchen zusammen wirken müssen, weil einzelne Maßnahmen allein selten ausreichen. Für Simcenter-Betreiber gilt dasselbe Prinzip: Patch, Segmentierung und Dateiprüfung ergänzen sich, sie ersetzen sich nicht.

Ein oft unterschätzter Baustein ist die Protokollierung von Abstürzen. Wenn ein Simulationsjob regelmäßig ohne erkennbaren Grund abbricht, lohnt sich ein Blick in die Crash-Dumps, bevor man den Vorfall achselzuckend dem üblichen Softwarerauschen zuschreibt. Wer diese Signale ignoriert, verschenkt oft den einzigen frühzeitigen Hinweis, den ein missglückter Angriffsversuch hinterlässt.

Auch eine einfache Dateiherkunfts-Kennzeichnung hilft: Wird jede eingehende Modelldatei mit Quelle und Übertragungsweg markiert, lässt sich im Nachhinein nachvollziehen, welcher Kanal ein kompromittiertes Dokument eingeschleust hat. Diese kleine organisatorische Maßnahme kostet wenig, liefert im Ernstfall aber genau die Spur, die eine technische Analyse sonst mühsam rekonstruieren müsste.

Ein Wiederanlaufplan für Simulationsumgebungen

Bevor Sie das Update ausrollen, lohnt sich ein kurzer Realitätscheck: Welche Arbeitsplätze öffnen regelmäßig Modelldateien aus externen Quellen, welche Lizenzserver hängen an welcher Version, und wer bemerkt es zuerst, wenn eine Berechnung plötzlich abstürzt statt zu konvergieren? Diese drei Fragen entscheiden, ob das Update ein ruhiger Wartungspunkt wird oder ein hektischer Freitagnachmittag.

Ein pragmatischer Wiederanlaufplan beginnt mit der Inventur aller Simcenter-Nastran- und Femap-Installationen, gefolgt vom Rollout auf V2606 zuerst auf weniger kritischen Arbeitsplätzen. Erst danach folgen die Systeme, an denen Projektfristen hängen. Wer zusätzlich eine Dateiprüfung vor dem produktiven Öffnen einführt, riskiert im Ernstfall einen abgelehnten Anhang statt eines kompromittierten Rechners – ein Tausch, den man im Nachhinein selten bereut. Der CISA-Eintrag zur Schwachstelle bleibt dabei die verlässlichste Referenz für Versionsstände und Fixdatum.

Zum Abschluss des Rollouts gehört ein kurzer Funktionstest mit bekannten, unkritischen Modelldateien, bevor produktive Projekte wieder anlaufen. Das kostet eine halbe Stunde und erspart im Zweifel einen zweiten Vorfall, weil ein Plugin oder ein Lizenzmodul nach dem Update nicht mehr wie erwartet mitspielt. Wer diesen Schritt überspringt, tauscht ein bekanntes Sicherheitsrisiko gegen ein unbekanntes Betriebsrisiko – kein Fortschritt, nur ein anderer Ärger.

Wer den Vorfall meldepflichtig einordnen muss, sollte die Meldekette schon vor dem Rollout klären, statt sie im Ernstfall erst zu improvisieren. Ein dokumentierter Ablauf, wer bei einem verdächtigen Absturz informiert wird und wer die Entscheidung über eine Betriebsunterbrechung trifft, macht aus einem hektischen Vorfall einen kontrollierten Prozess, in dem am Ende niemand improvisieren muss, während die Projektuhr weiterläuft.