Was passiert, wenn Entwickler Security nicht ernst nehmen – ein Blick hinter die Kulissen

Wir prüfen regelmäßig die Plugins auf den Websites unserer Kunden – nicht nur auf Updates, sondern auf echte Sicherheitslücken. Was wir dabei manchmal finden, ist… lehrreich.

In diesem Beitrag zeigen wir anhand eines realen Falls (anonymisiert), wie ein kommerzielles WordPress-Plugin mit über 10.000 aktiven Installationen grundlegende Sicherheitsstandards ignoriert. Nicht aus Versehen. Sondern bewusst.

Die Ausgangslage

Ein Divi-Erweiterungsplugin. Kostenpflichtige Pro-Version verfügbar. Professionelle Website, Support-Forum, regelmäßige Updates. Alles sieht seriös aus.

Dann schaut man in den Code.

Fund Nr. 1: Auskommentierte Sicherheitschecks

WordPress hat ein eingebautes System gegen CSRF-Angriffe (Cross-Site Request Forgery): sogenannte Nonces. Ein Nonce ist ein Einmal-Token, das sicherstellt, dass eine Anfrage wirklich von eurer Website kommt – und nicht von einem Angreifer, der euren Browser missbraucht.

Das Plugin erzeugt diese Nonces sogar korrekt und schickt sie an den Browser. Aber dann passiert das hier:

// if (!isset($_POST['nonce']) || !wp_verify_nonce($_POST['nonce'], '...')) {
//     wp_send_json_error([
//         "fuck_nonce" => $_POST['nonce'],
//         "schisser ist" => wp_verify_nonce($_POST['nonce'], '...'),
//     ]);
// }

Ja, ihr lest richtig. Der Entwickler hatte die Sicherheitsprüfung eingebaut, sie hat offenbar nicht auf Anhieb funktioniert – und statt das Problem zu lösen, hat er den gesamten Check auskommentiert. Die Debug-Variablennamen sprechen für sich.

Das betrifft nicht einen Handler. Sondern alle sieben AJAX-Endpunkte des Plugins.

Sieben offene Türen, durch die jeder Angreifer beliebige Daten abfragen kann.

Fund Nr. 2: Keine Berechtigungsprüfung

WordPress kennt das Konzept von Capabilities – Berechtigungen, die festlegen, wer was darf. Ein Redakteur darf Beiträge bearbeiten, ein Abonnent darf nur sein Profil verwalten.

Keiner der sieben AJAX-Handler prüft, ob der anfragende Benutzer überhaupt berechtigt ist. Ergebnis: Jeder eingeloggte Benutzer – auch ein einfacher Abonnent – kann über diese Endpunkte:

• Beliebige Beitragstitel abrufen (auch von Entwürfen und privaten Beiträgen)
• Beitrags-Excerpts auslesen
• Featured Images abfragen
• Post-Meta-Daten lesen (können sensible Informationen enthalten)
• Autoren-Informationen abfragen
• Attachment-URLs enumerieren

Fund Nr. 3: Unsanitisierte Eingaben

WordPress bietet dutzende Funktionen, um Benutzereingaben zu bereinigen. sanitize_text_field(), absint(), esc_url_raw() – für jeden Datentyp die passende Funktion.

In diesem Plugin findet sich stattdessen:

$post_id = $_POST['post_id'];
$result = [
    'title' => get_the_title( $post_id )
];
echo json_encode( $result );

Der Wert aus $_POST wird direkt, ohne jede Prüfung, an eine WordPress-Funktion weitergereicht. Kein absint() für die numerische ID. Kein isset() um zu prüfen, ob der Wert überhaupt existiert. Kein wp_send_json() statt dem manuellen json_encode().

An anderer Stelle:

$format = $_POST['format'];

Ein Datumsformat, direkt aus der POST-Variable, ohne jede Validierung. Zweimal.

Und bei der Galerie-Funktion:

foreach (explode(",", $_POST['images']) as $attachment_id) {
    $images[] = wp_get_attachment_image_src($attachment_id, "full")[0];
}

Eine kommaseparierte Liste von IDs, direkt aus $_POST, ohne Sanitizing, ohne Prüfung ob die Werte überhaupt numerisch sind. Ein Angreifer könnte hier beliebige Werte einschleusen.

Fund Nr. 4: Debug-Modus per CSRF aktivierbar

Das Plugin nutzt ein Lizenz-SDK eines Drittanbieters. Dieses SDK hat eine Funktion, um den Debug-Modus ein- und auszuschalten. Debug-Modus bedeutet: API-Aufrufe, Datenbankabfragen, Lizenzinformationen und Benutzerdaten werden geloggt und sind einsehbar.

Die Toggle-Funktion prüft zwar, ob der Benutzer ein Super-Admin ist – aber sie hat keinen CSRF-Schutz:

static function _toggle_debug_mode() {
    if ( ! is_super_admin() ) {
        return;
    }
    // Kein Nonce-Check!
    $is_on = fs_request_get( 'is_on', false, 'post' );
    update_option( 'fs_debug_mode', $is_on );
}

Ein Angreifer kann eine präparierte Seite erstellen. Wenn ein Super-Admin diese Seite besucht, wird im Hintergrund der Debug-Modus aktiviert – ohne dass der Admin es bemerkt. Danach werden sensible Daten geloggt, die der Angreifer potenziell auslesen kann.

Was bedeutet das konkret?

Stellt euch vor, ihr betreibt einen Mitgliederbereich. Oder einen Online-Shop. Oder eine Website mit unveröffentlichten Entwürfen.

Mit diesem Plugin auf eurer Seite kann jeder eingeloggte Benutzer:

1. Alle eure Beitragstitel durchgehen – auch Entwürfe, die noch nicht veröffentlicht sind
2. Meta-Daten auslesen, die möglicherweise Preise, interne Notizen oder Konfigurationen enthalten
3. Eure Medien-Bibliothek durchforsten

Und das alles, weil der Entwickler zu bequem war, seine eigenen Sicherheitschecks zum Laufen zu bringen.

Die drei CVEs

Für dieses Plugin wurden drei offizielle Sicherheitswarnungen (CVEs) veröffentlicht:

Kein Fix vom Entwickler. Die letzte Version des Plugins enthält alle drei Schwachstellen.

Was wir daraus lernen

1. Bekannter Name bedeutet nicht sicherer Code

Dieses Plugin hat eine professionelle Website, eine Pro-Version, tausende Installationen. Trotzdem ist der Code an entscheidenden Stellen fahrlässig unsicher.

2. „Kommerziell“ heißt nicht „geprüft“

Nur weil ein Plugin Geld kostet oder ein Freemium-Modell hat, wurde es nicht automatisch einem Security-Audit unterzogen. Die WordPress-Plugin-Prüfung deckt nur grundlegende Richtlinien-Verstöße ab – nicht ob der Code sicher ist.

3. Auskommentierter Code ist ein Warnsignal

Wenn ein Entwickler Sicherheitschecks auskommentiert statt sie zu fixen, zeigt das eine Haltung: „Hauptsache es funktioniert.“ Das ist das Gegenteil von dem, was ihr auf eurer Website haben wollt.

4. Updates allein reichen nicht

Dieses Plugin ist „aktuell“ – die neueste Version. Aber aktuell bedeutet nicht sicher. Wenn der Entwickler die Schwachstellen nicht behebt, hilft auch kein Update.

Was ihr tun könnt

• Installiert nur Plugins, die ihr wirklich braucht. Jedes Plugin vergrößert die Angriffsfläche eurer Website.
• Prüft die Bewertungen und den Support. Werden Sicherheitsberichte ernst genommen? Gibt es zeitnahe Reaktionen?
• Nutzt Security-Scanner. Tools wie WPScan, Wordfence oder Patchstack zeigen euch bekannte Schwachstellen in euren Plugins.
• Lasst eure Plugins regelmäßig prüfen. Nicht nur auf Updates – auf echte Schwachstellen.
• Im Zweifel: deaktivieren und deinstallieren. Ein Plugin mit bekannten, ungefixten Schwachstellen hat auf einer produktiven Website nichts zu suchen.

Unser Ansatz

Bei Cord Media prüfen wir die Plugins unserer Kunden proaktiv auf Sicherheitslücken. Wenn ein Entwickler keinen Fix liefert, patchen wir selbst – wie in diesem Fall, wo wir alle drei Schwachstellen geschlossen haben:

• Nonce-Verifizierung für alle AJAX-Handler reaktiviert
• Capability-Checks (current_user_can()) ergänzt
• Alle Benutzereingaben mit den passenden WordPress-Funktionen sanitisiert
• CSRF-Schutz für die Debug-Modus-Umschaltung implementiert
• Fehlenden break in einer switch-Anweisung ergänzt (Fall-through-Bug)

Die gefixte Version steht unseren Mitgliedern im Bereich Security Downloads zur Verfügung.

„Wir haben alle Zeit der Welt, es richtig zu machen – aber keine, um nachzuarbeiten.“

Das gilt auch für die Auswahl eurer Plugins.