CVE-2025-61757: Pre-Auth Remote Code Execution in Oracle Identity Manager (REST WebServices)

Oracle Identity Manager (OIM) ist die Art von System, die man erst bemerkt, wenn sie kaputt geht. Es stellt Identitäten bereit, verwaltet Berechtigungen, erteilt oder vermittelt Zugang und ist oft jeder ernsthaften Unternehmensanwendung vorgeschaltet. Wenn eine Schwachstelle in OIM auftritt, handelt es sich selten um "nur eine weitere CVE". CVE-2025-61757 ist ein kritisches Beispiel: ein unauthentifizierter, netzwerkerreichbarer RCE in der REST-WebServices-Komponente von OIM, die zu einer vollständigen Übernahme der Identitätsebene führen kann. NVD fasst es klar und deutlich zusammen: Die betroffenen unterstützten Versionen sind 12.2.1.4.0 und 14.1.2.1.0Ausbeutung erfordert keine Authentifizierungerfolgt über HTTPund ergibt schwerwiegender Kompromiss über Vertraulichkeit, Integrität und Verfügbarkeit, mit einem CVSS 3.1-Wert von 9.8 (kritisch). (NVD)

Dieser CVE ist nicht nur wegen seines Ergebnisses eine gründliche Lektüre wert, sondern auch wegen seiner wobei es lebt. Identitätsplattformen sind die Vertrauensbasis moderner Unternehmen. Ein Angreifer, der Code auf OIM ausführt, ist nur einen Schritt davon entfernt, Identitäten zu fälschen, Rollenzuweisungen zu manipulieren oder in angrenzende Middleware- und Anwendungsebenen einzudringen. Mit anderen Worten, CVE-2025-61757 ist eine primitive Identitätsübernahmeund nicht ein Fehler in der App.

Die meistzitierte öffentliche Analyse: Warum diese Kette funktioniert

Unter den öffentlich zugänglichen Aufzeichnungen ist der Forschungsbeitrag von Searchlight Cyber ("Breaking Oracle's Identity Manager: Pre-Auth RCE") derzeit die am meisten referenzierte, detaillierte Analyse für CVE-2025-61757, die auch von SANS und anderen Trackern aufgegriffen wird. (Suchscheinwerfer Cyber) Ihre Hauptbehauptung ist, dass die Schwachstelle eine zweistufige Kette:

1. a Umgehung der Vorauthentifizierung in einem zentralisierten Java-Sicherheitsfilter die die REST-Verwaltungsoberfläche schützt, und
2. Missbrauch eines hochprivilegierte Verwaltungs-/Skriptverwaltungsfunktionen, die von diesen REST-APIs bereitgestellt werdenbis hin zur entfernten Codeausführung. (Suchscheinwerfer Cyber)

Die genauen Mechanismen der Nutzlast sind für Verteidiger nicht wichtig (und sollten außerhalb eines autorisierten Labors nicht wiederholt werden). Was zählt, ist das Muster: ein klassisches "Zentraler Filter + spröde Zulassen-Liste" Design, bei dem die Authentifizierung durch Abgleich von Anfrage-URIs mit einer zulässigen Whitelist erzwungen wird. In Java-Unternehmensanwendungen der alten Schule ist dies üblich; in Bezug auf die Sicherheit ist es ein immer wiederkehrendes Mittel. Wenn Ihre Zugriffskontrolle von einem String- oder Regex-Abgleich über komplexe URI-Parsing-Regeln abhängt, setzen Sie darauf, dass jede Die vorgelagerte Komponente normalisiert die Pfade auf die gleiche Weise. Diese Wette geht tendenziell verloren.

Eine sichere Methode zur Erfassung der Ursachenform ist die Betrachtung einer abstrahierten Version der Logik:

// Pseudocode zur Veranschaulichung des Antipatterns (kein Produktcode)
if (request.uri.matches(ALLOWLIST_PATTERN) || request.query.equalsIgnoreCase("SPECIAL_CASE")) {
    chain.doFilter(request, response); // überspringt auth
} sonst {
    enforceAuthentication();
}

Sobald Angreifer das Authentifizierungstor umgehen können, wird jeder leistungsstarke Admin-Endpunkt zu einem potenziellen Ausführungs-Trampolin. Die wichtigste Erkenntnis von Searchlight ist nicht "dieser spezielle Endpunkt ist gefährlich", sondern "REST-Administrationsoberflächen in IAM-Produkten beinhalten oft Skriptkompilierung, Konnektorverwaltung oder Workflow-Hooks mit implizitem Vertrauen." Wenn diese ohne Autorisierung offengelegt werden, erhalten Sie RCE mit Absicht, nicht aus Versehen. (Suchscheinwerfer Cyber)

Die allgemeinere technische Lehre ist über diesen einzelnen CVE hinaus nützlich: zentralisierte Filter mit Erlaubnislisten sind eine strukturelle Schwachstelle. Wenn Sie den Code Ihrer eigenen Java-Dienste überprüfen (oder Middleware von Anbietern prüfen), sollten Sie "central allow-list auth" als einen Geruch behandeln, der eine gegnerische Prüfung verdient.

Betroffene Versionen und Patch-Kontext

Oracle behebt CVE-2025-61757 in der Oktober 2025 Kritisches Patch-Update (CPU), veröffentlicht am 2025-10-21. (Oracle) Die unterstützten betroffenen Versionen, die in mehreren Trackern genannt werden, sind:

Dies stimmt mit NVD, Wiz' Schwachstellen-DB und runZeros Expositionsbericht überein. (NVD)

Ein subtiler, aber wichtiger operativer Punkt: Oracle-CPUs sind vierteljährlich. Unternehmen, die nicht über eine straffe CPU-Aufnahme und -Rollout-Muskulatur verfügen, neigen dazu, "Patch-Schulden" in Identitäts- und Middleware-Stacks anzuhäufen, da diese als stabile, wenig veränderliche Systeme angesehen werden. CVE-2025-61757 durchbricht diese Annahme. Wenn Ihre REST-Verwaltungsebene von nicht vertrauenswürdigen Netzwerken aus erreichbar ist, handelt es sich nicht um einen Fehler, den Sie auf "nächstes Quartal" verschieben können.

Angriffsfläche Realität: Warum dieses CVE schnell gescannt werden wird

Auch ohne auf die Details des Exploits einzugehen, kann man an der Form des CVSS-Vektors erkennen, warum automatisierte Bedrohungsakteure sich dafür interessieren. NVD und Wiz listen ihn als:

• AV:N (Netzwerk erreichbar),
• AC:L (geringe Komplexität),
• PR:N/UI:N (keine Privilegien, keine Benutzerinteraktion),
• C:H/I:H/A:H (vollständige Wirkung). (NVD)

Diese Kombination ist das "grüne Licht" für handelsübliche Scanner. In dem Moment, in dem ein PoC in den öffentlichen Kanälen landet, wird er ein Fingerabdruck auf einmalige Anfrage + Folgekette in Botnets. Identitätsserver, die durch falsch konfigurierte Load Balancer, veraltete NAT-Regeln oder Lücken in der Remote-Unterstützung von Anbietern unbemerkt bleiben, tauchen in diesen Scans meist schnell auf.

Sie haben auch ein größeres Kontextproblem: Oracle Middleware war im Jahr 2025 ein hochwertiges Ziel, da mehrere kritische, nicht authentifizierte Fehler in benachbarten Produkten (WebLogic, EBS, Marketing-Module) zu aktiven Kampagnen führten. In der CPU-Prüfung von Qualys vom Oktober werden kritische Fusion Middleware-Fehler ausdrücklich als Hochrisikocluster hervorgehoben. (Qualys) Dies erhöht die Wahrscheinlichkeit, dass Angreifer die OIM-Kompromittierung in breitere Oracle-Vermögensoperationen einbinden.

Defensive Überprüfung, ohne dass die Erkennung in eine Ausnutzung umschlägt

Für die meisten Teams ist die erste Aufgabe einfach: Exposition erkennennicht die Angreifer nachahmen. Ein sicherer, autorisierter Arbeitsablauf sieht wie folgt aus:

1. Bestandsaufnahme der OIM-Versionen in verschiedenen Umgebungen und vergleichen Sie sie mit den betroffenen Linien.
2. Zugang der Verwaltung einschränken sofort (Netzwerk-ACLs, VPN-Gate, ZTNA), sogar vor Patch-Fenstern.
3. REST-Admin-Anomalien jagen in Zugriffsprotokollen: URIs mit hoher Entropie, Bursts von unbekannten IPs oder Endpunkte der Administratorklasse, die zu Zeiten aufgerufen werden, zu denen keine Änderungen vorgenommen werden.

Um dies zu verdeutlichen, finden Sie hier einen rein defensiven Versionsabgleich, den Sie in Ihre Inventarisierungsaufträge integrieren können:

# Nur defensiv: Übereinstimmung der entdeckten OIM-Versionen mit der betroffenen Menge
aus Verpackung importieren Version

AFFECTED = [
    ("12.2.1.4.0", "12.2.1.4.0"),
    ("14.1.2.1.0", "14.1.2.1.0"),
]

def is_affected(v: str) -> bool:
    v = version.parse(v)
    return any(version.parse(lo) <= v <= version.parse(hi) for lo, hi in AFFECTED)

for v in ["12.2.1.4.0", "14.1.2.1.0", "14.1.2.2.0"]:
    print(v, "affected?" , is_affected(v))

Wenn Sie die Versionen nicht zuverlässig aus Bannern extrahieren können, sollten Sie internen CMDB-Daten, Host-Paketmanifesten oder Oracle-Home-Metadaten den Vorzug geben. Wichtig ist, dass Sie Ihre Identitätsebene nicht auf eine Weise "sondieren", die das Betriebsrisiko erhöht.

Post-Patch-Jagd: Wie ein Kompromiss aussehen würde

Die Searchlight-Kette impliziert eine bestimmte Klasse von Verhaltensweisen, auf die Sie achten sollten, auch nach einem Upgrade:

• REST-Verwaltungsendpunkte werden von unbekannten Quellen angegriffeninsbesondere aus öffentlichen IP-Bereichen.
• Managementverben, die außerhalb von Änderungsfenstern verwendet werdeninsbesondere alles, was kompiliert, hochlädt oder Arbeitsabläufe/Verbindungen verändert.
• Neue Dienstkonten oder Rollenänderungen die nicht mit dem Fahrkartenverkauf übereinstimmen.

Sowohl RunZero als auch Wiz raten dazu, Protokolle auf ungewöhnliche REST-Aktivitäten zu überprüfen und die Erreichbarkeit des Managements als Teil der Härtung einzuschränken, nicht nur zur Behebung. (RunZero)

Der Grund, dies nach dem Patchen ernst zu nehmen, ist, dass Pre-Auth RCE-Bugs oft ausgenutzt werden vor Offenlegung. Wenn die REST-Ebene offengelegt wurde, ist davon auszugehen, dass sie möglicherweise berührt wurde.

Abhilfemaßnahmen, die das Risiko tatsächlich verringern

Die offizielle Empfehlung von Oracle lautet, die CPU-Updates vom Oktober 2025 anzuwenden, die den Fix enthalten. (Oracle) Aus technischer Sicht sehen die risikomindernden Maßnahmen folgendermaßen aus:

• Patch sofort auf jeder betroffenen unterstützten Version.
• Öffentliche Erreichbarkeit entfernen von REST-Verwaltungsebenen. Identitätsverwaltungs-APIs sollten nicht mit dem Internet verbunden sein.
• Privilegierte Zugangsdaten rotieren und erfordern MFA, wo immer dies operativ möglich ist.
• Baseline und Überwachung OIM-Konfigurationsabweichung (Rollen, Verbindungen, Arbeitsabläufe).
• Segmentierung der IAM-Schicht so dass selbst bei einer Beeinträchtigung der OIM die seitliche Bewegung verlangsamt wird.

Nichts davon ist neu, aber CVE-2025-61757 ist eine Fallstudie, die zeigt, warum IAM-Härtung nicht als "einrichten und vergessen" behandelt werden kann. Identitäts-Middleware gehört jetzt fest zur gleichen Bedrohungspriorität wie Edge-VPNs und Web-Gateways.

Warum dieses CVE für KI-Sicherheitsingenieure wichtig ist

Wenn Sie an der Schnittstelle von KI-Systemen und Sicherheit arbeiten, ist OIM eine zunehmend relevante vorgelagerte Abhängigkeit. Ihre Model-Serving-Cluster, Datenplattformen, CI/CD und sogar interne LLM-Tools erben oft Zugriffsentscheidungen von der Unternehmens-IAM. Durch die Übernahme der Identitätsinfrastruktur vor der Authentifizierung "legitimieren" Angreifer eine spätere Kompromittierung des KI-Stacks: Sie müssen einen Modellserver nicht zerstören, wenn sie die Identität, die ihn ändern darf, prägen können.

Aus Sicht der defensiven KI ist CVE-2025-61757 eine Mahnung, Identitätstelemetrie als erstklassiges Signal in Ihren Erkennungspipelines zu behandeln. Wenn Sie agentenbasierte Sicherheitstools entwickeln, ist die realistischste "High-Impact-Automatisierung" nicht die spekulative Exploit-Generierung, sondern eine realitätsgetreue Inventarisierung, Modellierung des Explosionsradius und Patch-Orchestrierung für Identitäts- und Middleware-Bestände.

Eine kleine Anmerkung zur Automatisierung (wenn es passt)

In großen Oracle-Umgebungen ist der Versionswildwuchs real: Entwicklungs-, QA-, DR- und Legacy-Tenants hinken oft um Vierteljahre hinterher. Human-in-the-Loop-Automatisierungsplattformen wie Penligent können helfen bei Flottenweites OIM-Versionsinventar, Validierung der Exposition und Verfolgung von Abhilfemaßnahmen, ohne die Teams zu einer riskanten Ausnutzung zu drängen. Wenn die Schwachstelle identitätskritisch ist, sind Geschwindigkeit und Genauigkeit in der Schleife "Finden → Priorisieren → Beheben" wichtiger als alles andere.

Schließen

Bei CVE-2025-61757 handelt es sich nicht nur um einen Fehler, sondern um eine hochwirksame Kompromittierungsroute für die Identitätsebene, die aus einem bekannten Java-Anti-Pattern für Unternehmen resultiert. Die unmittelbare Forderung liegt auf der Hand: Patchen Sie die betroffenen OIM-Versionen und sperren Sie den REST-Verwaltungszugang. Längerfristig ist das Problem jedoch größer: Wenn Ihre IAM-Kontrollebene erreichbar ist, wird sie angegriffen - und die zentralisierten Zulassen-Listen-Filter werden umgangen. Behandeln Sie dieses CVE als eine Zwangsfunktion, um zu prüfen, wie Ihre Identitätssysteme ausgesetzt, authentifiziert und überwacht werden.