miniOrange SAML SSO-Schwachstelle ermöglichte Angreifern die Umgehung des WordPress-Admin-Logins

Zwei kritische WordPress-Authentifizierungsumgehungsfehler im miniOrange SAML 2.0 Single Sign On-Plugin, verfolgt als CVE-2026-61979 und CVE-2026-15981, ermöglichten einem nicht authentifizierten Angreifer, sich als beliebiger vorhandener Benutzer, einschließlich eines Administrators, in eine WordPress-Website einzuloggen. Nicht authentifiziert bedeutet, dass der Angreifer kein eigenes Konto und kein eigenes Passwort benötigte. Die Entdeckung und die Ursachenanalyse stammen vom DigitalOcean-Sicherheitsteam, wobei die Berichterstattung und die Nachverfolgung durch den Anbieter gemeinsam mit Patchstack durchgeführt wurden. Beide Fehler haben einen CVSS-Score von 9,8, einer Schweregradbewertung von 0 bis 10, und beide wurden im Juli 2026 öffentlich bekannt gegeben.

Das Plugin verarbeitet SAML, was für Security Assertion Markup Language steht, einen Standard, der es einer Website ermöglicht, eine von einem externen Identitätsdienst bestätigte Anmeldung zu akzeptieren, anstatt das Passwort selbst zu überprüfen. Dieser externe Dienst wird als Identity Provider oder IdP bezeichnet. Beide Fehler untergraben dieses Vertrauen: Sie überzeugen das Plugin davon, dass eine gefälschte Anmeldenachricht, eine sogenannte SAML-Assertion, echt ist.

Der erste Fehler, CVE-2026-61979, ist eine Verwechslung der Signaturalgorithmen. Eine Signatur ist der digitale Stempel, der beweist, dass eine Nachricht wirklich vom vertrauenswürdigen Identitätsdienst stammt. Das Plugin lässt die eingehende SAML-Antwort auswählen, welche Signaturmethode verwendet wurde. Ein Angreifer kann diese Methode auf HMAC-SHA1 setzen, eine Art der Signierung mit einer gemeinsamen geheimen Zeichenkette, und das Plugin akzeptiert dann den öffentlichen RSA-Schlüssel des Identitätsanbieters, als wäre er dieses Geheimnis. Ein öffentlicher Schlüssel ist konstruktionsbedingt öffentlich. Daher ruft der Angreifer den Schlüssel vom veröffentlichten Metadaten-Endpunkt des Identitätsanbieters ab, signiert seine eigene Assertion damit, und das Plugin akzeptiert das Ergebnis als echt. Die Analyse von DigitalOcean für die Standard-Edition 16.1.9 weist auf bestimmte Codepfade hin: Utilities.php Zeilen 246 bis 250, die den vom Angreifer gewählten Algorithmus lesen und den RSA-Schlüssel umwandeln; Utilities.php Zeilen 259 bis 281, die den öffentlichen Schlüssel extrahieren und neu laden; und drei Stellen in includes/lib/SAML2Core/XMLSecurityKey.php (Zeilen 216 bis 218, 308 bis 314 und 546 bis 548), die HMAC-SHA1 als Option zulassen, das öffentliche Schlüsselmaterial als Rohbytes belassen, anstatt es abzulehnen, und es direkt als Geheimnis in die Funktion hash_hmac übergeben. miniOrange hat diesen Fehler in Version 17.0.5 für die Standard-Edition behoben.

Der zweite Fehler, CVE-2026-15981, ist ein anderer Fehler mit demselben Ergebnis. Die OpenSSL-Bibliotheksfunktion openssl_verify gibt drei mögliche Antworten zurück: 1 für eine gültige Signatur, 0 für eine ungültige und -1, wenn OpenSSL selbst auf einen internen Fehler stößt. Das Plugin überprüfte dieses Ergebnis als einfaches Wahr oder Falsch, und in PHP, der Programmiersprache, auf der WordPress läuft, zählt die Zahl -1 als wahr. Eine fehlerhafte Signatur, die den Fehlerpfad von OpenSSL auslöst, wird also als gültige Signatur behandelt. Die Codepfade in Version 16.1.9 sind XMLSecurityKey.php Zeilen 486 bis 494, die das rohe dreiwertige Ergebnis zurückgeben, und Utilities.php Zeile 252, die es in einen booleschen Wert umwandelt. miniOrange hat dies in Version 17.0.6 für die Standard-Edition behoben. Ein drittes, separates Problem wurde kurz nach diesen Korrekturen bekannt gegeben. Es erfordert, dass ein Administrator auf etwas klickt (in CVSS-Begriffen als UI:R beschrieben), sodass es in der praktischen Schwere deutlich unter den anderen beiden liegt, aber Patchstack merkt an, dass es sich lohnt, im selben Durchgang gepatcht zu werden.

Der Grund, warum diese Geschichte größer ist als der Code, ist die Verpackung. miniOrange vertreibt alle diese Produkte unter einem einzigen WordPress-Eintrag und Slug, miniorange-saml-20-single-sign-on, und dieser eine Eintrag enthält sieben separat versionierte Editionen. Keine zwei teilen eine Versionsnummer. Die kostenlose Single-Site-Edition läuft ab 3.0.0 und ist derzeit bei 5.4.7, und sie war bis einschließlich 5.4.4 anfällig, behoben in 5.4.5. Premium Single Site läuft von 11.3.0 bis 13.1.0, anfällig bis 13.0.3 und behoben in 13.0.4. Standard Single Site läuft von 15.1.0 bis 17.1.0, anfällig bis 17.0.5 und behoben in 17.0.6. Die Multisite Premium-, Enterprise- und All-Inclusive-Pläne laufen von 20.0.0 bis 20.2.8, anfällig bis 20.2.7 und behoben in 20.2.8. Enterprise und All-Inclusive Single Site läuft von 25.0.0 bis 26.1.0, anfällig bis 26.0.2 und behoben in 26.0.3. VIP Single Site läuft von 32.0.0 bis 32.0.8, anfällig bis 32.0.7 und behoben in 32.0.8. VIP Multisite läuft von 35.0.0 bis 35.0.7, anfällig bis 35.0.6 und behoben in 35.0.7. Da jede Edition mehrere Hauptversionsnummern umfasst, sagt eine Versionsnummer allein nicht aus, welche Edition Sie ausführen. Der Anbieter hat diese vollständige Aufschlüsselung an Patchstack geliefert, das angibt, dass sie zuvor nirgendwo veröffentlicht worden war.

Die öffentlichen Sicherheitshinweise für beide CVEs betrafen nur die kostenlose Edition, die einzige, die jeder von WordPress.org herunterladen kann. Dieser Eintrag besagte, dass das Plugin bis einschließlich 5.4.4 betroffen und in 5.4.5 behoben war. Der Eintrag selbst ist korrekt, aber es ist ein einzelner Bereich, der an einen einzelnen Slug angehängt ist. Jede kostenpflichtige Installation trägt eine höhere Versionsnummer als 5.4.5, sodass jede kostenpflichtige Installation als bereits gepatcht gelesen wurde. Eine Website mit der anfälligen Standard-Version 16.1.9 wurde als nicht betroffen gemeldet, und ebenso jede andere anfällige kostenpflichtige Version in den 13.x-, 20.x-, 26.x-, 32.x- und 35.x-Linien. Eine Erweiterung des Bereichs behebt das auch nicht: Dehnen Sie den Eintrag auf 17.0.5 aus, damit eine anfällige 16.1.9 erfasst wird, und kostenlose Editionen, die bereits auf 5.4.5 oder später gepatcht sind, werden stattdessen als anfällig gemeldet. Die Tabelle des Anbieters beschreibt die betroffene Menge genau als sieben separate Bereiche auf einem Slug, was der Datenbankeintrag jetzt enthält. Die sechs kostenpflichtigen Editionen wurden ohne öffentlichen Changelog-Eintrag und ohne öffentliche Sicherheitsmeldung gepatcht, wodurch die gesamte nachgelagerte Kette – Datenbanken, Scanner und Dashboards – auf einmal blind wurde.

Abhilfe war ebenso schwer zu finden. Patchstack sagt, dass WordPress-Websites mit einer anfälligen 16.x-Standard-Version überhaupt kein verfügbares Update im Admin-Dashboard sehen, obwohl die behobene 17.0.6 auf derselben Standard-Linie existiert, für die der Kunde bereits eine Lizenz besitzt. Der typische WordPress-Update-Mechanismus bietet diese Art von Sprung zwischen Hauptversionslinien nicht an, sodass die Korrektur manuell hochgeladen werden muss.

Was den Fall bemerkenswert macht, ist, wie das Problem tatsächlich entdeckt wurde. Es gab keinen Hinweis zum Lesen und keinen Datenbankeintrag, der die kostenpflichtigen Editionen kennzeichnete, und das Plugin meldete sich selbst als vollständig aktuell. Jedes Signal, das normalerweise vor Problemen warnt, sagte, alles sei in Ordnung. DigitalOcean entdeckte es durch Verteidigung in der Tiefe statt durch Plugin-Daten: Ein anomaler WordPress-Administrator-Sitzungsversuch kam von außerhalb seines vertrauenswürdigen Netzwerks und wurde blockiert. Der Angreifer hatte die Umgehung bereits genutzt, um ein Administrator-Sitzungscookie zu erhalten, das Token, das Sie eingeloggt hält, wurde aber gestoppt, weil Admin-Panel-Operationen auf dieser Infrastruktur auf das vertrauenswürdige Netzwerk beschränkt waren. Das Team reproduzierte dann die Umgehung von Anfang bis Ende auf Version 16.1.9, verfolgte beide Fehler bis zu bestimmten Zeilen, fand heraus, welche kostenpflichtigen Versionen betroffen waren, wo der Anbieter nichts veröffentlicht hatte, schrieb und validierte zwei Hotfixes und teilte die Analyse zur Veröffentlichung. Patchstack berichtet über Scan-Aktivitäten gegen die miniOrange SSO-Endpunkte von 207.211.214.41 und 79.127.224.14 in Brüssel, Belgien (VPN oder Rechenzentrum), 102.91.71.83 in Abuja, Nigeria (Mobilfunkanbieter), 162.243.116.148 in Secaucus, Vereinigte Staaten (Cloud oder VPS), 84.201.6.54 in Frankfurt, Deutschland (Hosting oder Rechenzentrum) und 64.225.25.188 in Clifton, Vereinigte Staaten (Cloud oder VPS). Die geografische Verteilung deutet auf opportunistisches Scannen hin, nicht auf eine gezielte Kampagne, wobei der Angreifer auf jede Website feuert, auf der das Plugin installiert ist, ohne zu prüfen, welche Edition dahinter steckt. Ein öffentlicher Proof of Concept für die kostenlosen Versionen existiert auf GitHub; Patchstack sagte, es werde die Ausnutzungsschritte nicht reproduzieren, da sie defensiv nichts bringen.

Für alle, die eine betroffene Version ausführen, lautet Patchstacks Rat, auf die gepatchte Version für Ihre Edition zu aktualisieren, wobei Sie erwarten sollten, die Plugin-Datei von Hand hochzuladen, anstatt auf eine Update-Schaltfläche zu klicken. Wenn ein sofortiges Upgrade unmöglich ist, hat DigitalOcean zwei bewusst eng gefasste Hotfixes veröffentlicht: einen, der verhindert, dass das Plugin eine HMAC-SHA1-Signaturmethode akzeptiert, direkt nach Zeile 246 von Utilities.php eingefügt, und einen, der die Signaturprüfung in XMLSecurityKey.php Zeile 494 dazu bringt, nur ein Ergebnis von genau 1 zu akzeptieren. Beide sollen Zeit gewinnen, nicht den Anbieter-Fix ersetzen. Eine vollständige Behebung würde eine Einschränkung erfordern, welche Signaturalgorithmen erlaubt sind, die Entfernung des Codepfads, der einen öffentlichen Schlüssel umwandelt, eine harte Sperre gegen asymmetrische Schlüssel, die in den HMAC-Zweig gelangen, und eine allgemeine Härtung der mitgelieferten XML-Sicherheitsbibliothek. Patchstack empfiehlt außerdem, Protokolle auf authentifizierte Administrator-Sitzungen zu prüfen, die von IP-Adressen außerhalb Ihrer üblichen Bereiche kommen, da dieses Signal nicht von Ihrer Plugin-Version abhängt. Für Teams, die Plugin-Updates lieber nicht selbst verwalten möchten, bietet AEU Hosting managed WordPress-Hosting an, bei dem das Patchen als Teil des Services erledigt wird, eine Art von Vereinbarung, die einen manuellen Upload-Schritt von Ihrer To-do-Liste streicht.

Die breitere Lehre, die Patchstack zieht, ist, dass Schwachstellendatenbanken nur so gut sind wie die Versionsinformationen, die Anbieter veröffentlichen. Wenn ein Slug sieben unabhängig nummerierte Editionen verbirgt und sechs davon ohne öffentliche Sicherheitsmeldung behoben werden, versagen die Datenbanken, Scanner und Dashboards stromabwärts alle zusammen. Patchstack macht hier eine präzise Unterscheidung: Eine Firewall-Regel, die das Exploit-Muster blockiert, kümmert sich nicht darum, welche Edition Sie ausführen, sodass virtuelles Patchen alle sieben auf einmal schützen kann, ob sie dokumentiert sind oder nicht, während genaue Alarmierung das nicht kann, weil sie nur funktioniert, wenn sie weiß, was Sie installiert haben. In diesem Fall skalierte der Schutz; die Berichterstattung war das, was kaputt ging.