miniOrange SAML SSO Admin-Bypass betrifft sechs kostenpflichtige Editionen

Zwei kritische Authentifizierungs-Bypass-Schwachstellen im miniOrange SAML 2.0 Single Sign On Plugin ermöglichen es nicht authentifizierten Angreifern, SAML-Assertions zu fälschen und sich bei WordPress als beliebiger vorhandener Benutzer anzumelden, einschließlich Administratoren. Die Forschung wurde vom DigitalOcean-Sicherheitsteam gemeldet, mit Root-Cause-Analyse durch DigitalOcean und Berichterstattung sowie Vendor-Follow-up in Zusammenarbeit mit Patchstack. Beide Schwachstellen haben einen CVSS-Schweregrad von 9.8 und wurden im Juli 2026 öffentlich bekannt gegeben. Obwohl beide vom Hersteller behoben wurden, hatten eine große Gruppe von Websites und viele Unternehmenskunden keine Möglichkeit zu erfahren, dass sie betroffen waren, sahen kein ausstehendes Update in ihrem WordPress-Dashboard und waren von keiner Schwachstellen-Datenbank abgedeckt.

Der erste Fehler, CVE-2026-61979, ist ein Problem mit der Signaturalgorithmus-Verwechslung. Das Plugin überprüft normalerweise eine SAML-Antwort mit einem vertrauenswürdigen RSA-öffentlichen Schlüssel vom Identitätsanbieter (IdP). Aber das Plugin lässt die eingehende SAML-Antwort ihren eigenen Signaturalgorithmus wählen. Ein Angreifer kann die SignatureMethod auf HMAC-SHA1 setzen, und das Plugin verwendet dann den öffentlichen RSA-Schlüssel-PEM als HMAC-Geheimnis. Da dieser öffentliche Schlüssel per Definition öffentlich ist, kann der Angreifer ihn vom IdP-Metadaten-Endpunkt abrufen, als HMAC-Geheimnis verwenden, eine gefälschte Assertion signieren, und das Plugin akzeptiert sie als echt. Die Root-Cause-Analyse, die gegen die Standard Edition 16.1.9 durchgeführt wurde, verweist auf Utilities.php Zeilen 246-250, die den vom Angreifer gewählten Algorithmus lesen und den RSA-Schlüssel umwandeln, und XMLSecurityKey.php Zeilen 308-314 und 546-548, die das PEM-Schlüsselmaterial als Rohbytes belassen und es dann direkt an hash_hmac() übergeben. miniOrange hat dies in der Standard Edition 17.0.5 behoben.

Der zweite Fehler, CVE-2026-15981, stammt aus einer lockeren Überprüfung des OpenSSL-Verifizierungsergebnisses. Die Funktion openssl_verify() gibt 1 für eine gültige Signatur zurück, 0 für eine ungültige Signatur und -1, wenn OpenSSL selbst auf einen internen Fehler stößt. Das Plugin prüfte das Ergebnis als Boolean, und in PHP ist der Wert -1 wahr, sodass eine fehlerhafte Signatur, die einen OpenSSL-Fehlerpfad auslöst, als gültig akzeptiert wurde. Die relevanten Codepfade sind XMLSecurityKey.php Zeilen 486-494, die das rohe Drei-Zustands-Ergebnis zurückgeben, und Utilities.php Zeile 252, die es als Boolean auswertet. miniOrange hat dies in der Standard Edition 17.0.6 behoben. Ein drittes, separates Problem wurde kurz nach diesen Fixes offengelegt, erfordert jedoch, dass ein Administrator auf etwas klickt, sodass es in der praktischen Schwere unter den ersten beiden liegt.

Das Plugin wird unter einem einzigen WordPress-Slug ausgeliefert, miniorange-saml-20-single-sign-on, aber diese eine Auflistung enthält stillschweigend sieben separat versionierte Produkteditionen. Die öffentlichen Advisories deckten nur die kostenlose Edition ab. Der Hersteller stellte die folgende Aufschlüsselung zur Verfügung. Kostenlos (Einzelstandort): erste Version 3.0.0, neueste 5.4.7, anfällig bis 5.4.4, behoben in 5.4.5. Premium (Einzelstandort): erste Version 11.3.0, neueste 13.1.0, anfällig bis 13.0.3, behoben in 13.0.4. Standard (Einzelstandort): erste Version 15.1.0, neueste 17.1.0, anfällig bis 17.0.5, behoben in 17.0.6. Premium/Enterprise/All-Inclusive (Multisite): erste Version 20.0.0, neueste 20.2.8, anfällig bis 20.2.7, behoben in 20.2.8. Enterprise/All-Inclusive (Einzelstandort): erste Version 25.0.0, neueste 26.1.0, anfällig bis 26.0.2, behoben in 26.0.3. VIP (Einzelstandort): erste Version 32.0.0, neueste 32.0.8, anfällig bis 32.0.7, behoben in 32.0.8. VIP (Multisite): erste Version 35.0.0, neueste 35.0.7, anfällig bis 35.0.6, behoben in 35.0.7. Um Ihre Website zu überprüfen, finden Sie Ihre Edition und vergleichen Sie Ihre Version mit den anfälligen und gepatchten Spalten.

Dieses Versionierungsschema ist der Grund, warum keine öffentliche Schwachstellen-Datenbank diese Authentifizierungs-Bypasses erfasst hat. Ein typischer Schwachstelleneintrag geht davon aus, dass alle Versionen unter einem Slug in einer Linie aufsteigen. Hier steigen sie in sieben getrennten Bändern. Das einzige öffentliche Advisory betraf die kostenlose Edition, die bei 5.4.5 behoben wurde. Jede kostenpflichtige Installation hat eine höhere Versionsnummer als diese, sodass sie als bereits gepatcht gemeldet wird. Eine Verbreiterung des betroffenen Bereichs hilft auch nicht, da kostenlose Editionen auf 5.4.5 oder höher dann fälschlicherweise als anfällig markiert würden. Die korrekte Lösung besteht darin, sieben disjunkte betroffene Bereiche auf demselben Slug zu erfassen, was der Datenbankeintrag jetzt tut. Das fehlende Stück war die Herstellertabelle, die bis zu diesem Artikel nirgendwo veröffentlicht worden war.

Die Remediation-Geschichte wird noch schlimmer. Wenn Sie die Standard Edition 16.1.9 ausführen, zeigt Ihr WordPress-Admin-Dashboard keine verfügbaren Updates an, obwohl 17.0.6 auf derselben Standard-Linie existiert, für die Sie bereits eine Lizenz haben. Der Upgrade-Pfad von einer anfälligen 16.x zu einer gepatchten 17.x ist ein manueller Plugin-Upload, da der typische WordPress-Update-Mechanismus keinen Sprung zwischen Linien anbietet. DigitalOcean bestätigte beide Fehler auf 16.1.9, einer Standard-Version aus der Mitte dieser Linie, und der Fix ist 17.0.6. Es kommt kein 16.x-Patch.

DigitalOcean fand das Problem durch Defense in Depth. Es gab kein Advisory zu lesen, kein Datenbankeintrag markierte die kostenpflichtige Edition, und das Plugin meldete sich selbst als vollständig aktuell. Ein anomaler WordPress-Administrator-Sitzungsversuch von außerhalb ihres vertrauenswürdigen Netzwerks wurde blockiert. Der Angreifer hatte den Bypass bereits verwendet, um ein WordPress-Admin-Sitzungscookie zu erhalten, aber die Admin-Panel-Operationen selbst blieben hinter dem vertrauenswürdigen Netzwerk eingeschränkt. Von dort aus reproduzierte DigitalOcean den Bypass Ende-zu-Ende auf Version 16.1.9, führte beide Fehler auf ihre Ursachen zurück, bestimmte, welche kostenpflichtigen Versionen betroffen waren, schrieb die Hotfixes und teilte die Analyse zum öffentlichen Nutzen. Scan-Aktivitäten gegen die miniOrange SSO-Endpunkte wurden von den folgenden IP-Adressen beobachtet: 207.211.214.41 (Brüssel, Belgien, VPN/Rechenzentrum), 79.127.224.14 (Brüssel, Belgien, VPN/Rechenzentrum), 102.91.71.83 (Abuja, Nigeria, Mobilfunknetz), 162.243.116.148 (Secaucus, USA, Cloud/VPS), 84.201.6.54 (Frankfurt, Deutschland, Hosting/Rechenzentrum) und 64.225.25.188 (Clifton, USA, Cloud/VPS). Die Verteilung deutet auf opportunistisches Scannen hin, nicht auf eine gezielte Kampagne. Der Angreifer muss nicht wissen, welche Edition Sie ausführen; Sie schon.

Um Ihre WordPress-Website zu schützen, aktualisieren Sie das Plugin mindestens auf die Version in der gepatchten Spalte für Ihre Edition und rechnen Sie damit, dies per manuellem Upload zu tun. Wenn Sie nicht sofort aktualisieren können, bietet DigitalOcean zwei schmale Hotfixes. Für die Algorithmus-Verwechslung fügen Sie unmittelbar nach Zeile 246 in Utilities.php Folgendes hinzu: if ( XMLSecurityKey::HMAC_SHA1 === $MG ) { printf( 'HMAC-SAML-Signaturen werden nicht unterstützt.' ); exit; }. Für das OpenSSL-Drei-Zustands-Problem ersetzen Sie die Rückgabe in includes/lib/SAML2Core/XMLSecurityKey.php:494 durch: return openssl_verify( $ql, $hl, $this->key, $MG ) === 1;. Beide Hotfixes sind bewusst schmal und sollen Zeit überbrücken, nicht den Hersteller-Fix ersetzen. Ein umfassender Fix benötigt eine RSA-Whitelist für Signaturalgorithmen, Entfernung des Public-Key-Umwandlungspfads, eine harte Blockade asymmetrischer Schlüssel in HMAC-Zweigen und Härtung der gebündelten XML-Sicherheitsbibliothek. Überprüfen Sie auch Ihre Protokolle auf authentifizierte Administrator-Sitzungen von IPs außerhalb Ihrer erwarteten Bereiche. Dieses Signal hängt nicht davon ab, dass Sie Ihre Plugin-Version kennen.

Die breitere Lektion ist, dass Schwachstellen-Datenbanken nur so gut sind wie die Versionsdaten, die Hersteller öffentlich veröffentlichen. Wenn ein Hersteller sieben unabhängig nummerierte Editionen unter einem Slug betreibt und sechs davon ohne öffentliches Advisory patcht, wird das gesamte Ökosystem flussabwärts auf einmal blind: Datenbanken, Scanner, Dashboards und die Site-Administratoren, die sich auf alle drei verlassen. Virtuelles Patchen war anders: Eine Firewall-Regel, die das Exploit-Muster blockiert, kümmert sich nicht darum, welche Edition Sie ausführen, sodass der Schutz alle sieben Editionen gleichzeitig abdecken konnte. Genaue Warnungen konnten das nicht; sie funktionieren nur, wenn sie genau wissen, was Sie installiert haben. In diesem Fall skalierte der Schutz gut, aber die Berichterstattung brach. Für Organisationen, die auf WordPress angewiesen sind, kann ein verwalteter Hosting-Dienst wie AEU Hosting eine weitere Ebene hinzufügen, die auf ungewöhnliche Admin-Logins achtet und bekannte Exploit-Muster blockiert, selbst wenn der Update-Feed eines Plugins Sie in die Irre führt.

Die Anerkennung gebührt dem DigitalOcean-Sicherheitsteam für die gesamte ursprüngliche Forschung. Sie erkannten und blockierten die Aktivität gegen ihre eigene Infrastruktur, bestätigten und reproduzierten den Bypass auf Standard Edition 16.1.9, erstellten die vollständige Root-Cause-Analyse für beide CVEs auf den kostenpflichtigen Editionen, identifizierten die behobenen Versionen 17.0.5 und 17.0.6, die der Hersteller ohne öffentlichen Changelog-Eintrag oder Advisory auslieferte, schrieben und validierten die Hotfixes und teilten die Indikatoren für eine Kompromittierung.