Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
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
Tools/GitHubGitHub/dungsocool/cve-2025-7384
SchwachstellenanalyseExploitationWebanwendungs-ExploitationLernen & BildungLabs & Praxis
GitHubdungsocool/cve-2025-7384

CVE-2025-7384

Exploit-PoC und Root-Cause-Analyse für eine kritische, nicht authentifizierte PHP-Objektinjektion in WordPress Database for Contact Form 7, die über beliebiges Löschen von Dateien zu RCE führt.

Repository anzeigen
12vor 2 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-2025-7384 — PHP-Objektinjektion zu RCE

Plugin: Database for Contact Form 7 (contact-form-entries) ≤ 1.4.3
CVSS: 9.8 (Kritisch)
CWE: CWE-502 — Deserialisierung nicht vertrauenswürdiger Daten
Authentifizierungsanforderung: Keine (nicht authentifiziert)
Auswirkung: Remote Code Execution


Inhaltsverzeichnis

  1. Überblick über die Schwachstelle
  2. Verwandte Konzepte
  3. Ursachenanalyse (Quellcode + Debug)
  4. Angriffskette
  5. Schritt-für-Schritt-Reproduktion (POC)
  6. Auswirkungsanalyse
  7. Abhilfemaßnahmen

1. Überblick über die Schwachstelle

Das Plugin „Database for Contact Form 7" (Slug: contact-form-entries) in Version 1.4.3 und früher enthält eine Schwachstelle zur PHP-Objektinjektion. Wenn ein WordPress-Administrator einen Formulardatensatz (Eintrag) im Admin-Panel anzeigt, ruft das Plugin die Funktion maybe_unserialize() direkt mit Daten auf, die ein nicht authentifizierter Benutzer über Contact Form 7 übermittelt hat, ohne die Liste der zulässigen zu instanziierenden Klassen zu kontrollieren.

Ein Angreifer muss sich nicht anmelden — er muss lediglich ein normales Kontaktformular absenden und dabei ein serialisiertes PHP-Objekt in ein beliebiges Formularfeld einfügen. Diese Daten werden unverändert in der Datenbank gespeichert. Wenn ein Administrator den Eintrag zur Ansicht öffnet, instanziiert die Deserialisierungsfunktion ein Objekt nach Wahl des Angreifers und löst damit Magische Methoden wie __destruct() oder __wakeup() aus → abhängig von den im WordPress-Umfeld verfügbaren POP-Gadgets wird beliebiges Verhalten ausgeführt.

Schweregrad: Mit einem geeigneten POP-Gadget (zum Beispiel einer Klasse, deren __destruct()-Methode unlink() aufruft), kann ein Angreifer die Datei wp-config.php löschen, wodurch WordPress zum anfänglichen Installationsbildschirm zurückkehrt → Neuinstallation mit einem vom Angreifer kontrollierten Administrator-Konto → Installation eines Plugins mit Webshell → vollständige Remote Code Execution (RCE) auf dem Server.

AttributWert
CVE IDCVE-2025-7384
CVSS-Score9.8 (Kritisch)
CWECWE-502 — Deserialisierung nicht vertrauenswürdiger Daten
Betroffenes Plugincontact-form-entries (Database for Contact Form 7) ≤ 1.4.3
AuthentifizierungsanforderungKeine — jeder, der ein CF7-Formular absendet, kann ein Payload injizieren
AuslösebedingungAdministrator betrachtet den injizierten Eintrag im Admin-Panel
Maximale AuswirkungNicht authentifizierte Remote Code Execution
Behobene Version1.4.4+ (ersetzt unserialize durch json_decode bzw. allowed_classes: false)

2. Verwandte Konzepte

PHP-Serialisierung / -Deserialisierung

PHP verwendet serialize(), um ein Objekt in einen strukturierten Textstring zu konvertieren, und unserialize(), um das Objekt aus diesem String wiederherzustellen. Wenn unserialize() Daten aus einer nicht vertrauenswürdigen Quelle (z. B. Benutzereingaben) erhält, kann ein Angreifer ein beliebiges Objekt konstruieren, das zu einer Klasse gehört, die zu diesem Zeitpunkt im PHP-Speicher geladen ist.

Magische Methoden in PHP

Besondere Methoden, die PHP automatisch während des Lebenszyklus eines Objekts aufruft. Am wichtigsten in diesem Zusammenhang:

  • __wakeup() — wird sofort aufgerufen, wenn ein Objekt deserialisiert wird
  • __destruct() — wird aufgerufen, wenn ein Objekt zerstört wird (den Gültigkeitsbereich verlässt oder die Anfrage endet)
  • __toString() — wird aufgerufen, wenn ein Objekt in einen String umgewandelt wird

POP-Kette (Property-Oriented Programming)

Eine Technik, bei der mehrere Magische Methoden aus vorhandenen Klassen innerhalb der Anwendung zu einer gefährlichen Abfolge von Verhaltensweisen verkettet werden. Der Angreifer schreibt keinen neuen Code — er manipuliert lediglich die Eigenschaften vorhandener Objekte, sodass bei der Ausführung der Magischen Methoden Aktionen durchgeführt werden, die von den Entwicklern nicht beabsichtigt waren.

maybe_unserialize() in WordPress

Eine Wrapper-Funktion des WordPress-Kerns. Sie ruft is_serialized() auf, um zu prüfen, ob ein String serialisierte Daten enthält — falls ja, ruft sie unserialize() auf, um das Objekt wiederherzustellen. Problem: Diese Funktion übergibt den Parameter allowed_classes (verfügbar seit PHP 7.0) nicht, um einzuschränken, welche Klassen instanziiert werden dürfen.


3. Ursachenanalyse — Schwachstellenentdeckung aus dem Quellcode

Schritt 1: Sink-Punkte finden (Sink-Hunting)

Durchsuchen Sie den gesamten Plugin-Quellcode per grep, um Deserialisierungsfunktionen zu lokalisieren — diese gehören zu den gefährlichsten Funktionen in PHP, da sie zu Objektinjektion führen können:

grep -rn "unserialize" wp-src/wp-content/plugins/contact-form-entries/

image.png

Die Ausgabe zeigt mehrere Aufrufstellen für maybe_unserialize(), insbesondere in includes/data.php Zeile 545 innerhalb der Funktion verify_val():

image 1.png

// data.php lines 538-548
public function verify_val($string){
    if(in_array(substr(ltrim($string),0,1), array('{','['))
       && in_array(substr(rtrim($string),-1), array('}',']'))
    ){
        $val = json_decode($string, 1);
        if(is_array($val)){ $string = $val; }
    } else if(is_serialized($string)){            // line 544
        $string = maybe_unserialize($string);     // ★ line 545 — SINK
    }
    return $string;
}

Kernfrage: Woher stammt die Variable $string? Wenn sie ohne Filterung aus Benutzereingaben stammt → handelt es sich um eine Schwachstelle.

Schritt 2: Rückverfolgung — Woher kommen die Daten?

Finden Sie heraus, wo verify_val() aufgerufen wird. Verfolgen Sie die Aufrufe in derselben Datei data.php rückwärts:

image 2.png

// data.php lines 520-535
public function get_lead_detail($lead_id){
    global $wpdb;
    $table = $wpdb->prefix . 'vxcf_leads_detail';
    $detail_arr = $wpdb->get_results(
        $wpdb->prepare("SELECT * FROM $table WHERE lead_id=%d", $lead_id),
        ARRAY_A
    );

    foreach($detail_arr as $k => $v){
        if(!empty($v['value'])){
            $detail_arr[$k]['value'] = $this->verify_val($v['value']);  // ← calls verify_val
        }
    }
    return $detail_arr;
}

→ $string ist exakt $v['value'] — Werte, die aus der Datenbanktabelle wp_vxcf_leads_detail abgerufen werden. Diese Funktion wird aufgerufen, wenn ein Administrator die Details eines Formulareintrags anzeigt.

Nächste Frage: Woher stammen die Daten in wp_vxcf_leads_detail? Wer schreibt sie?

Schritt 3: Schreibpunkte der Daten finden (Source)

Aus Schritt 2 wissen wir, dass Daten aus der Datenbank gelesen werden. Nächste Frage: Wer schreibt Daten hinein? Suchen Sie nach INSERT-Abfragen in data.php:

grep -rn "insert" wp-src/wp-content/plugins/contact-form-entries/includes/data.php

image 3.png

Öffnen Sie den Code der Funktion create_lead() (Zeilen 85–103) für Details:

image 4.png

Tool herunterladen