Kurzfassung
OpenAM ist von sechs zusammenhängenden kritischen Schwachstellen betroffen, die je nach Konfiguration Authentifizierung umgehen, LDAP-Manipulation erlauben oder Code auf dem Server ausführen können. Besonders schwer wiegt CVE-2026-62379 mit CVSS 9.8, kritisch; betroffen sind OpenAM-Versionen vor 16.1.2, mehrere weitere Fehler wurden bereits mit 16.1.1 behoben. Für Unternehmen mit öffentlich erreichbaren OpenAM-Instanzen hat das hohe Priorität, vor allem wenn WebAuthn, MSISDN-Authentifizierung, OAuth mit PKCE oder ältere SOAP- und XML-Schnittstellen aktiv sind.
Was ist passiert?
Die NVD führt derzeit sechs kritische Schwachstellen in OpenAM, einer Plattform für Zugriffs- und Identitätsmanagement. Die Fehler betreffen unterschiedliche Komponenten, greifen aber operativ ineinander: Vor der Anmeldung erreichbare Endpunkte, unsichere Deserialisierung, unzureichend abgesicherte XML-Verarbeitung, fehlerhafte LDAP-Filterbildung sowie Schwächen in OAuth- und Liberty-Funktionen.
Die betroffenen CVEs sind CVE-2026-45051, CVE-2026-45052, CVE-2026-46619, CVE-2026-48717, CVE-2026-62263 und CVE-2026-62379. Nach NVD sind die ersten vier Fehler in Version 16.1.1 behoben, die beiden späteren bzw. die unvollständige Nachbesserung erst in 16.1.2.
Für den Betrieb ist wichtig: Nicht jede Installation ist automatisch über jeden der sechs Wege angreifbar. Mehrere Schwachstellen setzen bestimmte Module, Authentifizierungsflüsse oder unsichere Alt-Konfigurationen voraus. Trotzdem liegt das Gesamtrisiko hoch, weil OpenAM typischerweise zentral vor geschäftskritischen Anwendungen sitzt und ein erfolgreicher Angriff unmittelbar Sitzungen, Identitäten und nachgelagerte Zugriffe betreffen kann.
Technische Details
Die höchste technische Schwere weist CVE-2026-62379 mit CVSS 9.8 nach CVSS 3.1 auf. Der Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H bedeutet: Angriffe sind über das Netzwerk möglich, mit geringer Komplexität, ohne vorherige Anmeldung und ohne Mitwirkung eines Benutzers; bei Erfolg drohen hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Der CVSS-Wert beschreibt die technische Schwere, nicht automatisch eine bestätigte Ausnutzung in freier Wildbahn.
CVE-2026-62379 betrifft den vor der Anmeldung erreichbaren Endpunkt /authservice im PLL-Pfad. Dort soll ein manipuliertes CustomCallback-XML die Auswahl und Instanziierung beliebiger Java-Klassen ermöglichen; zusätzlich kann ein serialisierter Subject-Wert unsicher verarbeitet werden. Laut NVD ist der Fehler in Versionen vor 16.1.2 behoben.
CVE-2026-45051 beschreibt eine unsichere Deserialisierung in WebAuthn. OpenAM lädt vor 16.1.1 ein serialisiertes AuthenticatorImpl-Objekt aus einem konfigurierten Benutzerattribut, ohne den Objektgraphen ausreichend zu begrenzen. Ausnutzbar wird das laut NVD dann, wenn Angreifer zuvor kontrollierte Daten in dieses Attribut schreiben konnten, etwa über delegierte Administration, Provisionierung, Verzeichniszugriff, ältere Self-Registration-Wege oder unsichere Konfigurationen.
CVE-2026-62263 ist die nachfolgende Umgehung der ersten WebAuthn-Korrektur. Vor 16.1.2 erlaubt der eingesetzte Filter verschachtelte Objekte offenbar weiterhin zu großzügig, solange das Wurzelelement formal passt. Damit kann die erste Nachbesserung unter bestimmten Bedingungen umgangen werden, wenn passende Gadget-Klassen im Klassenpfad vorhanden sind.
CVE-2026-46619 betrifft das MSISDN-Authentifizierungsmodul. Dort wird ein vom Request gelieferter Wert in einen LDAP-Suchfilter übernommen, ohne die Sonderzeichen sicher zu maskieren. Ist das Modul in einer erreichbaren Authentifizierungskette aktiv, kann ein externer Angreifer laut NVD dadurch einen beliebigen passenden Benutzer auswählen und eine reguläre OpenAM-Sitzung ohne Passwort erhalten.
CVE-2026-48717 betrifft den OAuth-Autorisierungscodefluss mit PKCE. Vor 16.1.1 verlangt OpenAM einen code_verifier nur dann zwingend, wenn eine realm-weite Einstellung dafür aktiv ist. Ist das nicht der Fall, kann ein abgefangener Autorisierungscode unter Umständen auch ohne den eigentlich erwarteten PKCE-Nachweis eingelöst werden. Besonders relevant ist das für öffentliche Clients; bei vertraulichen Clients kommen zusätzliche Voraussetzungen hinzu.
CVE-2026-45052 betrifft Liberty-Web-Services per SOAP. Der SOAP-Empfänger soll nicht authentifizierte Remote-Anfragen akzeptieren, die persistente Einträge in Discovery-Speicher schreiben. Das kann nachgelagerte Komponenten beeinflussen, wenn diese manipulierte Discovery-Daten für Service-Routing oder Sicherheitsmechanismen auswerten.
Wer ist betroffen?
Direkt betroffen sind OpenAM-Installationen vor 16.1.1 beziehungsweise vor 16.1.2. Für CVE-2026-45051, CVE-2026-45052, CVE-2026-46619 und CVE-2026-48717 nennt die NVD als behobene Version 16.1.1. Für CVE-2026-62263 und CVE-2026-62379 ist 16.1.2 erforderlich.
Besonders prüfen sollten Unternehmen, ob ihre OpenAM-Systeme aus dem Internet erreichbar sind oder als zentraler Identitätsdienst intern viele Anwendungen absichern. Erhöht ist das Risiko, wenn WebAuthn genutzt wird, das MSISDN-Modul aktiv ist, OAuth mit PKCE für mobile oder Web-Clients eingesetzt wird oder SOAP-/XML-Funktionen aus älteren Integrationen noch freigeschaltet sind.
Für die meisten DACH-Unternehmen ist nicht jede einzelne CVE gleichermaßen relevant. Wer weder WebAuthn noch MSISDN noch Liberty Discovery nutzt, reduziert die Angriffsfläche erheblich. Kritisch bleibt aber schon deshalb die schnelle Prüfung, weil die Schwachstellen in einem Identitätsprodukt sitzen, das oft Single Sign-on, föderierte Anmeldung oder vorgeschaltete Zugriffskontrolle für viele Fachanwendungen übernimmt.
Empfohlene Maßnahmen
Erstens: OpenAM-Versionen inventarisieren und sofort auf 16.1.2 anheben, wenn Ihre Umgebung noch darunter liegt. Wer auf 16.1.1 aktualisiert hat, ist gegen CVE-2026-62263 und CVE-2026-62379 noch nicht vollständig geschützt.
Zweitens: Exponierte Endpunkte vor der Anmeldung kurzfristig einschränken. Prüfen Sie insbesondere, ob /authservice, WebAuthn-Flows, SOAP-Schnittstellen und selten genutzte Authentifizierungsketten aus dem Internet erreichbar sein müssen. Wenn nicht, per Reverse Proxy, Firewall oder Netzsegmentierung sperren.
Drittens: Konfigurationen auf die konkret betroffenen Funktionen prüfen. Deaktivieren Sie ungenutzte MSISDN-Authentifizierung, Liberty Discovery und ältere Self-Registration- oder Provisionierungswege. Kontrollieren Sie Realm-Einstellungen rund um PKCE und erzwingen Sie den code_verifier, wo OAuth-Autorisierungscodes im Einsatz sind.
Viertens: Verzeichnis- und Attributschreibrechte eng ziehen. Für die WebAuthn-Probleme ist relevant, wer Benutzerattribute befüllen oder verändern darf. Delegierte Administration, Provisionierung, Verzeichniszugriffe und Importpfade gehören jetzt auf den Prüfstand.
Fünftens: Logs gezielt auswerten. Suchen Sie nach ungewöhnlichen Aufrufen von /authservice, verdächtigen XML-Elementen wie CustomCallback, atypischen SOAP-Requests, auffälligen OAuth-Codeeinlösungen ohne erwarteten PKCE-Kontext sowie unerwarteten Anmeldungen über MSISDN-Ketten.
Sechstens: Wenn OpenAM vor geschäftskritischen Anwendungen steht, behandeln Sie die Instanz als potenziell kompromittierten Vertrauensanker, falls es bereits verdächtige Spuren gibt. Dann reichen Patch und Neustart nicht aus; prüfen Sie Sitzungen, Tokens, Konfigurationen, Verzeichnisänderungen und Anwendungsanbindungen auf Missbrauch.
Einschätzung von CyberSecurity-News.de
Die technische Schwere ist hoch, und zwar nicht nur wegen eines einzelnen Fehlers. Hier kommt eine Häufung in sicherheitskritischen Funktionen zusammen: Vor-Authentifizierungs-Endpunkte, Deserialisierung, Identitäts- und OAuth-Flows. Für ein IAM-Produkt ist das deutlich gravierender als eine isolierte Schwachstelle in einem Randmodul.
Die Informationslage ist dennoch ungleich. Die NVD nennt präzise technische Zusammenhänge und Fix-Versionen, aber keine Aussagen dazu, ob es bereits aktive Ausnutzung gibt. Ein Hersteller-Hinweis mit Patch- und Betriebsdetails liegt in den vorliegenden Angaben nicht vor. Für Administratoren ist das unpraktisch, weil gerade bei OpenAM die tatsächliche Exponierung stark von Realm-Design, Altmodulen und individuellen Integrationen abhängt.
Wichtig ist auch die Abfolge der WebAuthn-Fehler: CVE-2026-62263 korrigiert nicht einfach einen neuen Randaspekt, sondern beschreibt eine Umgehung der ersten Maßnahme gegen CVE-2026-45051. Wer nur auf 16.1.1 gegangen ist und die Sache damit als erledigt betrachtet, liegt unter Umständen falsch. Genau das macht die Priorität für den Betrieb hoch.
Fazit
Wenn Sie OpenAM betreiben, sollten Sie zügig auf 16.1.2 aktualisieren und parallel prüfen, welche der betroffenen Funktionen in Ihrer Umgebung überhaupt aktiv und erreichbar sind. Priorität haben öffentlich zugängliche Instanzen und zentrale SSO-Systeme.
Wer OpenAM nur intern, stark segmentiert und ohne die genannten Module nutzt, kann die operative Dringlichkeit besser staffeln. Aufschieben sollten Sie die Prüfung trotzdem nicht: Bei Identitätsdiensten wirkt sich schon ein einzelner erfolgreicher Angriff meist weit über den betroffenen Server hinaus aus.
