Beschreibung

Modern Events Calendar Lite registriert eine Familie von nicht authentifizierten admin-ajax.php "Load More"- Aktionen für seine Event-List-Skins (list, grid, masonry, agenda, timeline, tile, custom). Jeder Handler liest das vom Angreifer kontrollierte atts-Request-Array, übergibt es an eine Helper-Funktion namens sanitize_deep_array() — die bei Aufruf mit ihren Standardargumenten überhaupt keine Sanitisierung durchführt — und verkettet dann die Werte von atts['include'] (und atts['exclude']) roh in einen SQL-post_id IN (...)-Fragment, das mit $wpdb->get_results() ausgeführt wird und kein $wpdb->prepare() verwendet.

Da die Einstiegspunkte auf wp_ajax_nopriv_* registriert sind, ist keine Authentifizierung, kein Konto, kein Nonce oder Benutzerinteraktion erforderlich. Ein nicht authentifizierter entfernter Angreifer kann beliebiges SQL in die WHERE-Klausel eines SELECT gegen wp_mec_dates injizieren und beliebige Daten in der WordPress-Datenbank (Benutzer-Passwort-Hashes, wp_options-Geheimnisse/Schlüssel, Daten anderer Plugins) mittels blinder zeitbasierter / boolescher / fehlerbasierter Techniken auslesen.

Ursache

1. Ein "Sanitizer", der auf dem Standardpfad nichts sanitisiert

app/libraries/main.php:9607:

Die Guard-Bedingung (is_array($excludes) and !count($excludes)) macht die Funktion zu einer vollständigen No-Op, wenn $excludes das leere Standard-Array ist — jeder Wert wird wörtlich kopiert. Die Absicht war offensichtlich "wenn es eine Ausschlussliste gibt, überspringe diese Schlüssel"; die boolesche Logik überspringt stattdessen alles, wenn keine Ausschlussliste angegeben wird.

2. Der Aufrufer liefert kein $excludes

app/skins/list.php:499-501 (load_more()):

sanitize_deep_array($_REQUEST['atts']) wird mit einem einzigen Argument aufgerufen → $excludes standardmäßig auf array() → der No-Op-Zweig oben → $atts ist das rohe, nicht vertrauenswürdige $_REQUEST['atts'].

3. Rohverkettung in die IN (...)-Klausel

app/libraries/skins.php:

Die Array-Elemente werden direkt in den SQL-String implode()d, ohne Integer-Cast und ohne Escape. (absint()/(int) bei jedem Element hätte dies verhindert.)

4. Ausführung ohne Prepared Statement

app/libraries/db.php:79:

Der vollständig aufgebaute String wird $wpdb->get_results() wörtlich übergeben.

Taint-Fluss (Request → Senke):

Erreichbarkeit

app/skins/list.php:51-52:

Die nopriv-Registrierung macht den Endpunkt vor der Authentifizierung erreichbar. Dasselbe load_more()-Schema und der gemeinsame Query-Builder aus skins.php sind in den Geschwister-Skins vorhanden, jeder mit seiner eigenen wp_ajax_nopriv_*-Aktion, sodass dieselbe Injektion über jeden der folgenden Punkte erreichbar ist:

In load_more() wird kein Nonce geprüft, und die Aktion erfordert kein Plugin-Shortcode auf einer Seite — die AJAX-Handler werden bedingungslos bei init registriert.

Proof of Concept (lab-verifiziert, MEC Lite 6.5.6, WordPress 6.6.5, MariaDB 10.x)

Alle Requests sind nicht authentifiziert (kein Cookie, kein Nonce). Der injizierte Wert wird in atts[include][] platziert; das Payload schließt die beiden offenen Klammern der IN ((...) AND (... IN (-Gruppe und hängt ein top-level OR <sleep> an, sodass die Bedingung für jede gescannte Zeile ausgewertet wird, und kommentiert dann den nachfolgenden )) ORDER BY ...-Teil aus:

Die genaue ausgeführte Abfrage (aufgezeichnet aus WP_DEBUG_LOG) für einen Fehler-Canary atts[include][]=0)MEC_SQLI_CANARY war:

— das Literal-Token MEC_SQLI_CANARY erscheint wörtlich in der ausgeführten Anweisung, was die rohe Verkettung bestätigt. Der Parameter atts[exclude][] (skins.php:803 / 603, NOT IN) ist identisch injizierbar (lab-bestätigt: atts[exclude][]=0)) OR SLEEP(3)# → ~3.5s). Die identische Abfrage und Injektion wurden auf 7.33.0 (aktueller Build) reproduziert — gleicher Canary, gleiches SLEEP-Verhalten.

Automatisierter PoC

mec-unauth-sqli-poc.py (enthalten) ist vollständig in sich geschlossen und erfordert keine Anmeldedaten: es bestätigt die Injektion (Baseline vs. SLEEP) und führt dann eine zeitbasierte blinde Extraktion beliebiger Daten durch (Standard: @@version, DB-Benutzer und das erste Admin-user_login:user_pass). Es validiert jede Antwort (HTTP 200) und taktet Requests mit --delay + Back-off, um WAF/Rate-Limiting zu überleben (z. B. mod_evasive). Es werden keine Daten modifiziert (nur lesender SELECT-Kontext).

Auswirkungen

Nicht authentifizierter, netzwerkerreichbarer, vollständiger Lese-Zugriff auf die Datenbank: wp_users-Passwort- Hashes, wp_options (auth_key, API-Geheimnisse, Token) und jede andere Tabelle. In der Praxis führt dies zur vollständigen Site-Übernahme (Offline-Hash-Knacken, Geheimnis-/Sitzungsdiebstahl). Die Auswirkung auf die Integrität ist begrenzt — die Injektion wird in einem SELECT über $wpdb->get_results() ausgeführt, das keine gestapelten Abfragen erlaubt — daher I:N. Schwere SLEEP/BENCHMARKs könnten die Verfügbarkeit beeinträchtigen, aber die primäre, zuverlässig demonstrierte Auswirkung ist die Vertraulichkeit (C:H), was zu CVSS 7.5 führt.

Betroffene Dateien

Zeilennummern gelten für 7.33.0 (aktuell) mit 6.5.6 in Klammern; der Code ist im gesamten Bereich identisch.

Die Geschwister-Skins (grid, masonry, agenda, timeline, tile, custom) teilen sich das gleiche load_more() + skins.php-Query-Builder und registrieren jeweils eine wp_ajax_nopriv_*-Aktion → gleicher Fehler, mehrere Einstiegspunkte.

Abgrenzung zu früheren Modern Events Calendar SQL-Injection CVEs

Dies ist ein eigenständiger, zuvor nicht gemeldeter Injektionspunkt. Jede öffentlich dokumentierte MEC SQL- Injection zielt auf eine andere AJAX-Aktion und einen anderen Parameter ab, und alle wurden in Versionen gepatcht, die dieser Fund nach sich zieht (er ist lab-bestätigt live in 7.33.0):

• Anderer Codepfad. Die früheren nicht authentifizierten Probleme befinden sich im Single-Event-Handler mec_load_single_page; dieses hier befindet sich in der Skin-"Load More"-Paginierung (load_more() → MEC_skin::initialize() → app/libraries/skins.php post_id IN (...)-Builder), erreicht durch den No-Op-Standardzweig von sanitize_deep_array(). Die Patches für mec_load_single_page berühren skins.php nicht.
• Keine Konfigurationsvorbedingung. CVE-2021-4458 (id) war nur ausnutzbar, wenn das PHP/WordPress- Input-Slashing deaktiviert war (ein nicht standardmäßiger Zustand), weil dieser Wert in einem zitierten Kontext steht. Hier landen die Werte atts[include]/atts[exclude] in einem unzitierten numerischen IN(...)-Kontext und werden mit Klammern + SQL-Schlüsselwörtern (0)) OR SLEEP(3)#) ausgenutzt, die wp_magic_quotes() nicht neutralisiert. Daher ist es auf einer Standard-WordPress-Installation ausnutzbar — lab-bestätigt auf Stock WP 7.0 (magic quotes an).
• Überlebt alle vorherigen Fixes. Bestätigt funktionierend auf 7.33.0 — vier Jahre und eine Hauptversion nach dem letzten mec_load_single_page-Patch (6.4.0).

Offenlegung / Hinweis zum Umfang

Modern Events Calendar Lite wurde am 2022-05-11 von wordpress.org entfernt ("Grund: Richtlinienverstoß"), daher ist der wordpress.org-Build bei 6.5.6 eingefroren. Dies bedeutet nicht, dass das Plugin aufgegeben wurde — Webnus hat die Entwicklung außerhalb der Plattform fortgesetzt: Der aktuelle Lite-Build, der von mec.webnus.net verteilt wird, ist 7.33.0, und der anfällige Codepfad ist dort byte-for-byte derselbe (lab-bestätigt; die SQLi feuert identisch auf 7.33.0). Der Fehler betrifft daher jede Version im gesamten Nach-Entfernungs-Bereich, nicht nur die eingefrorene wordpress.org-Kopie.

Auswirkungen auf die Routinen (der Einwand "closed on wordpress.org" ist viel schwächer als es zunächst scheint):

• Es ist ein aktuelles, vom Anbieter verteiltes, unterstütztes Produkt, kein verlassener Code — eine koordinierte Offenlegung gegenüber Webnus ist der primäre Kanal; sie liefern aktiv Updates und sollten patchen.
• MEC Pro (aktiv verkauft; aktuell 7.x) basiert auf derselben 7.x-Codebasis. app/libraries/skins.php, app/libraries/main.php und app/libraries/db.php sind gemeinsam genutzte Kernbibliotheken, daher ist Pro mit hoher Wahrscheinlichkeit betroffen. Dies sollte gegen Pro-Quellcode bestätigt werden, bevor es formal behauptet wird, aber die gemeinsam genutzte Bibliotheksarchitektur macht es sehr wahrscheinlich. Ein bestätigter Pro-Einfluss macht den Befund eindeutig im Rahmen für Patchstack (eine öffentlich verkaufte Komponente) und einen MITRE/Patchstack-CVE wert, unabhängig vom Status der wordpress.org-Listung.
• Für Konsumenten, die speziell auf die wordpress.org-Listung achten (einige Wordfence-Bounty-Kriterien; Patchstacks "Closed Component"-Ausschluss wie auf den Lite-Free-Build angewendet), verweisen Sie auf die vom Anbieter verteilte 7.33.0 + Pro-Auswirkung anstatt auf den eingefrorenen 6.5.6.

Ein CVE ist aufgrund der Verdienste gerechtfertigt: nicht authentifizierte, netzwerkerreichbare, vollständige DB-Lese-SQL-Injection in einem aktuellen, vom Anbieter verteilten Produkt mit einer historischen sechsstelligen Installationsbasis.

Zeitplan