CVE-2026-4020: Gravity SMTP-Lücke – 17 Mio. Angriffe auf WordPress-Sites

Gravity SMTP, scheinbar harmlos, verwaltet in Zehntausenden WordPress-Installationen SMTP-Passwörter, API-Keys und OAuth-Tokens. Seit Ende Mai 2026 zapfen Angreifer diese Schatzkiste systematisch an – unauthentifiziert, automatisiert, in industriellem Maßstab. Wordfence hat bereits über 17 Millionen geblockte Exploit-Versuche gezählt. Wer jetzt noch Version 2.1.4 oder älter betreibt, hat ein Problem.

Was steckt hinter CVE-2026-4020?

Gravity SMTP ist das E-Mail-Plugin des RocketGenius-Ökosystems, besser bekannt als das Team hinter Gravity Forms. Das Plugin übernimmt die SMTP-Konfiguration, verbindet WordPress-Installationen mit externen Mail-Diensten und speichert dabei genau das, was man unter keinen Umständen öffentlich haben möchte: Zugangsdaten, API-Keys, OAuth-Tokens. Rund 100.000 aktive Installationen, laut Wordfence-Daten und diversen Sicherheitsanalysen.

Die WordPress-Sicherheitslücke CVE-2026-4020 sitzt in einer REST-API-Route, die eigentlich für Testzwecke gedacht war. Konkret: der Endpoint /wp-json/gravitysmtp/v1/tests/mock-data. Das Pikante daran – der permission_callback dieses Endpoints gibt schlicht immer true zurück. Keine Authentifizierung, keine Überprüfung, keine Zugriffskontrolle. Jeder, der die URL kennt, bekommt Einlass.

Mit dem zusätzlichen Parameter ?page=gravitysmtp-settings generiert das Plugin über seine register_connector_data()-Funktion einen vollständigen System Report – rund 365 Kilobyte JSON, prall gefüllt mit Systemdaten. Was genau drin steckt, dazu gleich mehr. Die öffentliche Offenlegung und CVE-Vergabe datiert auf den 31. März 2026. Erste Exploits in freier Wildbahn wurden laut CrowdSec ab dem 27. Mai 2026 dokumentiert.

Was Angreifer aus diesem Informationsleck herausholen

Ein CVSS-Score von 5,3 klingt nach einem überschaubaren Mittelfeldproblem. Plot Twist: Die praktische Gefährlichkeit dieser WordPress-Sicherheitslücke liegt weit jenseits dieser Zahl. wp-firewall.com bewertet die Schwachstelle sogar mit 7,5, also als High-Severity. Diese Diskrepanz hat einen simplen Grund: CVSS-Scores messen die technische Eigenschaft der Lücke, nicht ihren operativen Wert für Angreifer.

Und der operative Wert des Gravity SMTP-Informationslecks ist beachtlich. Aus dem System Report lassen sich abrufen: PHP-Version und geladene Extensions, Webserver-Version inklusive Document-Root-Pfad, Datenbanktyp und -version, Tabellennamen, WordPress-Version, alle aktiven Plugins mit jeweiliger Versionsnummer, das aktive Theme – und, der eigentliche Jackpot: SMTP-Credentials, konfigurierte API-Keys sowie OAuth-Tokens.

Für Angreifer ist das kein Selbstzweck. Es ist Reconnaissance auf Knopfdruck. Wer weiß, welche Plugin-Versionen auf einer Site laufen, weiß auch, welche davon bekannte Exploits haben. Wer SMTP-Passwörter kennt, kann im Namen der Domain E-Mails versenden. Wer OAuth-Tokens hat, kann unter Umständen direkt auf verbundene Mail-Konten zugreifen. Aus einem „mittelschweren“ Informationsleck wird so eine Eintrittskarte für Kettenangriffe, Account-Takeovers und E-Mail-Impersonation.

17 Millionen Angriffsversuche – die Automatisierungsmaschinerie läuft

Zahlen aus dem Wordfence-Netzwerk sprechen eine deutliche Sprache: über 17 Millionen geblockte Exploit-Versuche gegen diese eine Schwachstelle, Stand Ende Mai / Anfang Juni 2026. Das ist kein gezielter Angriff mehr, das ist industrieller Betrieb.

CrowdSec dokumentierte bis zum 1. Juni 2026 mindestens 412 eindeutige angreifende IP-Adressen und bezeichnete die Aktivität als „Background Noise“ – also automatisierte Breitband-Scans, die zum normalen Internet-Rauschen übergegangen sind. Wenig überraschend: Sobald ein Exploit-Code öffentlich und zuverlässig reproduzierbar ist, dauert es keine zwei Wochen, bis die Botnetze ihn übernehmen. Hier waren es laut CrowdSec gerade einmal wenige Tage zwischen erster Sichtung und Massenbetrieb.

Das bedeutet konkret: Wer eine ungepatchte Gravity SMTP-Installation betreibt, ist nicht mehr die Ausnahme in einem gezielten Angriffsszenario, sondern Teil des täglichen Massenscans. Die Frage ist nicht ob jemand versucht, den Endpoint abzurufen, sondern wie oft er es bereits getan hat.

Das Angriffsszenario im Detail

Skizzieren wir einen realistischen Angriffsablauf. Ein automatisierter Scanner pingt systematisch WordPress-Installationen an – erkennbar durch typische Pfad-Strukturen im Header oder im wp-json-Verzeichnis. Trifft er auf Gravity SMTP ≤ 2.1.4, sendet er einen einfachen GET-Request an den Mock-Data-Endpoint. Keine Anmeldung, kein Token, kein Aufwand.

Der System Report kommt zurück. Der Scanner parst die JSON-Antwort, extrahiert SMTP-Credentials und API-Keys, gleicht Plugin-Versionen gegen eine Datenbank bekannter Schwachstellen ab – und legt ein Profil der Site an. SMTP-Zugangsdaten landen in einem Pool für Spam-Kampagnen oder Phishing. OAuth-Tokens werden gegen Mail-Provider-APIs getestet. Die Kombination aus bekannter WordPress-Version und Plugin-Liste ermöglicht gezielte Folgeangriffe über andere Schwachstellen, die in der Liste auftauchen.

Der eigentliche RCE, also die direkte Übernahme der Site, passiert über CVE-2026-4020 nicht. Aber das ist fast nebensächlich, wenn der Angreifer bereits die Zugangsdaten zur Mail-Infrastruktur hat. Cyberangriffe auf Authentifizierungssysteme folgen exakt diesem Muster: Credential-Diebstahl als Stufe eins, Eskalation als Stufe zwei. Der Clou bei dieser Schwachstelle: Stufe eins kostet genau einen HTTP-Request.

Warum das Patch-Timing so relevant ist

CVE-2026-4020 wurde am 31. März 2026 öffentlich. Die CrowdSec-Signaturen folgten am 22. Mai 2026. Erste wilde Exploits: 27. Mai 2026. Wordfence beobachtet seit Anfang Mai 2026 massenhafte Angriffe. Das ergibt ein Zeitfenster von knapp zwei Monaten zwischen Offenlegung und Massenbetrieb – im Maßstab heutiger Exploit-Entwicklung ist das schon großzügig. Wer dieses Fenster nicht genutzt hat, sitzt jetzt im Regen.

Gravity SMTP 2.1.5 ist die erste gepatchte Version und schließt die Lücke. Alle Versionen bis einschließlich 2.1.4 sind verwundbar. Die NVD-Einträge bestätigen diese Versionsgrenze eindeutig. Ein Plugin-Update über das WordPress-Backend – einige Klicks, Minuten, erledigt. Dass dieses Update nach zwei Monaten noch nicht flächendeckend ausgerollt ist, sagt einiges über den Zustand des Plugin-Managements in vielen WordPress-Installationen aus.

Ich sage das ohne Häme: WordPress-Wartung ist in kleinen Betrieben, Agenturen mit Dutzenden Kunden-Sites und Selbstverwalteten oft das, was zwischen zwei dringenden Projekten fällt. Aber genau das wissen Angreifer – und sie richten ihre Automatisierung danach aus.

Sofortmaßnahmen – was jetzt zu tun ist

Schritt eins ist trivial und unausweichlich: Update auf Gravity SMTP 2.1.5 oder eine neuere Version, sofern zwischenzeitlich erschienen. Wer das Plugin gerade nicht aktiv nutzt, aber installiert hat – deaktivieren stoppt weitere Leaks, ersetzt aber das Update nicht und schon gar nicht die Credential-Rotation.

Schritt zwei ist der, den viele vergessen: Webserver-Logs prüfen. Speziell nach GET-Requests auf /wp-json/gravitysmtp/v1/tests/mock-data, mit oder ohne Parameter ?page=gravitysmtp-settings. War der Endpoint in den letzten Wochen erreichbar und wurde er abgerufen? Dann sind die gespeicherten Zugangsdaten als kompromittiert zu betrachten – unabhängig davon, ob man einen konkreten Missbrauch beobachtet hat oder nicht.

Schritt drei, und das ist nicht optional: alle im Plugin konfigurierten SMTP-Passwörter, API-Keys und OAuth-Tokens rotieren. Beim Mail-Anbieter, beim API-Dienst, bei jedem verbundenen Drittanbieter. Tokens sind ab dem Moment wertlos, in dem sie dem Angreifer bekannt sind – aber gefährlich, solange sie noch gültig sind. Wer hier zögert, schiebt das eigentliche Risiko nur nach hinten.

Darüber hinaus empfiehlt sich, die Liste der aktiven Plugins auf bekannte Schwachstellen zu prüfen – denn genau diese Liste war Teil des geleakten System Reports. Angreifer wissen jetzt, was auf der Site läuft. Das ist keine Paranoia, das ist die logische Konsequenz aus dem, was der Endpoint ausgeliefert hat. Browser-Exploit-Ketten und Plugin-basierte Angriffsvektoren folgen oft genau dieser Reconnaissance-Logik: erst kartieren, dann angreifen.

Wie Agenturen und Managed-Hosting-Anbieter reagieren sollten

Für Einzelbetreiber mit einer Handvoll Sites ist das Update überschaubar. Die eigentliche Herausforderung liegt bei Agenturen, Freelancern und Hosting-Anbietern, die Dutzende oder Hunderte WordPress-Installationen verwalten. Hier zeigt CVE-2026-4020 ein strukturelles Problem: Ohne zentralisiertes Plugin-Monitoring und automatisiertes Update-Management ist flächendeckende Reaktionsfähigkeit schlicht nicht gegeben.

Wer noch kein Inventory seiner WordPress-Installationen mit aktiven Plugin-Versionen pflegt, sollte das jetzt als Anlass nehmen. Tools wie ManageWP, MainWP oder vergleichbare Verwaltungsplattformen ermöglichen es, Plugin-Versionen zentral abzufragen und Updates gebündelt auszurollen. Das ist kein Luxus für Großbetriebe – das ist die Mindestvoraussetzung, um auf Schwachstellen wie diese innerhalb des verfügbaren Zeitfensters reagieren zu können.

Darüber hinaus lohnt es sich, für alle verwalteten Sites eine automatische Benachrichtigung bei neuen CVE-Einträgen für installierte Plugins einzurichten. Dienste wie WPScan oder Patchstack bieten genau das – eine kontinuierliche Überwachung des Plugin-Ökosystems gegen bekannte Schwachstellendatenbanken. Wer auf solche Benachrichtigungen verzichtet, erfährt von einer Lücke wie CVE-2026-4020 im besten Fall über Medienberichte, im schlechtesten Fall erst nach einem Vorfall.

Ein weiterer Aspekt, den Agenturen gegenüber ihren Kunden kommunizieren sollten: Die Angriffsfläche durch schlecht gewartete Plugins ist strukturell vergleichbar mit anderen Infrastruktur-Schwachstellen, die durch verzögerte Updates entstehen – der Unterschied ist nur, dass WordPress-Plugins seltener im Radar von IT-Sicherheitsverantwortlichen auftauchen als Serverkomponenten.

Was dieser Fall über REST-API-Sicherheit in WordPress lehrt

CVE-2026-4020 ist kein Einzelfall, sondern ein Symptom eines wiederkehrenden Musters in der WordPress-Plugin-Entwicklung. REST-API-Endpunkte, die zu Testzwecken oder für Debug-Funktionen angelegt werden, landen häufig ohne ausreichende Zugangskontrolle in Produktivsystemen – weil sie während der Entwicklung praktisch sind und weil das Thema Authentifizierung dort als zweitrangig behandelt wird.

Das WordPress-REST-API-Framework macht es Entwicklern leicht, Endpunkte zu registrieren. Es macht es aber genauso leicht, den permission_callback mit einem schlichten __return_true oder einer immer wahren Bedingung zu versehen – und das wird in der Praxis zu selten im Code-Review hinterfragt. Gravity SMTP ist hier kein Ausreißer, sondern eines von mehreren Plugins, bei denen genau dieser Fehler aufgetaucht ist.

Für WordPress-Entwickler, die eigene Plugins oder Themes mit REST-Endpoints bauen, ist die Lektion direkt: Jeder Endpoint braucht einen expliziten, restriktiven permission_callback. Testzweck-Endpoints gehören nicht in den Produktionscode oder müssen hinter einer Administratorprüfung liegen. Und jede Funktion, die Systemkonfigurationsdaten oder Credentials aggregiert, sollte grundsätzlich als hochsensibel behandelt werden – unabhängig davon, ob sie offiziell exponiert ist oder nur intern genutzt werden soll.

Diese Designentscheidungen zu Beginn eines Projekts zu treffen kostet wenig Zeit. Sie nachträglich zu korrigieren, wenn bereits Exploits im Umlauf sind, kostet Reputation, Vertrauen und im schlimmsten Fall Kundendaten.

Das Awareness-Problem: Wenn Medium gefährlicher ist als Critical

Es gibt eine bittere Ironie in der Welt der Schwachstellenbewertungen. Ein CVSS-Score von 5,3 löst in den meisten Patch-Management-Prozessen keinen Alarm aus. „Critical“ und „High“ werden priorisiert, „Medium“ wandert in die Backlog-Liste, die sich niemand wirklich ansieht. CVE-2026-4020 demonstriert einmal mehr, warum diese Priorisierung an der realen Bedrohungslage vorbeigeht.

Das Informationsleck liefert keine direkte Code-Ausführung. Es schreibt keine Dateien, es legt keine Backdoors an. Es liest nur. Aber was es liest – SMTP-Credentials, API-Tokens, vollständige Systemkonfiguration, Plugin-Fingerprint –, ist in den Händen eines strukturierten Angreifers mehr wert als so mancher RCE-Bug in einem wenig genutzten System. Sicherheitsexperten bei Wordfence und anderen Stellen betonen deshalb den praktischen Schweregrad, auch wenn die formale CVSS-Bewertung ambivalent bleibt.

Das cPanel-Schwachstellenumfeld oder Browser-Exploit-Ketten zeigen dasselbe Muster: Es sind selten die spektakulären Zero-Days, die in der Praxis den größten Schaden anrichten. Es sind die stillen, gut automatisierbaren Informationslecks, die unbemerkt bleiben, weil ihre formale Klassifizierung keine roten Lampen auslöst. Wer WordPress betreibt und Plugin-Updates nach CVSS-Score priorisiert, riskiert, genau diese Lücken zu verpassen.

Was bleibt

Gravity SMTP ist kein Exot. Es ist ein Plugin, das in professionellen WordPress-Setups routinemäßig eingesetzt wird, weil es die Mail-Integration vereinfacht. Genau dieser Verbreitungsgrad macht CVE-2026-4020 so relevant: 100.000 potenziell betroffene Installationen, ein unauthentifizierter Endpoint, ein 365-Kilobyte-JSON mit allem, was ein Angreifer für den nächsten Schritt braucht.

Meine Einschätzung: Die eigentliche Gefahr liegt nicht in der Schwachstelle selbst, sondern in der Erwartung, dass ein mittlerer CVSS-Score bedeutet, man habe Zeit. Bei einem Plugin, das Zugangsdaten zu Mail-Infrastrukturen hält, gibt es diese Zeit nicht. 17 Millionen Exploit-Versuche in wenigen Wochen belegen das ziemlich eindeutig.

Die Frage, die WordPress-Betreiber jetzt beantworten sollten: Wann haben Sie zuletzt überprüft, ob Ihre Logs Zugriffe auf Endpoints zeigen, die Sie nie selbst aufgerufen haben – und ob die Antwort darauf etwas enthielt, das eigentlich niemand hätte lesen dürfen?