Eine kritische Schwachstelle, die zeigt, wie ein längst abgekündigtes Bauteil zum Einfallstor für die komplette SAP-Landschaft wird. Hier die Einordnung aus Sicht der Verteidigung: was passiert ist, woran man einen Treffer erkennt und was wirklich hilft.

Kurzfassung

CVSS 10.0, unauthentifizierter Dateiupload im Metadata Uploader des SAP NetWeaver Visual Composer. Führt über eine hochgeladene JSP-Webshell zu Remote Code Execution. Seit Ende März 2025 als Zero-Day aktiv ausgenutzt, von SAP am 24.04.2025 mit einem Out-of-Band-Patch adressiert. Betroffen sind NetWeaver-AS-Java-Systeme (7.x) mit aktiviertem Visual Composer.

Wer ein internetexponiertes NetWeaver-Java-System mit Visual Composer betreibt, sollte diesen Artikel als Auftrag verstehen, nicht als Lektüre.

Worum es geht

Der Visual Composer ist ein modellgetriebenes Entwicklungswerkzeug auf dem SAP NetWeaver Application Server Java. Das verwundbare Bauteil ist der Metadata Uploader, erreichbar über den Endpunkt:

/developmentserver/metadatauploader

Diesem Endpunkt fehlte eine Berechtigungsprüfung. Ein nicht angemeldeter Angreifer konnte also per HTTP-POST eine Datei hochladen, ohne sich jemals authentifizieren zu müssen. Genau das ist der Kern der Schwachstelle: keine Authentifizierung, keine Validierung, beliebige Datei auf dem Server.

Bin ich betroffen?

Visual Composer ist nicht in jeder Standardinstallation aktiv, aber in der Praxis sehr verbreitet, weil er über Jahre mit ausgeliefert wurde. Prüfen lässt sich das so:

Besonders kritisch wird es bei internetexponierten Systemen. Genau die wurden in den beobachteten Angriffswellen zuerst getroffen, mit deutlichem Fokus auf Fertigungsunternehmen.

Die Schwachstelle technisch

Es lohnt sich, zwei Ebenen zu unterscheiden, weil das auch die Patch-Strategie erklärt:

  1. Fehlende Autorisierung (CVE-2025-31324). Der Upload-Endpunkt prüfte nicht, ob der Aufrufer überhaupt berechtigt ist. Das ist der unmittelbare Hebel.
  2. Unsichere Deserialisierung (CVE-2025-42999). Unter der fehlenden Prüfung lag eine Java-Deserialisierungsschwachstelle. Selbst nach Erzwingen der Authentifizierung blieb die eigentliche Wurzel offen, bis SAP die Verarbeitung der Dateien grundlegend umgebaut hat.

Wichtig für die Praxis: Der erste Notfall-Patch schließt die Tür (Authentifizierung), aber erst der nachgelagerte Patch entfernt das morsche Schloss (Deserialisierung). Beides gehört zusammen.

Angriffsablauf

Der typische Ablauf, wie ihn mehrere Incident-Response-Teams unabhängig beobachtet haben:

  1. Upload. Unauthentifizierter POST an den Metadata-Uploader-Endpunkt legt eine JSP-Webshell in ein web-erreichbares Verzeichnis, meist unterhalb von servlet_jsp/irj/root/.
  2. Trigger. Ein einfacher GET-Aufruf der hochgeladenen JSP führt Betriebssystembefehle aus, und zwar mit den Rechten des SAP-Serverprozesses.
  3. Post-Exploitation. Ab hier ist es eine normale Kompromittierung: Erkundung, Persistenz, laterale Bewegung. Beobachtet wurden unter anderem Reverse Shells, Kryptominer und in mehreren Fällen Ransomware-nahe Aktivität.

Der entscheidende Punkt: Ein einziger HTTP-Request ohne Login reicht für den initialen Zugriff. Es gibt keine Hürde, die ein Angreifer erst überwinden müsste.

Indicators of Compromise

Worauf man bei der Suche nach einem Treffer achtet:

Vollständige IOC-Listen pflegen unter anderem Onapsis, Rapid7 und Red Canary. Die obigen Punkte sind der schnelle Erstcheck, keine abschließende Liste.

Erkennung mit ETD und Monitoring

Hier wird es für uns interessant, denn die meisten Indikatoren lassen sich in bestehende Überwachung gießen, statt sie nur einmalig zu suchen. Drei Ansatzpunkte:

Der Charme dieser drei Muster: Sie sind verhaltensbasiert. Sie erkennen nicht nur diesen einen CVE, sondern die generische Kette „SAP-Prozess schreibt Webshell, Webshell startet Kommandos". Genau so sollte ein ETD-Pattern geschnitten sein.

Gegenmaßnahmen

In der Reihenfolge der Dringlichkeit:

  1. Notfall-Patch einspielen. SAP Security Note 3594142 erzwingt die Authentifizierung am betroffenen Endpunkt. Das ist die Sofortmaßnahme, ohne auf den nächsten regulären Patch-Zyklus zu warten.
  2. Wurzel schließen. SAP Security Note 3604119 (ergänzend 3660659 samt JVM-Serial-Filter) entfernt die zugrunde liegende Deserialisierungsschwachstelle. Ohne diesen Schritt bleibt die eigentliche Ursache bestehen.
  3. Wenn sofortiges Patchen nicht geht: Visual Composer deaktivieren und den Endpunkt am Reverse Proxy oder WAF sperren. Das ist eine Brücke, kein Ersatz für den Patch.
  4. NetWeaver nicht ins offene Internet stellen. Wenn überhaupt nötig, dann nur hinter VPN, gesichertem Reverse Proxy oder WAF.
  5. Forensik nicht vergessen. Das ist der Punkt, den viele übersehen: Ein Patch schließt die Lücke, beseitigt aber keine bereits vorhandene Kompromittierung. Wer verwundbar war, muss aktiv nach Spuren suchen, nicht nur patchen.

Einordnung

CVE-2025-31324 ist ein Lehrstück über Angriffsfläche, die man vergessen hat. Der Visual Composer galt als abgekündigt, lief aber in unzähligen Systemen weiter mit, oft ohne dass jemand ihn aktiv nutzte. Genau dieses „läuft halt noch mit" ist das Risiko.

Die Lehren sind unbequem, aber simpel:

Quellen