PeopleSoft 0-Day: ShinyHunters plündert Universitäten

Wer jemals ein HR- oder Studierendeninformationssystem betrieben hat, weiß: PeopleSoft sitzt an der denkbar ungünstigsten Stelle – tief genug im Stack, um jeden sensiblen Datensatz zu verwalten, und alt genug, dass niemand im aktuellen Team die Integration selbst geschrieben hat. Genau dieses System hat ShinyHunters in der zweiten Maihälfte still und leise ausgeplündert. Als Oracle der Schwachstelle endlich einen Namen gab, war die Datenleck-Seite bereits gut gefüllt.

Was geschah

Die Schwachstelle trägt die Bezeichnung CVE-2026-35273 – eine Server-Side Request Forgery in Oracles PeopleSoft-Suite, bewertet mit 9,8 von 10 Punkten. Wie Ars Technica berichtete, nutzte ShinyHunters die Lücke bereits seit dem 27. Mai aus – mehr als zwei Wochen, bevor Oracle das Problem erkannte. Oracle hat eine vorläufige Abhilfemaßnahme veröffentlicht, die Schwachstelle aber noch nicht vollständig gepatcht. Der Fehler ist remote ausnutzbar – das ist die schlimmstmögliche Kombination in einem Sicherheitshinweis am Dienstagmorgen.

Googles Mandiant-Team identifizierte und analysierte die Aktivitäten. Stand Mittwoch hatte die Gruppe rund 300 Endpunkte bei etwa 100 Organisationen angegriffen. Etwa 68 Prozent dieser Opfer sind im Hochschulbereich tätig. Die University of Nottingham bestätigte, dass sie kompromittiert wurde und dass eine „erhebliche" Menge an Studierendendaten in die Hände der Angreifer gelangte. ShinyHunters veröffentlichte anschließend Gigabytes an angeblichen Nottingham-Daten auf ihrer Leak-Seite, um Druck auszuüben.

Mindestens ein Kunde wurde erpresst, damit die gestohlenen Daten nicht veröffentlicht werden, und Google hat bestätigt, dass Opfer Lösegeldforderungen erhalten. Am Dienstag stellte ein Sicherheitsforscher fest, dass die Gruppe Verzeichnisse offengelegt hatte, die auf laufende PeopleSoft-Angriffe hinwiesen, und sogar einen Staging-Server mit ihren Tools öffentlich zugänglich ließ. Auf diese Weise erhielt Mandiant einen so klaren Einblick in die Angriffskette. Die Datenleck-Seite behauptete, 48 GB Daten von einem einzigen Opfer erbeutet zu haben – das ist kein Ein-Tabellen-Export. Das sind Monate von Datensätzen, Anhängen und wahrscheinlich auch Backups.

ShinyHunters ist seit mindestens 2019 aktiv. Frühere Opfer sind Ticketmaster über den Snowflake-Breach, Santander und Salesforce (und über Salesforce auch Google sowie Berichten zufolge viele weitere). Das ist kein neuer Akteur, der sein Handwerk erlernt. Das ist eine ausgereifte Operation mit einem funktionierenden Einnahmemodell.

Technische Analyse

SSRF ist der stille Killer in Enterprise-Web-Stacks. OWASP listet diese Schwachstellenklasse seit Jahren, und der Grund dafür ist genau das, was hier passiert ist. Der Angreifer muss keinen Code auf dem Zielsystem ausführen. Er bringt einen vertrauenswürdigen Server dazu, in seinem Auftrag Anfragen zu stellen – in Systeme, die diesem Server ebenfalls vertrauen. In einer PeopleSoft-Umgebung sitzt dieser vertrauenswürdige Server typischerweise neben dem WebLogic-Application-Tier, dem Prozess-Scheduler, internen Datenbanken und dem Identity Provider, der das SSO zusammenhält.

Das im Staging-Environment hinterlassene Bash-Skript erzählt die ganze Geschichte. Die Angreifer kartierten PeopleSoft-Konfigurationen, inspizierten den Prozess-Scheduler und luden WebLogic-XML-Konfigurationen herunter. Das ist klassische Aufklärung: herausfinden, wo die Daten liegen, wo sich die Service-Accounts authentifizieren und was vom kompromittierten Host aus erreichbar ist. Das erfordert keinen Kernel-Exploit. Es erfordert lediglich einen Server, der beliebige URLs abrufen kann – das ist per Definition SSRF.

Die Exfiltration verlief sauber. Die Daten wurden mit zstd komprimiert – schnell und platzsparend – und dann über eine ausgehende SSH-Verbindung an 176.120.22.24 übertragen, dieselbe IP, die die ShinyHunters-Datenleck-Seite hostet. Kein ausgefeiltes DNS-Tunneling, kein Domain Fronting. Nur SSH-Egress zu einer bekannt schädlichen IP. Das sagt etwas Unangenehmes über die Opfer aus: Ausgehende SSH-Verbindungen zu beliebigen Internethosts waren vom PeopleSoft-Tier aus offenbar erlaubt. In Produktionsumgebungen, die ich gesehen habe, ist dieser Egress-Pfad die häufigste Lücke bei Legacy-App-Servern – weil niemand derjenige sein will, der einen 15 Jahre alten Batch-Job durch eine verschärfte Firewall-Regel kaputt macht.

Meine Einschätzung: Der Schweregrad von 9,8 ist fast eine Ablenkung. Die eigentliche Lehre liegt im operativen Muster. Zwei Wochen Ausnutzung vor der Herstellerbestätigung, ein halber Patch und eine Egress-Konfiguration, die 48 GB via SSH nach draußen lässt. Der CVE ist der Funke. Der Brennstoff war längst aufgeschichtet.

Wer am härtesten trifft

Den Hochschulbereich hat es am schlimmsten erwischt – und das ist kein Zufall. Universitäten betreiben weitläufige PeopleSoft-Umgebungen für Studierenden-, HR- und Finanzdaten, oft mit kleinen Sicherheitsteams und Beschaffungszyklen, die in Semestern gemessen werden. Sie halten auch genau die Art von Daten, die Erpressungsgruppen lieben: Namen, Geburtsdaten, Stipendiendaten, Einwanderungsunterlagen. Die 68-Prozent-Konzentration ist eindeutig. ShinyHunters wusste, wo die leichten Ziele waren, und schlug dort zuerst zu.

Doch der Schadensradius endet nicht bei .edu-Domains. PeopleSoft ist weit verbreitet in regulierten Unternehmen – darunter Finanzdienstleister, Gesundheitssysteme und große öffentliche Arbeitgeber. Jeder, der noch auf dem gleichen verwundbaren Build sitzt, ist nur eine Shodan-Suchanfrage davon entfernt, das nächste Opfer zu sein. Teams, mit denen ich bei Fintechs gearbeitet habe, betreiben PeopleSoft typischerweise für das interne HR, während der kundenseitige Stack die gesamte Sicherheitsaufmerksamkeit bekommt. Wer von beiden enthält die Privatadressen und Bankdaten der Führungskräfte?

Für Vorstände und CTOs sehen die nächsten 90 Tage so aus: Die Rechtsabteilung wird eine schriftliche Bestätigung des Expositionsstatus verlangen. Versicherer werden Nachweise über die Einführungsdaten der Abhilfemaßnahmen anfordern. Regulierungsbehörden in Rechtsprechungen mit Meldepflicht bei Datenpannen (DSGVO, US-Gesetze auf Staatsebene, sektorspezifische Bankenregeln) werden die Reaktionszeiten ab dem 27. Mai messen – nicht ab Ihrem Erkennungsdatum. Wenn Sie nicht nachweisen können, dass Sie in diesem Zeitraum nicht kompromittiert wurden, sollten Sie davon ausgehen, dass Sie es waren.

Die unbequeme Schlussfolgerung: Ein Angriff auf 100 Kunden mit 300 angegriffenen Endpunkten deutet darauf hin, dass die Angreifer einen funktionierenden Scanner und eine Zielliste hatten. Jeder, der eine öffentlich zugängliche PeopleSoft-Instanz betreibt, sollte davon ausgehen, dass er gescannt wurde. Die Frage ist, ob der SSRF tatsächlich ausgelöst hat, bevor die Übergangslösung in Kraft trat.

Maßnahmen für Sicherheitsteams

Behandeln Sie dies als aktive Ausnutzung und handeln Sie diese Woche. Mandiant und Rapid7 veröffentlichen Indicators of Compromise. Holen Sie diese ab, speisen Sie sie in Ihr SIEM ein und führen Sie rückwirkende Suchen bis zum 27. Mai durch. Warten Sie nicht auf den vollständigen Oracle-Patch, bevor Sie die Übergangslösung anwenden. Ein halber Fix ist besser als keiner, wenn der Angreifer bereits im Gebäude ist.

Konkrete Maßnahmen:

• Wenden Sie Oracles Übergangslösung für CVE-2026-35273 sofort auf jede PeopleSoft-Instanz an – intern wie extern. Überprüfen Sie den CISA KEV für Statusaktualisierungen.
• Blockieren Sie ausgehende SSH-Verbindungen und beliebigen Egress-Traffic von PeopleSoft-Application-Tiers. Erlauben Sie nur die Ziele, die Ihre Batch-Jobs tatsächlich benötigen. Ja, etwas wird dadurch nicht mehr funktionieren. Beheben Sie das vorwärts.
• Suchen Sie nach ausgehenden Verbindungen zu 176.120.22.24 und nach zstd-komprimierten Archiven in temporären Verzeichnissen auf PeopleSoft-Hosts.
• Prüfen Sie Ihre WebLogic- und Prozess-Scheduler-XML-Konfigurationen auf Zugangsdaten und Service-Account-Tokens. Rotieren Sie alles, was vom App-Tier aus lesbar war.
• Ziehen Sie Access-Logs für das PeopleSoft-Web-Tier bis zum 27. Mai zurück und suchen Sie nach anomalen ausgehenden Abrufmustern, die auf SSRF-Sondierung hindeuten.

Für das Gespräch mit dem CTO: Dies ist der Moment, um zu überdenken, ob Legacy-Enterprise-Anwendungen im selben Netzwerksegment wie Ihr moderner Stack betrieben werden sollten. PeopleSoft wird in den meisten Umgebungen nicht verschwinden. Netzwerkisolierung, strikter Egress und ein ernsthafter Abkündigungs-Fahrplan für die risikoreichsten Module sind die einzigen dauerhaften Antworten. Ein einziger SSRF-Fehler sollte nicht in der Lage sein, Ihre Daten als 48-GB-zstd-Archiv nach außen zu schleusen.

Wichtigste Erkenntnisse

• CVE-2026-35273 ist ein SSRF mit Schweregrad 9,8 in Oracle PeopleSoft, wird seit dem 27. Mai aktiv ausgenutzt und ist bisher nur teilweise gepatcht.
• ShinyHunters hat rund 300 Endpunkte bei 100 Organisationen angegriffen, davon 68 Prozent im Hochschulbereich, und mindestens eine Erpressungsforderung bestätigt.
• Die Angriffskette war unspektakulär: SSRF, Aufklärung von PeopleSoft- und WebLogic-Konfigurationen, zstd-Komprimierung, SSH-Exfiltration zu 176.120.22.24.
• Ausgehende Egress-Controls bei Legacy-App-Tiers sind die günstigste Abhilfemaßnahme, die Sie noch nicht umsetzen. Beheben Sie das diese Woche.
• Gehen Sie von einer Sondierung aus, wenn Sie zwischen dem 27. Mai und dem Datum der Übergangslösung öffentliches PeopleSoft betrieben haben. Suchen Sie rückwirkend – patchen Sie nicht nur vorwärts.