Von ShinyHunters ausgenutzte Oracle-PeopleSoft-Schwachstelle entpuppt sich als Kette aus drei separaten Fehlern

Die kritische Schwachstelle CVE-2026-35273 in Oracle PeopleSoft Enterprise PeopleTools der Versionen 8.61 und 8.62, die von der Gruppierung ShinyHunters seit Mai 2026 als zero-day ausgenutzt wurde, stellt in Wirklichkeit nicht eine, sondern drei separate Schwachstellen dar, die zu einer Kette kombiniert werden. Darüber hat in der vergangenen Woche das Team der Zero Day Initiative (ZDI) berichtet, das die Schwachstelle ursprünglich entdeckt und die Informationen an Oracle weitergegeben hat. Die Schwachstelle hat einen CVSS-Score von 9.8, ermöglicht einem nicht authentifizierten Angreifer Remote Code Execution und ist in den CISA-Katalog Known Exploited Vulnerabilities aufgenommen worden. Organisationen, die PeopleSoft einsetzen, müssen den am 10. Juni 2026 veröffentlichten Oracle-Patch umgehend installieren und auf Anzeichen einer Kompromittierung prüfen – die Installation des Patches beseitigt keinen zuvor durch den Angreifer erlangten Zugriff. Wir haben bereits über diese Schwachstelle berichtet – im Zusammenhang mit den Aussagen von ShinyHunters.

Anatomie der Kette: von SSRF bis zur Codeausführung

Oracle hat alle drei Fehler unter der einheitlichen Kennung CVE-2026-35273 geschlossen, doch laut ZDI handelt es sich um drei verschiedene Schwachstellen in zwei Komponenten von PeopleSoft. ZDI stimmt sich mit Oracle über die Vergabe separater CVEs für jeden Fehler ab, aber zum Zeitpunkt der Veröffentlichung ist die eine Kennung die einzige im Register. Das ist ein wichtiger Punkt: Ein einziges CVE und ein einzelner Patch bedeuten nicht, dass es nur einen Fehler gibt, und Organisationen sollten dies bei der Bewertung ihrer Angriffsoberfläche berücksichtigen.

Betroffen sind zwei Komponenten, die als eigenständige Webanwendungen arbeiten:

• Integration Gateway (PSIGW) – ein Gateway für den Nachrichtenaustausch mit externen Systemen;
• Environment Management Hub (PSEMHUB) – eine interne Administrationsoberfläche, die nur von vertrauenswürdigen Hosts aus zugänglich sein soll.

Laut ZDI sieht die Exploit-Kette folgendermaßen aus:

1. SSRF in PSIGW. Der Angreifer sendet eine Anfrage an den Handler für eingehende Verbindungen des Integration Gateway und kontrolliert sowohl die Zieladresse als auch den vollständigen Inhalt der weitergeleiteten Anfrage. Der Handler überprüft nicht, ob die Zieladresse ein legitimes Ziel ist.
2. Umgehung der Vertrauensprüfung über Loopback. PSEMHUB definiert vertrauenswürdige Clients über eine Liste in der Datei allowedhosts.properties. Standardmäßig enthält diese Datei die Adresse 127.0.0.1. Der Angreifer leitet die SSRF-Anfrage an die Loopback-Adresse – die Anfrage trifft bei PSEMHUB so ein, als ob sie vom Server selbst käme, und die Vertrauensprüfung wird erfolgreich durchlaufen. Die interne Oberfläche, die Oracle als isoliert vorgesehen hatte, wird so von außen zugänglich.
3. Codeausführung. ZDI beschreibt zwei Wege, den Zugriff auf PSEMHUB in die Ausführung beliebigen Codes zu verwandeln. Der erste erfolgt über den Log-Schreibbefehl, bei dem der Angreifer sowohl den Inhalt der Datei als auch den Pfad auf dem Datenträger kontrolliert, was es ermöglicht, ein Web-Shell in das Anwendungsverzeichnis zu schreiben. Der zweite Weg erfolgt über das Schreiben einer schädlichen XML-Datei, die PSEMHUB beim nächsten Start des Dienstes über Java XMLDecoder verarbeitet und dabei den Code des Angreifers ausführt, ohne ein Web-Shell abzulegen.

Der zweite Weg zur Codeausführung – über XMLDecoder – ist insbesondere aus Erkennungssicht gefährlich: Er hinterlässt keine JSP-Dateien, auf die sich Erkennungsregeln üblicherweise konzentrieren. Organisationen, deren Monitoring sich auf die Suche nach JSP-Shells beschränkt, laufen Gefahr, eine Kompromittierung zu übersehen. Für eine vollständige Erkennung ist es notwendig, die Analyse von Zugriffslogs mit einem Monitoring der von dem Java-Prozess WebLogic erzeugten Prozesse zu kombinieren.

Kampagne von ShinyHunters: von Universitäten bis zu Behörden

Nach Angaben von Mandiant und der Google Threat Intelligence Group wurde die aktive Ausnutzung von CVE-2026-35273 vom 27. Mai bis 9. Juni 2026 beobachtet – also vor der Veröffentlichung des Oracle-Patches am 10. Juni, was die Kampagne als zero-day einstuft. Die Kampagne wird der Gruppierung UNC6240 zugeschrieben, die auch als ShinyHunters bekannt ist. Ursprünglich richteten sich die Angriffe überwiegend gegen den Hochschulsektor: Nach Einschätzung von Mandiant gehörten 68 % von mehr als 100 benachrichtigten Organisationen zu Universitäten.

Im September 2026 hat Mandiant eine erneute Welle massenhafter Ausnutzung registriert, die sich auf die Sektoren Technologie, IT-Dienstleistungen, Gesundheitswesen, Landwirtschaft, Transport und öffentliche Verwaltung ausweitete. Web-Shells wurden auf Dutzenden von Systemen weltweit entdeckt.

Bemerkenswert ist die von ShinyHunters in der zweiten Welle eingesetzte Technik zur Umgehung von WAFs: Anstatt den Pfad /PSEMHUB/ direkt aufzurufen, verwendeten die Angreifer eine URL-Codierung eines einzelnen Zeichens – /%50SEMHUB/. Die meisten WAF-Regeln führen das Matching anhand des offenen Textpfads durch, während der PeopleSoft-Server den Pfad vor der Verarbeitung dekodiert. Mandiant verweist außerdem auf ein charakteristisches Aufklärungsmuster: 5 bis 15 POST-Anfragen an den kodierten Pfad vor Beginn der Ausnutzung, was als Indikator in Logs dienen kann.

Indikatoren einer Kompromittierung

Auf Basis der Untersuchungsdaten stehen folgende IOC zur Verfügung:

• Dateihashes:48b4a0827da7bbfce9fb52464f8a659dea7a035189c52c506c0bfb4b1c3fe494, 2bee941fb40519d0d1ec52bd79a8f63fc65aac6455c8f2d6b668e3360dfdb5d7
• IP-Adressen: 142.11.200.186–190, 5.199.162.157, 104.219.234.138, 162.219.30.165
• Domains: azurenetfiles.net, winmanage-me.network
• C2-URL:wss://azurenetfiles.net:443/agent.ashx (MeshCentral)

Empfehlungen

• Installieren Sie den Patch. Wenden Sie das Oracle-Update für CVE-2026-35273 an und stellen Sie sicher, dass eine unterstützte Version von PeopleTools verwendet wird. Mandiant weist ausdrücklich darauf hin, dass das Blockieren von Pfaden über einen WAF kein Ersatz für den Patch ist – die URL-Codierungstechnik hat dies deutlich gezeigt.
• Wenn ein Patch derzeit nicht möglich ist – deaktivieren Sie den Dienst Environment Management Hub in Mehrserverkonfigurationen oder entfernen Sie die Anwendung PSEMHUB in Einzelserverkonfigurationen, wie es Oracle empfiehlt. Dies beeinträchtigt die Arbeit von Benutzersitzungen nicht.
• Führen Sie eine Prüfung auf Kompromittierung durch. Suchen Sie nicht nur nach JSP-Dateien von Web-Shells, sondern auch nach verdächtigen XML-Dateien in den PSEMHUB-Verzeichnissen sowie nach untypischen Kindprozessen des Java-Prozesses WebLogic. Überprüfen Sie die Logs auf POST-Anfragen zu Pfaden mit URL-Codierung (/%50SEMHUB/).
• Wenn Sie eine Kompromittierung feststellen – betrachten Sie den Host als vollständig kompromittiert, sichern Sie die Beweise und rotieren Sie sämtliche Zugangsdaten, die von der PeopleSoft-Ebene aus erreichbar sind. ShinyHunters stiehlt Daten und fordert anschließend ein Lösegeld, daher ist mit Erpressungsversuchen zu rechnen.

Die wichtigste Lehre aus diesem Vorfall ist architektonischer Natur: Die Aufnahme der Loopback-Adresse in die Liste der vertrauenswürdigen Hosts als Standardeinstellung verwandelt jede SSRF-Schwachstelle in eine vollständige Umgehung der Zugriffskontrolle für interne Schnittstellen. Für Organisationen, die PeopleSoft betreiben, reicht es nicht aus, den Patch zu installieren – sie müssen sich vergewissern, dass auf den betroffenen Servern keine Spuren eines bereits erlangten Zugriffs durch Angreifer vorhanden sind, da weder Oracle noch Mandiant bestätigen, dass der Patch zuvor eingerichtete Persistenzmechanismen entfernt.