WordPress Attack Report: 1,69 Millionen Angriffe, Mai–Juli 2026
Zwischen dem 1. Mai und dem 21. Juli 2026 verzeichnete das ReportedIP-Community Network 1.692.650 Angriffe von 206.388 eindeutigen IP-Adressen – gemessen, nicht geschätzt, durch Honeypot Server und WordPress-Seiten, auf denen das Hive-Sicherheits-Plugin läuft. Dies ist der erste vierteljährliche ReportedIP-WordPress Attack Report; alle nachstehenden Zahlen stammen direkt aus dem Live-Datensatz und dürfen unter der Lizenz CC BY 4.0 frei zitiert werden.
Der Tag mit den meisten Angriffen war der 17. Juni mit 29.217 Angriffen. Brute-Force-Angriffe auf den Login-Bereich waren mit Abstand die häufigste WordPress-spezifische Technik, wobei ein Vorfall besonders hervorstach: die unauthentifizierte RCE-Schwachstelle „wp2shell“ (CVE-2026-63030), für die Hive noch am selben Tag einen virtuellen Patch für alle Tarife bereitstellte.
Wie viele Angriffe gab es, und woher stammen diese Zahlen?
Der Datensatz speist sich aus zwei Quellen. Eine Flotte von acht Honeypot-Servern ahmt Endpoints von WordPress, Drupal und Joomla nach und protokollierte 1.505.488 der Angriffe; produktive WordPress-Websites, auf denen Hive im Community Network-Modus läuft, meldeten die übrigen 186.292 über die Public API. The Reports are aggregated, deduplicated for peaks, weighted by relevance and diversity of reporters, and evaluated with a confidence score ranging from 0 to 100. No personal data from website visitors is collected, and the identity of the reporters is never published – only aggregated numbers leave the network.
- Insgesamt 1.692.650 Angriffe (Einzelreports sowie zu Bursts zusammengefasste Ereignisse)
- 206.388 eindeutige IP-Adressen der Angreifer
- 29.217 Angriffe am Tag mit den meisten Angriffen (17. Juni 2026)
- Im Durchschnitt ~20.600 Angriffe pro Tag über den Zeitraum von 82 Tagen
Ist die Anzahl der Angriffe im Laufe des Quartals gestiegen oder gesunken?
Das Angriffsvolumen blieb hoch und bemerkenswert konstant. Über alle elf vollen Wochen des Betrachtungszeitraums hinweg lag die wöchentliche Anzahl der Angriffe zwischen 133.462 und 179.476, wobei der Höchststand in der Woche vom 15. bis 21. Juni erreicht wurde – derselben Woche, in der auch der Tag mit dem höchsten Angriffsaufkommen am 17. Juni lag. Es gab keine ruhige Phase – automatisierte WordPress-Angriffe stellen eine ständige Hintergrundbelastung dar und sind kein gelegentliches Ereignis.
Was ist das Ziel von Angreifern auf WordPress-Websites?
Der Großteil des Datenverkehrs besteht aus allgemeinen Hacking-Angriffen und Brute-Force-Angriffen auf Anmeldedaten, die auf jede exponierte Anmeldestelle abzielen. Die WordPress-spezifische Aufschlüsselung zeigt jedoch, worauf sich CMS-Betreiber konzentrieren sollten. Brute-Force-Angriffe auf Anmeldedaten wp-login.php übertrifft alles andere bei weitem, und die Erkundung – die User Enumeration sowie das Scannen nach Versionen und Plugins – macht einen großen, oft übersehenen Anteil aus.
| WordPress-Angriffsvektor | Angriffe (Meldungsfenster) |
|---|---|
Brute-Force-Angriff auf den Login (wp-login.php) | 130.856 |
| Missbrauch von XML-RPC | 23.602 |
| Überprüfung von Versionen und Plugins | 23.269 |
| Versuche, Schwachstellen in Plugins auszunutzen | 15.998 |
| User Enumeration | 13.768 |
| Versuche, Schwachstellen im Kern auszunutzen | 6.227 |
Fallstudie: Wie sich der Fall „wp2shell“ entwickelte
Am 19. Juli 2026 wurde die „wp2shell“-Technik bekannt gegeben – eine Kette zur nicht authentifizierten Remote-Codeausführung gegen den WordPress-Kern, die unter der Kennung CVE-2026-63030 erfasst wurde. Sie nutzt die Routenauswertung des REST-Batch-Endpunkts aus, um eine privilegierte Unteranfrage an der Authentifizierung vorbei zu schmuggeln. Unser Sensor für REST-Missbrauch verzeichnete in den Tagen rund um die Bekanntgabe den erwarteten Anstieg an Abfragen des Batch-Endpunkts.
Am selben Tag wurden im Rahmen von ReportedIP Hive 2.1.25 zwei Firewall Rules veröffentlicht — waf_rest_batch_desync und waf_rest_batch_nested –, die die „Route-Confusion“-Primitive auf der WAF-Ebene blockieren. Beide sind Teil der kostenlosen „Paranoia Level-1“-Baseline, die in jedem Tarif – einschließlich des kostenlosen Tarifs – im Lieferumfang des Plugins enthalten ist. Eine Website ist geschützt, sobald sie auf Version 2.1.25 aktualisiert wird, ohne dass ein Abonnement für Rule Sync erforderlich ist (Version 2.1.25, 19. Juli). Die Regeln passen sich der strukturellen Form der fehlerhaften Anfrage an, anstatt auf eine feste Payload-Zeichenkette abzugleichen, sodass gängige Umgehungsversuche (zusätzliche Schrägstriche, protokollrelative oder absolute URLs) nicht durchschlüpfen – ein Verhalten, das durch Regressionstests in der Testsuite des Plugins gesichert ist. Websites mit Version 2.1.25 oder höher waren unabhängig davon, wann sie den WordPress-Core-Patch angewendet hatten, vor dieser Angriffsklasse geschützt.
Wo Hive PRO noch einen Schritt weiter geht
Die Basisversion, die „wp2shell“ blockiert hat, ist Free. Die PRO-Version bietet zusätzliche Tiefe und Geschwindigkeit in der Post-Exploitation-Phase. Auf eine RCE wie wp2shell folgt in der Regel das Hochladen einer Webshell, um Persistenz herzustellen; Hive PRO liefert die erweiterten PL2-Firewall-Signaturen – einschließlich der Regelgruppe für Webshells und missbräuchliche Uploads – über eine tägliche, mit Ed25519 signierte Rule Sync. Kostenlose Installationen erhalten neue Regeln im Rahmen von Plugin-Veröffentlichungen; PRO-Installationen erhalten diese unmittelbar nach ihrer Veröffentlichung, was das Zeitfenster verkürzt, in dem eine Technik aktiv als Angriffswerkzeug genutzt wird.
Wie die Daten erhoben wurden
Alle Zahlen stammen aus der reportedip_ip_reports Tabelle für den Zeitraum vom 1. Mai bis zum 21. Juli 2026 und berücksichtigen einzelne Meldungen sowie deren Burst-Aggregationsmultiplikator. Die Zahlen zu den Threat Categories basieren auf den 30 Threat Categories der Plattform. Honeypot- und Hive-Reports werden bei der Erfassung anonymisiert: Standardmäßig werden keine User-Agents der Website-Besucher sowie keine IP-Adressen oder Identitäten der Meldenden in den veröffentlichten Zahlen angegeben. Die aus diesen Daten abgeleitete Community Blacklist listet eine IP-Adresse erst ab einer Konfidenz von 75 % oder höher auf, nach einer 48-stündigen Karenzzeit.
Verwenden Sie diese Zahlen
Alle Abbildungen und Diagramme in diesem Bericht stehen unter der Lizenz CC BY 4.0 – Sie dürfen sie in Artikeln, Fachbeiträgen oder Vorträgen wiederverwenden, sofern Sie als Quelle einen Link zu reportedIP.com angeben. Für einen individuellen Zeitrahmen, eine Aufschlüsselung nach Ländern, Rohdaten oder ein Zitat wenden Sie sich bitte an Patrick Schlesinger unter 1@reportedIP.com. Die vollständige Methodik sowie das Berichtsarchiv finden Sie auf der Seite „Threat Reports“.
Was dies für WordPress-Betreiber bedeutet
- Gehen Sie von einer konstanten Auslastung aus. Es gibt kein Zeitfenster mit geringem Datenverkehr – automatisierte Angriffe lagen während des gesamten Quartals bei über 133.000 pro Woche.
- Führen Sie eine Rate Limitation für den Login und XML-RPC ein. Diese beiden Bereiche machen den Großteil der WordPress-spezifischen Zugriffsversuche aus und lassen sich problemlos drosseln.
- Virtual-Patching ist schneller als Core-Patching. Das wp2shell-Fenster verdeutlicht die Lücke zwischen der Bekanntgabe einer Sicherheitslücke und der Behebung – eine WAF schließt diese Lücke. Installieren Sie Hive; die Firewall-Baseline ist Free.
- Verwenden Sie die aktuellen Versionen. Die Regeln, die wp2shell gestoppt haben, sind erst ab Version 2.1.25 vorhanden; die tägliche Rule Sync von PRO sorgt dafür, dass diese Schutzmaßnahmen stets auf dem neuesten Stand bleiben. Vergleichen Sie die Tarife.
Der nächste „ReportedIP WordPress Attack Report“ umfasst das dritte Quartal 2026. Jede Hive-Installation und jeder Honeypot trägt zur Verbesserung des Datensatzes bei – installieren Sie das Plugin oder betreiben Sie einen Honeypot, um einen Beitrag zu leisten.