CVE-2026-23550: Modular DS-Plugin wird aktiv ausgenutzt – so prüfst du WordPress-Seiten auf Admin-Übernahmen

Wer WordPress in Kundenprojekten betreibt, kennt das Muster: Ein Plugin bringt Komfort, öffnet aber nebenbei einen neuen Angriffsvektor. Beim Plugin Modular DS ist genau das gerade akut – eine Schwachstelle mit maximaler Bewertung (CVE-2026-23550, CVSS 10.0) wird laut Patchstack bereits “in the wild” ausgenutzt, um Administratorzugriff ohne Authentifizierung zu erlangen.

Was ist betroffen – und warum ist das so kritisch?

Die Lücke betrifft alle Modular-DS-Versionen bis einschließlich 2.5.1. Gepatcht wurde sie laut Maintainer in Version 2.5.2. Brisant: Das Plugin soll bei WordPress auf über 40.000 aktiven Installationen laufen – also nicht nur in Nischenprojekten.

Im Kern handelt es sich um eine unauthenticated privilege escalation: Ein Angreifer braucht kein Konto und keine gültige Session, kann aber durch den Exploit letztlich Funktionen erreichen, die bis hin zu einem Admin-Login führen. Das ist in der Praxis oft gleichbedeutend mit Full Takeover: bösartige Änderungen, Malware, Redirects auf Scam-Seiten, neue Admin-User, Persistenz über Plugins oder Backdoors.

Technischer Hintergrund: Routing-Layer, „direct request“ und ein zu großzügiges Trust-Modell

Modular DS legt eigene Endpoints unter dem Prefix /api/modular-connector/ frei. Diese Routen sollten eigentlich durch eine Authentifizierungsbarriere geschützt sein. Laut Patchstack lässt sich diese Schutzschicht jedoch umgehen, sobald ein bestimmter Modus aktiv ist: der „direct request“-Modus (sinngemäß: eine Anfrage wird als interne/vertrauenswürdige Modular-Anfrage behandelt).

Der Bypass funktioniert demnach, indem bei einer Request Parameter gesetzt werden – konkret origin=mo plus ein type-Parameter (Wert beliebig). Dadurch wird die Anfrage als Modular-Direktanfrage klassifiziert, ohne dass eine kryptografische Bindung zwischen der eingehenden Request und dem tatsächlichen Modular-Dienst besteht.

Patchstack nennt mehrere dadurch exponierte Routen, u. a. /login/, /server-information/, /manager/ und /backup/ – also Endpoints, die in vielen Setups sensible Informationen preisgeben oder direkt administrative Aktionen ermöglichen.

Der eigentliche Angriffspfad: Admin-Login über /login/{modular_request}

Der gefährlichste Teil ist laut Beschreibung, dass ein Angreifer den Endpoint /api/modular-connector/login/ bzw. die Route /login/{modular_request} nutzen kann, um am Ende als Administrator eingeloggt zu werden. Patchstack beschreibt das als Kombination aus permissivem Route-Matching, aushebelbarer Authentifizierung und einem Login-Flow, der auf ein Admin-Konto „zurückfällt“.

Aktive Ausnutzung: Was wurde beobachtet?

Patchstack zufolge wurden Angriffe erstmals am 13. Januar 2026 gegen 02:00 UTC beobachtet. Das Muster: HTTP-GET-Requests auf /api/modular-connector/login/, anschließend Versuche, einen neuen Admin-User anzulegen.

Als Ursprung werden in der Meldung u. a. diese IPs genannt:

• 45.11.89[.]19 (VirusTotal: https://www.virustotal.com/gui/ip-address/45.11.89.19)
• 185.196.0[.]11 (VirusTotal: https://www.virustotal.com/gui/ip-address/185.196.0.11)

Sofortmaßnahmen: Patchen, prüfen, aufräumen

Wenn Modular DS bei dir oder in Kundenprojekten im Einsatz ist, ist die wichtigste Maßnahme simpel: Update auf 2.5.2 (oder neuer, falls inzwischen verfügbar). Da die Lücke bereits aktiv ausgenutzt wird, ist das ein klassischer Fall für „jetzt patchen, nicht beim nächsten Wartungsfenster“.

1) Plugin aktualisieren (Minimum: 2.5.2)

Der Hersteller hat das Sicherheitsrelease für Modular Connector 2.5.2 dokumentiert. Falls Updates in deinem Setup verzögert ausgerollt werden (Staging/Release-Train), priorisiere dieses Update wie einen Incident.

2) Auf Kompromittierung prüfen: Admin-User, Logs, Scanner-Spuren

Modular DS empfiehlt, die Seite gezielt auf Auffälligkeiten zu prüfen – insbesondere, weil der beobachtete Angriff nach dem Login-Endpoint direkt auf die Anlage neuer Admin-Konten zielt. Praktisch heißt das:

• WordPress-Userliste auf unerwartete Administratoren prüfen (neue Accounts, unbekannte E-Mail-Domains, kryptische Logins).
• Webserver-Logs nach Requests auf /api/modular-connector/ und speziell /login/ durchsuchen; auffällige Parameterkombinationen (z. B. origin=mo) markieren.
• Auf verdächtige Änderungen achten: neue Plugins, unbekannte Dateien, geänderte wp-config.php, unerwartete Cronjobs.

3) Sessions und Credentials rotieren (wenn Verdacht besteht)

Wenn du Anzeichen einer Übernahme findest, nennt Modular DS drei konkrete Schritte, die in Incident-Playbooks gut funktionieren, weil sie Angreifern den Boden unter den Füßen wegziehen:

1. WordPress Salts neu generieren, um bestehende Sessions zu invalidieren.
2. OAuth-Credentials neu generieren (sofern genutzt), damit abgegriffene Tokens nicht weiter funktionieren.
3. Die Installation auf bösartige Plugins, Dateien oder Code scannen (z. B. per File-Integrity-Checks und manuellem Review verdächtiger Pfade).

Was man daraus mitnehmen sollte (auch unabhängig von Modular DS)

Der Fall ist ein gutes Beispiel dafür, wie gefährlich „implizites Vertrauen“ in interne Request-Pfade werden kann, sobald diese Pfade im öffentlichen Internet landen. Besonders heikel wird es, wenn mehrere Designentscheidungen zusammenspielen: URL-basiertes Route-Matching, ein zu offener „direct request“-Schalter, Authentifizierung basierend auf „Site ist verbunden“ statt auf Request-Signaturen – und am Ende ein Login-Flow, der im Zweifel beim Admin landet.