BR-2026-004
Aktive Kampagne
Aktiv beobachtet

PTC Windchill & FlexPLM: Cl0p nutzt kritische RCE-Lücke aktiv aus

Cl0p-Affiliates nutzen CVE-2026-12569 in PTC Windchill und FlexPLM für unauthentifizierte Codeausführung, legen JSP-Webshells ab und exfiltrieren Konstruktionsdaten.

Stufe
Kritisch
CVE
CVE-2026-12569, CVE-2026-4681
CVSS
9.8 (CVE-2026-12569) / 10.0 (CVE-2026-4681)
Aktiv ausgenutzt
Ja
Nicht bestätigt
Patch verfügbar
Ja
Nein
Stand
August 1, 2026
KurzfassungBin ich betroffen?Was ist passiertByteRay-EinordnungSofortmaßnahmenErkennung & IOCsWas wir gemacht habenWie wir unterstützenHäufige FragenUpdate-LogQuellen

Akut betroffen?

Unsere DFIR-Bereitschaft ist rund um die Uhr erreichbar — auch ohne bestehenden Vertrag.

+49 89 2000 7683

Kurzfassung

  • CVE-2026-12569 erlaubt unauthentifizierte Codeausführung auf PTC Windchill PDMLink und FlexPLM. CVSS 9.8, seit 25.06.2026 im CISA-KEV-Katalog.
  • Cl0p-Affiliates nutzen die Lücke seit Anfang Juni 2026 aktiv aus, legen JSP-Webshells ab und exfiltrieren Konstruktions- und Produktdaten für doppelte Erpressung.
  • Betroffen sind Windchill- und FlexPLM-Stände vor 11.0 M030. Patches liegen seit dem 17.06.2026 vor.
  • Wer aus dem Internet erreichbare PLM-Systeme betreibt, muss nicht nur patchen, sondern aktiv nach Webshells suchen. Der Patch entfernt keine bereits abgelegte Persistenz.

Bin ich betroffen?

Betroffen sind PTC Windchill PDMLink und PTC FlexPLM in allen Ständen vor Release 11.0 M030. Windchill wird typischerweise in Fertigung, Automotive und Luftfahrt eingesetzt, FlexPLM im Handel sowie in der Bekleidungs- und Konsumgüterindustrie.

Drei Fragen zur Einordnung

  1. Ist die Instanz aus dem Internet erreichbar? Dann gilt akuter Handlungsbedarf, unabhängig vom Patchstand. Die beobachtete Ausnutzung zielt ausschließlich auf exponierte Systeme.
  2. Liegt der Patch vom 17.06.2026 oder später ein? Falls nein: das System ist verwundbar.
  3. Wird die Instanz von PTC gehostet? Dann hat PTC die Absicherung übernommen und meldet sich bei zusätzlichem Handlungsbedarf direkt.

Verfügbare Patches

PTC stellt Patches für folgende Stände bereit (Stand: eSupport-Artikel CS473270):

  • SUPs: 13.1.3, 13.1.2
  • CPSXB Stand-Alone-Patches: 13.1.1, 13.0.2, 12.1.2, 12.0.2, 11.2.1, 11.1 M020, 11.0 M030

Selbstcheck auf Kompromittierung

Wichtiger als der Versionsstand ist die Frage, ob bereits eine Webshell liegt. Die beobachtete Kampagne legt JSP-Dateien mit hexadezimalen Namen unterhalb von /Windchill/login/ ab:

# Verdächtige JSP-Dateien im Login-Verzeichnis
find /opt/ptc -path "*/Windchill/login/*" -name "*.jsp" -newermt "2026-06-01" -ls

# Artefakt der Dateisystem-Enumeration
find / -name "flst.txt" -type f 2>/dev/null

Aus der Kampagne im März 2026 (CVE-2026-4681) stammen zusätzlich diese Dateinamen: GW.class, Gen.class sowie JSP-Dateien im Muster dpr_<8 Hex-Zeichen>.jsp.

Was ist passiert

Die aktuelle Kampagne kettet zwei Schwachstellen aneinander. Zuerst greift eine Informationspreisgabe im WSDL-Endpunkt von FlexPLM vor der Authentifizierung (CVSS 7.5). Die daraus gewonnenen Informationen nutzen die Angreifer gegen das Login-Servlet von Windchill. Dort führt eine unsichere Deserialisierung nicht vertrauenswürdiger Daten zu Codeausführung ohne jede Anmeldung (CVE-2026-12569, CVSS 9.8).

Danach folgt ein Muster, das Cl0p seit MOVEit, Cleo und Oracle EBS unverändert führt: JSP-Webshells mit hexadezimalen Namen unter /Windchill/login/, anschließend Enumeration des Dateisystems mit Ablage einer Ergebnisliste als flst.txt, dann Exfiltration. Erpresst wird doppelt. Parallel gehen Massenmails an hunderte Mitarbeitende der betroffenen Organisation, Betreff sinngemäß ein gemeldetes Datenleck im PDMLink-Modul, versendet über kompromittierte Fremdkonten.

Der Zielwert ist hier nicht die Verfügbarkeit, sondern das geistige Eigentum. PLM-Systeme halten Konstruktionsdaten, Stücklisten, Lieferantenkonditionen und Produktentwicklungsstände. Genau das lässt sich am wirksamsten für Erpressung nutzen.

Zeitlinie

  • März 2026 CVE-2026-4681 wird bekannt: unsichere Deserialisierung in Windchill und FlexPLM, CVSS 10.0. Erste IOCs kursieren, Ausnutzung wird vermutet.
  • Anfang Juni 2026 Cl0p-Affiliates nutzen CVE-2026-12569 mutmaßlich als Zero-Day.
  • 17.06.2026 PTC veröffentlicht Patches.
  • 18.06.2026 PTC gibt Indicators of Compromise heraus.
  • 25.06.2026 CISA nimmt CVE-2026-12569 in den KEV-Katalog auf, Frist für US-Bundesbehörden: 28.06.2026.
  • Ende Juli 2026 Ransom-ISAC ordnet die Kampagne öffentlich Cl0p zu und veröffentlicht weitere C2-Indikatoren.

ByteRay-Einordnung

Das eigentliche Problem ist nicht der Patch, sondern der Zeitraum davor. Cl0p war nach heutigem Kenntnisstand vier bis sechs Wochen unterwegs, bevor PTC den Patch veröffentlicht hat. Wer sein System jetzt aktualisiert und danach abhakt, hat die Lücke geschlossen und die Webshell behalten. Bei dieser Gruppe ist das kein theoretisches Restrisiko, sondern das dokumentierte Vorgehen. Patchen ohne anschließende Kompromittierungsprüfung ist bei diesem Fall die falsche Reihenfolge.

PLM wird als Nebenschauplatz behandelt und ist keiner. In den Umgebungen, die wir sehen, läuft Windchill häufig außerhalb der normalen Patch- und Monitoring-Routine. Betreut von der Konstruktion oder einem externen Dienstleister, technisch alt, mit einer Lieferantenanbindung nach außen, weil es anders nicht funktioniert. Genau diese Kombination sucht Cl0p seit Jahren. MOVEit war Filetransfer, Cleo war Filetransfer, Oracle EBS war ERP. Das Muster ist immer dasselbe: geschäftskritisch, exponiert, außerhalb der Sicherheitszuständigkeit.

Zur Erpressungsmail. Der Massenversand an hunderte Mitarbeitende ist kein Beweis für eine Kompromittierung. Cl0p verschickt breit, auch an Organisationen, bei denen die Exfiltration nicht gelungen ist. Wer eine solche Mail erhält, sollte deshalb weder in Panik verfallen noch sie ignorieren, sondern die Systeme forensisch prüfen. Die Mail ist ein Anlass, kein Befund.

Zur deutschen Lage. Der deutsche Mittelstand im Maschinen- und Anlagenbau ist hier überdurchschnittlich betroffen, weil Windchill in genau diesen Branchen stark verbreitet ist. Anders als bei MOVEit gibt es hier zudem keinen schnellen Ersatz. Das System lässt sich nicht kurzfristig abschalten, ohne die Entwicklung anzuhalten.

Sofortmaßnahmen

Jetzt

  • Erreichbarkeit aus dem Internet prüfen und, wenn irgend möglich, sofort beenden. Zugriff nur über VPN oder aus definierten Netzen.
  • Patchstand prüfen und den passenden PTC-Patch einspielen (eSupport-Artikel CS473270).
  • Vor dem Patchen forensische Sicherung anlegen, wenn das System exponiert war. Ein Patch überschreibt Spuren, die später gebraucht werden.
  • Dateisystem auf JSP-Webshells unter /Windchill/login/ durchsuchen sowie auf flst.txt, GW.class, Gen.class und dpr_*.jsp.

In den nächsten 24 Stunden

  • Webserver-Logs auf Zugriffe auf das Login-Servlet und den FlexPLM-WSDL-Endpunkt durchsehen, insbesondere ab Anfang Juni 2026.
  • Ausgehende Verbindungen des PLM-Servers prüfen. Große Datenmengen an unbekannte Ziele sind das Exfiltrationssignal.
  • Dienstkonten und Integrationszugänge des PLM-Systems rotieren, insbesondere Anbindungen an ERP, CAD-Ablagen und Lieferantenportale.

In den nächsten 72 Stunden

  • Bei bestätigten Artefakten Incident Response auslösen und die Meldepflicht nach Art. 33 DSGVO sowie gegebenenfalls NIS2 bewerten.
  • Netzsegmentierung des PLM-Systems prüfen. Ein kompromittierter Windchill-Server darf kein Sprungbrett in die Konstruktions- und Fertigungsnetze sein.
  • Kommunikationslinie vorbereiten. Wenn die Erpressungsmails intern breit ankommen, braucht es innerhalb von Stunden eine abgestimmte Antwort.

Erkennung & IOCs

Unsere Erkennung setzt an drei Stellen an: Ablage der Webshell, Ausführung durch den Applikationsserver und Nachlauf der Enumeration.

1. Webshell-Ablage im Login-Verzeichnis

Die aussagekräftigste Suche. Legitime Prozesse schreiben dort keine neuen JSP-Dateien:

#event_simpleName = /.*FileWritten/i
| FileName = /\.jsp$/i
| FilePath = /Windchill\/login/i
| groupBy([ComputerName, FilePath, FileName, TargetProcessId], limit=max)

2. Bekannte Artefakte aus der März-Kampagne

#event_simpleName = /.*FileWritten/i
| FileName = /GW\.class/i or FileName = /Gen\.class/i or FileName = /dpr_.*\.jsp/i

Ergänzend die Dateinamen aus dem IOC-Dokument:

#event_simpleName = /.*FileWritten/i
| in(field="FileName", values=["Gen.java","GW.java","HTTPRequest.java","HTTPResponse.java","IXBCommonStreamer.java","IXBStreamer.java","MethodFeedback.java","MethodResult.java","WTContextUpdate.java"])

3. Enumerationsartefakt

#event_simpleName = /.*FileWritten/i
| FileName = /^flst\.txt$/i

4. Kindprozesse des Applikationsservers

Eine ausgeführte Webshell zeigt sich daran, dass der Java-Prozess des PLM-Systems eine Shell startet. Das ist im Normalbetrieb praktisch ausgeschlossen:

#event_simpleName = ProcessRollup2
| ParentBaseFileName = /^java(\.exe)?$/i
| FileName = /^(cmd\.exe|powershell\.exe|sh|bash|whoami|net\.exe)$/i
| groupBy([ComputerName, ParentBaseFileName, FileName, CommandLine], limit=max)

5. Hashes ins IOC-Management übernehmen

Die neun bekannten SHA256-Hashes aus dem IOC-Dokument gehören dauerhaft in das IOC-Management, damit aus der einmaligen Suche eine bleibende Schutzmaßnahme wird. In der Falcon-Konsole unter Endpoint Security > IOC Management > Add Hashes, Plattform Windows und Linux:

F2C8EB4A4F4BB2344DC0E41C2717B7B0D22F923A1CDBBE61EBF415759F757DAD,330433BC430CB40E7BC4D17BEBABD521572AD5077F614484FEE9442EEE793477,1CB7A011880958A1A8797D720495646BA8B0601AF09352E4118FCB0E09475E95,E697AFEAF83ED975D5B5D2A6604F08E7496D99F9775F33407B0B02530516D88D,AFEDA8E680639FE58343AE7A67B92C36E44A67A6BB7DC3C1FC239DF29CF225E0,AD388F887F2EB0114AA672EC0D9EE9201916F257EB982C96EC4867727C52082C,305241D4D27B07CFDD566AA16B22CF79116EE9BC254D6D8A8032443ABA2EC985,69E41E4B68A1097143C394DE25B2E1D33A819AED0C61F3DF891485A98B5AAA07,78473ABBECDFF2BDC30BCB96B0B3EAC3BD6493E6960D11D03277509EFDA188F2

Action und Severity nach eigenem Ermessen. Wo ein Block zu riskant erscheint, ist Detect Only die Alternative.

Was wir bereits gemacht haben

Die Detections weiter oben sind nicht abgeschrieben. Wir haben sie gebaut, in echten Umgebungen getestet und stellen sie hier offen zur Verfügung.

  • Vier Erkennungslogiken entwickelt: Ablage der Webshell, bekannte Artefakte aus der März-Kampagne, Enumerationsdatei und Kindprozesse des Applikationsservers.
  • Die neun bekannten Hashes für die direkte Übernahme ins IOC-Management aufbereitet.
  • Rückwirkende Suche über den Datenbestand ab Anfang Juni 2026 in den von uns betreuten Umgebungen durchgeführt und die Logik anhand der Ergebnisse nachgeschärft.

Wer Falcon selbst betreibt, kann das direkt übernehmen. Wer dabei Unterstützung braucht oder einen Verdacht forensisch geklärt haben will, erreicht uns rund um die Uhr.

Wie wir unterstützen

Compromise Assessment PLM

Gezielte Prüfung Ihrer Windchill- oder FlexPLM-Umgebung auf Webshells, Persistenz und Hinweise auf Exfiltration. Ergebnis ist ein Bericht mit klarer Aussage zur Betroffenheit und konkreten Handlungsempfehlungen. Wie lange das dauert, hängt an Umgebungsgröße und Befundlage. Den Rahmen legen wir im Kick-off verbindlich fest.

24/7 DFIR-Hotline

Bei konkretem Verdacht, gefundenen Artefakten oder eingegangener Erpressungsmail: +49 89 2000 7683. Rund um die Uhr, auch ohne bestehenden Vertrag.

Detection-Regelwerk für Ihr eigenes SIEM

Sie betreiben Falcon NG-SIEM selbst? Die Queries oben können Sie frei übernehmen. Wenn Sie sie als gepflegtes Regelwerk in Ihre bestehende Struktur eingebunden haben wollen, inklusive Tuning gegen Fehlalarme, machen wir das.

Häufige Fragen

Wir haben gepatcht. Sind wir damit sicher?

Der Patch verhindert eine erneute Ausnutzung. Er entfernt keine Webshell, die vorher abgelegt wurde. War Ihr System vor dem 17.06.2026 aus dem Internet erreichbar, gehört eine Kompromittierungsprüfung dazu.

Wir haben eine Erpressungsmail von Cl0p erhalten. Sind wir betroffen?

Nicht zwingend. Cl0p verschickt diese Mails breit, auch an Organisationen ohne erfolgreiche Exfiltration. Die Mail ist ein Anlass zur Prüfung, kein Nachweis. Antworten Sie nicht und prüfen Sie zuerst die Systeme.

Betrifft das auch von PTC gehostete Instanzen?

PTC hat für selbst gehostete Kundeninstanzen Maßnahmen ergriffen und kontaktiert Betroffene bei zusätzlichem Handlungsbedarf direkt. Für eigenbetriebene Installationen liegt die Verantwortung vollständig bei Ihnen.

Was ist der Unterschied zwischen CVE-2026-4681 und CVE-2026-12569?

Beides sind Deserialisierungslücken in denselben Produkten, aber unterschiedliche Schwachstellen. CVE-2026-4681 wurde im März 2026 bekannt. CVE-2026-12569 wurde ab Anfang Juni 2026 von Cl0p als Zero-Day genutzt und im Juni gepatcht. Ein Patch für die eine Lücke schützt nicht vor der anderen.

Können wir Windchill übergangsweise absichern, ohne zu patchen?

Der wirksamste Sofortschritt ist, die Erreichbarkeit aus dem Internet zu beenden. Zusätzlich lässt sich der betroffene Publish-Servlet-Pfad auf Ebene des Webservers sperren. Beides ersetzt den Patch nicht, kauft aber Zeit.

Wie lange dauert eine Kompromittierungsprüfung?

Das hängt vom Fall ab: Größe der Umgebung, Anzahl betroffener Systeme, verfügbare Datenlage und vor allem die Befundlage. Die Datenerhebung selbst ist schnell, die Auswertung bestimmt die Dauer. Einen verbindlichen Rahmen nennen wir im Kick-off, sobald der Umfang klar ist.

Update-Log

  • 01.08.2026, 11:00 Uhr Zuordnung der Kampagne zu Cl0p ergänzt, Abschnitt zu den Erpressungsmails aufgenommen, Detection um Webshell- und Kindprozess-Logik erweitert.
  • 26.06.2026, 08:30 Uhr CVE-2026-12569 aufgenommen: KEV-Eintrag, PTC-Patches vom 17.06.2026, Webshell-Indikatoren.
  • 22.03.2026, 09:00 Uhr Erstveröffentlichung zu CVE-2026-4681 mit IOC-basierten Detections für CrowdStrike Falcon.

Quellen

  • PTC Trust Center, Customer & Partner Update zur RCE-Schwachstelle in Windchill und FlexPLM
  • PTC eSupport-Artikel CS473270 (betroffene Versionen und Patches)
  • CISA Known Exploited Vulnerabilities Catalog, CVE-2026-12569 (25.06.2026)
  • Ransom-ISAC, Analyse der Cl0p-Ausnutzung von PTC Windchill und FlexPLM
  • EAC, IOC-Dokument zur März-Kampagne (CVE-2026-4681)
z
z
z
z
i
i
z
z
Wir durchleuchten digitale
Risiken.
Sprechen Sie direkt mit einem Security-Engineer: unverbindlich, technisch, konkret.