Gehacktes WordPress bereinigen: Malware entfernen, Backups und Absicherung

Mehr zum WordPress-Sicherheitsaudit von WPPoland.

Dieser Leitfaden führt Schritt für Schritt durch die Bereinigung einer infizierten WordPress-Instanz. Er arbeitet mit Kommandozeilenwerkzeugen (SSH, WP-CLI), weil sie schneller und gründlicher sind als jedes Plugin. Scanner in Plugin-Form kommen weiter unten vor, im Abschnitt über die Dokumentation von WordPress.org.

#Woran man erkennt, dass WordPress gehackt wurde

Bevor Sie mit der Bereinigung beginnen, bestätigen Sie, dass die Website wirklich kompromittiert ist. Die häufigsten Anzeichen:

• Unerwünschte Weiterleitungen: Besucher landen auf Spam-, Pharma- oder Casino-Seiten
• Eingeschleuster Spam-Inhalt: Seiten mit japanischem oder chinesischem Text oder Links zu schädlichen Websites
• Unbekannte Administratorkonten: Neue Admin-Konten, die Sie nicht angelegt haben
• Kürzlich geänderte Dateien: Core-, Theme- oder Plugin-Dateien, die ohne Ihr Wissen verändert wurden
• Warnungen von Google: ein Warnhinweis in den Suchergebnissen oder eine Warnseite im Browser vor dem Aufruf
• Einbruch beim SEO-Traffic: Google hat die Website abgewertet oder aus dem Index genommen
• Versand von Spam-Mails: Ihr Server verschickt unerwünschte E-Mails
• Schlechtere Performance: Die Website ist spürbar langsamer geworden

Wenn das erste Anzeichen japanische Seiten in Google waren und nicht etwas Sichtbares auf der Website, handelt es sich wahrscheinlich um die getarnte Variante, die einen anderen ersten Schritt verlangt. Lesen Sie dazu den japanischen Keyword-Hack, bevor Sie etwas löschen.

#Wie Angreifer in eine WordPress-Website eindringen

Automatisierte Bots scannen das Web ununterbrochen nach bekannten Schwachstellen, führen Brute-Force-Angriffe auf Administrator-Zugangsdaten durch und nutzen Fehlkonfigurationen von Servern aus. Um ein System nachhaltig zu bereinigen, muss zuerst verstanden werden, wie der Angreifer Zugriff erhalten hat.

#Sicherheitslücken in veralteten Plugins und Themes

Schwachstellen wie SQL-Injection (SQLi), Local File Inclusion (LFI) und Remote Code Execution (RCE) treten häufig in veralteten Plugins auf. Angreifer suchen mit automatisierten Werkzeugen nach bekannten verwundbaren Versionen und führen ihre Payloads aus. Zwei Klassen von Schwachstellen sind besonders gefährlich:

• PHP Object Injection (Deserialisierung): Tritt auf, wenn ungeprüfte Benutzereingaben direkt an die PHP-Funktion unserialize() übergeben werden. Enthält der Code Hilfsklassen, die als “POP chain” dienen können, kann der Angreifer beliebige PHP-Objekte instanziieren, Code ausführen und Dateien ins Dateisystem schreiben.
• Unbeschränkter Datei-Upload: Prüft ein Plugin hochgeladene Dateien aus eigenen Formularen nicht richtig (zum Beispiel nur die Dateiendung im Browser und nicht auf dem Server), kann der Angreifer eine als Bild getarnte Webshell hochladen, in /wp-content/uploads/ ablegen und per direkter HTTP-Anfrage ausführen.

#Schwache Passwörter und Brute-Force-Angriffe

Bots attackieren /wp-login.php und /xmlrpc.php ohne Pause mit Listen gängiger Passwörter. Nutzt das Administratorkonto ein schwaches Passwort, wird es früher oder später kompromittiert.

#Wie Angreifer xmlrpc.php missbrauchen

Die Altlast xmlrpc.php erlaubt die Kommunikation mit der WordPress-API über XML. Weil sie gebündelte Methodenaufrufe (Multicall) unterstützt, kann ein Angreifer mit einer einzigen HTTP-Anfrage hunderte Kombinationen von Zugangsdaten durchprobieren und die üblichen Login-Limits umgehen.

#Infektion über andere Websites auf Shared Hosting

Läuft Ihre Website auf einem Shared-Hosting-Server, kann eine Schwachstelle auf der Website eines Nachbarn ausreichen, damit der Angreifer Dateien im Verzeichnisbaum schreibt und Ihre sauberen Dateien infiziert.

#Was WordPress.org nach einem Hack als Erstes empfiehlt

Der Support-Artikel von WordPress.org FAQ My site was hacked behandelt die erste Stunde als Dokumentationsarbeit, nicht als Bereinigung. Der erste konkrete Schritt ist, festzuhalten, was Sie sehen, wann es Ihnen aufgefallen ist (mit Zeitzone) und was sich zuletzt geändert hat: ein neues Plugin, eine Theme-Anpassung, eine Änderung an einem Widget. Diese Notiz ist die Grundlage des Vorfallberichts, egal ob Sie die Website selbst bereinigen oder an jemand anderen übergeben.

Derselbe Artikel nennt Indikatoren, die auf einen echten Hack hindeuten und nicht auf einen Ausfall: Die Website steht auf einer Blacklist von Google oder Bing, der Hoster hat sie deaktiviert, sie ist als Malware-Verteiler markiert, das Antivirenprogramm der Besucher blockiert sie, jemand meldet, dass sie andere Websites angreift, oder es tauchen Benutzer auf, die niemand angelegt hat.

Für das Scannen kombiniert der Artikel Scanner auf Anwendungsebene (die Plugins Wordfence, Sucuri, Quttera und GOTMLS) mit externen Scannern wie VirusTotal und Sucuri SiteCheck, weil jeder Typ andere Dinge meldet.

Vier Punkte aus diesem Artikel gehen unter Druck leicht verloren:

• Scannen Sie auch Ihren eigenen Rechner. Der Artikel weist darauf hin, dass viele Infektionen auf dem Gerät des Betreibers beginnen, wo ein Trojaner die Zugangsdaten für FTP und wp-admin abgreift. Neue Passwörter, die auf einem infizierten Laptop eingegeben werden, landen direkt beim Angreifer.
• Sprechen Sie früh mit dem Hoster. Auf Shared Hosting kann der Hack mehr als eine Website betreffen, und eine Website, die Spam verschickt, kann die IP des Servers auf Mail-Blacklists bringen, was den E-Mail-Versand vom selben Server beeinträchtigt.
• Installieren Sie dieselbe Version neu, und nicht über wp-admin. Der Artikel rät von den Neuinstallationsoptionen im Dashboard ab, weil diese Installer oft nur vorhandene Dateien überschreiben, während Hacks neue Dateien hinzufügen. Er nennt /wp-admin und /wp-includes als Verzeichnisse, die sich gefahrlos ersetzen lassen.
• Ändern Sie die Passwörter zweimal. Einmal bei der Entdeckung des Hacks und noch einmal, wenn die Website als sauber bestätigt ist, und zwar an allen Zugangspunkten: SFTP, wp-admin, Hosting-Panel und MySQL. Der Artikel empfiehlt außerdem, Benutzername und Passwort der Datenbank zu ändern und wp-config.php entsprechend anzupassen.

Er nennt auch die Dateien, die unabhängig von der Art der Infektion eine manuelle Prüfung verdienen, weil eine Änderung an ihnen jede Anfrage betrifft: .htaccess (im Stammverzeichnis und in jedem Unterverzeichnis, das eine hat), index.php sowie die Theme-Dateien header.php, footer.php und functions.php.

#Wie man ein gehacktes WordPress während der Bereinigung vom Netz nimmt

Googles Leitfaden Quarantine your site empfiehlt, die gehackte Website vom Netz zu nehmen, damit sie Nutzern keine Inhalte mehr ausliefert, und mit dem Statuscode 503 zu antworten, der einen vorübergehenden Ausfall signalisiert. Für WordPress zählen zwei Details:

• Liefern Sie den 503 von außerhalb des kompromittierten Verzeichnisbaums aus, zum Beispiel über die Konfiguration des Webservers oder des Proxys, den der Hoster kontrolliert. Ein Wartungs-Plugin oder eine PHP-Datei innerhalb der infizierten Installation läuft neben der Malware.
• Eine 4xx- oder 5xx-Antwort allein reicht nicht, denn “auch mit diesen Statuscodes können weiterhin schädliche Inhalte an Nutzer ausgeliefert werden” (Google, Quarantine your site, eigene Übersetzung). Ein disallow in der robots.txt reicht ebenfalls nicht: Es sperrt nur Suchmaschinen-Crawler, nicht die Besucher.

Laut dem Leitfaden wird es das künftige Ranking kaum beeinträchtigen, die Website während der Wiederherstellung vorübergehend vom Netz zu nehmen. Seine beiden anderen Schritte decken sich mit WordPress.org: den Hoster informieren, die Benutzerliste prüfen, vom Angreifer angelegte Konten löschen und alle Passwörter ändern (FTP, Datenbank, Systemadministrator und CMS).

Bringen Sie die Website wieder online, bevor Sie bei Google eine Überprüfung beantragen, denn die Überprüfung braucht Seiten, die der Googlebot crawlen kann.

#Wie man ein Backup eines gehackten WordPress erstellt

Vor jeder Änderung muss der Ist-Zustand vollständig archiviert werden. Das ist aus zwei Gründen entscheidend: (1) Wenn bei der Bereinigung etwas schiefgeht, können Sie wiederherstellen, und (2) Sie können die Malware später analysieren, um zu verstehen, wie es zum Einbruch kam.

# Dateisystem sichern
tar -czf /tmp/compromised-files-$(date +%Y%m%d).tar.gz -C /var/www/html .

# Datenbank exportieren
wp db export /tmp/compromised-db-$(date +%Y%m%d).sql --path=/var/www/html

#Wie man WordPress-Zugriffslogs per SSH auswertet

Um den Einstiegspunkt und den Zeitpunkt des Hacks zu finden, werten Sie die Access-Logs des Webservers mit SSH-Befehlen aus. So finden Sie schädliche POST-Anfragen, die zu den Änderungsdaten der Dateien passen.

# IP-Adressen mit auffällig vielen POST-Anfragen an Login- oder XML-RPC-Endpunkte
grep -h "POST /wp-login.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20
grep -h "POST /xmlrpc.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20

# Suche nach typischen Angriffsmustern in den Logs
grep -E "wp-config\.php|\.env|eval\(|union\+select" /var/log/nginx/access.log

# Anfragen einer verdächtigen IP-Adresse während des Angriffsfensters filtern
grep "192.168.1.100" /var/log/nginx/access.log | grep -E "POST|PUT"

Wer die Quell-IP und das genaue Skript kennt, das die Anfrage verarbeitet hat, erkennt das ausgenutzte Plugin oder Theme und kann die Schwachstelle beheben.

#Wie man Malware in einem gehackten WordPress findet

#Wie man verdächtige PHP-Dateien findet

Suchen Sie mit grep und find nach typischen Malware-Mustern und modifizierten Dateien:

# Typische Verschleierungsfunktionen durchsuchen
grep -rn "eval(" /var/www/html/wp-content/ --include="*.php"
grep -rn "base64_decode" /var/www/html/wp-content/ --include="*.php"
grep -rn "str_rot13" /var/www/html/wp-content/ --include="*.php"
grep -rn "gzinflate" /var/www/html/wp-content/ --include="*.php"

# PHP-Dateien im Uploads-Ordner aufspüren (dort dürfen keine existieren)
find /var/www/html/wp-content/uploads/ -type f -name "*.php"

# In den letzten 7 Tagen geänderte PHP-Dateien auflisten
find /var/www/html/ -type f -name "*.php" -mtime -7

#Wie man Administratoren in der Datenbank prüft

-- Verdächtige Administratoren anzeigen
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE ID IN (
    SELECT user_id FROM wp_usermeta
    WHERE meta_key = 'wp_capabilities'
    AND meta_value LIKE '%administrator%'
);

#Die häufigsten Arten von WordPress-Hacks 2026

#Wie man den WordPress-Core nach einem Hack ersetzt

Verlassen Sie sich bei Kerndateien nicht auf Virenscanner. Am sichersten ist es, alle Systemdateien durch saubere Originalversionen zu ersetzen, ohne den Inhaltsordner wp-content/ anzutasten:

# Core-Dateien neu herunterladen und überschreiben, wp-content bleibt unberührt
wp core download --force --skip-content --path=/var/www/html

# Integrität anhand offizieller Prüfsummen verifizieren
wp core verify-checksums --path=/var/www/html

Das ersetzt wp-admin/, wp-includes/ und alle Core-Dateien im Stammverzeichnis durch die Originalversionen und entfernt so schädliche Änderungen an diesen Dateien.

#Wie man wp core verify-checksums und die Plugin-Prüfung liest

wp core verify-checksums lädt von WordPress.org die md5-Prüfsummen der installierten Version herunter und vergleicht sie mit den Dateien auf der Festplatte. Laut der Befehlsreferenz geschieht das, ohne WordPress zu laden. Das ist wichtig auf einer Website, auf der das Laden von WordPress die Malware ausführt.

Ein sauberer Core endet mit Success: WordPress installation verifies against checksums. Jede veränderte Datei erzeugt eine Zeile wie Warning: File doesn't verify against checksum: wp-includes/version.php, und der Lauf endet mit Error: WordPress installation doesn't verify against checksums.

Nützliche Optionen nach einem Hack:

• --include-root prüft zusätzlich das Stammverzeichnis und warnt vor Elementen, die nicht zu WordPress gehören. Genau dort tauchen Loader auf, die neben wp-load.php abgelegt wurden.
• --version=<version> und --locale=<locale> vergleichen mit einer bestimmten Version und Sprache.
• --format=json liefert eine maschinenlesbare Ausgabe für ein Skript oder ein Ticket zum Vorfall.
• --insecure wiederholt den Download ohne Zertifikatsprüfung. Die Referenz warnt, dass die Anfrage damit für einen Man-in-the-Middle-Angriff anfällig wird, also nutzen Sie es nicht auf einem kompromittierten Server.

wp core download --force überschreibt laut der Referenz zum Download nur vorhandene Dateien. Dateien, die der Angreifer in wp-admin/ oder wp-includes/ hinzugefügt hat, können überleben. Die sicherere Reihenfolge: Diese beiden Verzeichnisse löschen, die laut WordPress.org-FAQ gefahrlos ersetzt werden können, dann herunterladen und prüfen.

Für Plugins prüft wp plugin verify-checksums --all die Dateien gegen die Prüfsummen von WordPress.org, und --strict lässt auch “weiche Änderungen” wie Bearbeitungen an readme.txt fehlschlagen (Referenz). Da die Prüfsummen von WordPress.org stammen, deckt der Befehl die Plugins aus dem WordPress.org-Verzeichnis ab. Premium- und Eigenentwicklungen brauchen ein frisches Paket vom Anbieter oder aus Ihrem eigenen Repository.

wp core verify-checksums --include-root --path=/var/www/html
wp plugin verify-checksums --all --strict --path=/var/www/html

#Wie man wp-content in einem infizierten WordPress bereinigt

#Wie man Plugins nach einem Hack neu installiert

Am sichersten ist es, alle Plugins zu löschen und neu zu installieren, damit keine versteckten Backdoors zurückbleiben:

# Aktive Plugins auflisten
wp plugin list --status=active --path=/var/www/html

# Jedes Plugin aus dem Repository neu installieren
wp plugin install plugin-name --force --path=/var/www/html

Bei kommerziellen Erweiterungen löschen Sie die Ordner vollständig und laden unberührte ZIP-Pakete direkt beim ursprünglichen Anbieter herunter.

#Was nach einem Hack mit den Themes zu tun ist

Löschen Sie alle Themes außer dem aktiven. Vergleichen Sie beim aktiven Theme die Dateien Zeile für Zeile mit der Originalversion.

#Wie man PHP-Dateien aus dem Uploads-Ordner entfernt

Der Uploads-Ordner darf NIEMALS PHP-Dateien enthalten. Löschen Sie alle, die Sie finden:

find /var/www/html/wp-content/uploads/ -name "*.php" -delete
find /var/www/html/wp-content/uploads/ -name "*.phtml" -delete
# .htaccess nur auflisten und prüfen, nicht löschen: WooCommerce schützt woocommerce_uploads/ mit einer eigenen .htaccess
find /var/www/html/wp-content/uploads/ -name ".htaccess"

#Wie man die Datenbank eines gehackten WordPress bereinigt

Angreifer hinterlegen oft eigene Administratorkonten, Weiterleitungsskripte und SEO-Spam direkt in den Datenbanktabellen.

#Wie man falsche Administratoren löscht

-- Verdächtige Benutzer entfernen (IDs vorher verifizieren)
DELETE FROM wp_users WHERE ID IN (liste_verdaechtiger_ids);
DELETE FROM wp_usermeta WHERE user_id IN (liste_verdaechtiger_ids);

#Wie man eingeschleuste Skripte in wp_posts und wp_options findet

Typische Angriffe wie der Japanese Keyword Hack schreiben tausende Spam-Links direkt in Beitragsfelder:

-- Nach eingeschleusten Skripten in Beiträgen suchen
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
OR post_content LIKE '%eval(%';

-- Verdächtige Optionen suchen
SELECT option_name, option_value
FROM wp_options
WHERE option_name LIKE '%hack%'
OR option_name LIKE '%inject%'
OR option_value LIKE '%base64_decode%';

#Wie man Backdoors im Cron und in der WordPress-Konfiguration entfernt

Malware richtet häufig Cron-Aufgaben ein, die gereinigte Dateien erneut infizieren. Deshalb kann sich eine Website innerhalb weniger Stunden wieder infizieren, selbst wenn alle Systemdateien ersetzt wurden.

#Wie man WordPress-Cronjobs prüft

Alle geplanten Aufgaben liegen als serialisierte Arrays in der Tabelle wp_options, in der Option cron. Mit diesem WP-CLI-Befehl sehen Sie die geplanten Events:

# Alle geplanten Cron-Events auflisten
wp cron event list --path=/var/www/html

#Wie man ein schädliches Cron-Event mit PHP löscht

Finden Sie einen unbekannten Cron-Hook (zum Beispiel wp_update_system_cache, der auf dynamischen Code zeigt), entfernt ihn dieses PHP-Skript:

declare(strict_types=1);

namespace WPPoland\Security\Cron;

/**
 * Entfernt schädliche Cron-Hooks aus dem Zeitplan.
 */
function remove_malicious_cron_event(): void {
    $target_hook = 'wp_update_system_cache';

    // Hook entfernen, falls er geplant ist
    $timestamp = wp_next_scheduled( $target_hook );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, $target_hook );
        error_log( sprintf( 'Security Action: Unscheduled backdoor hook "%s".', $target_hook ) );
    }
}
add_action( 'init', __NAMESPACE__ . '\\remove_malicious_cron_event' );

#Wie man Backdoors in .user.ini und .htaccess findet

Ein häufiger Persistenzmechanismus ist das Einschleusen von .user.ini- oder .htaccess-Dateien in das Stammverzeichnis. Der Angreifer setzt PHP-Direktiven wie auto_prepend_file, um ein Schadskript auszuführen, bevor irgendein WordPress-Code geladen wird:

; Schädliche .user.ini Direktive
auto_prepend_file = "/var/www/html/wp-content/uploads/2026/06/backdoor.jpg"

Weil diese Datei global wirkt, führt jede PHP-Anfrage die Backdoor aus, auch der Login-Bildschirm. Prüfen Sie .user.ini und .htaccess im Stammverzeichnis auf Änderungen und stellen Sie sicher, dass kein unautorisiertes Skript vorangestellt oder angehängt wird.

#Wie man WordPress nach einer Malware-Bereinigung absichert

Nach der Bereinigung müssen restriktive Sicherheitsmaßnahmen etabliert werden:

#Wie man Admin-Passwort und Salt-Keys ändert

# Administrator-Passwort ändern
wp user update admin --user_pass="neues-sicheres-passwort" --path=/var/www/html

# Salt-Keys erneuern (beendet alle aktiven Sitzungen)
wp config shuffle-salts --path=/var/www/html

Durch das Rotieren der Salt-Keys werden alle bestehenden Sitzungen und Login-Cookies sofort ungültig.

#Welche Schutzmaßnahmen in wp-config.php gehören

// Integrierten Theme- und Plugin-Editor deaktivieren
define( 'DISALLOW_FILE_EDIT', true );

// Plugin- und Theme-Installationen über das Backend sperren
define( 'DISALLOW_FILE_MODS', true );

// HTTPS für den Adminbereich erzwingen
define( 'FORCE_SSL_ADMIN', true );

#Welche Dateirechte WordPress braucht

# Verzeichnisse auf 755 setzen
find /var/www/html/ -type d -exec chmod 755 {} \;

# Dateien auf 644 setzen
find /var/www/html/ -type f -exec chmod 644 {} \;

# wp-config.php: 400 (nur lesbar)
chmod 400 /var/www/html/wp-config.php

#Wem die WordPress-Dateien gehören sollten

Neben den Rechten zählt der Dateibesitz. Der Webserver-Prozess (zum Beispiel www-data oder apache) sollte nicht Eigentümer der WordPress-PHP-Dateien sein. Setzen Sie einen separaten Deployment-Benutzer (zum Beispiel wp-user) als Eigentümer und www-data als Gruppe. So kann ein kompromittierter Webserver-Prozess die .php-Systemdateien weder schreiben noch verändern:

# Eigentümer: Deployment-Benutzer, Gruppe: Webserver
chown -R wp-user:www-data /var/www/html/

# Schreibzugriff für den Webserver nur im Uploads-Ordner
chown -R www-data:www-data /var/www/html/wp-content/uploads/

#Schreibgeschütztes Dateisystem für WordPress in Docker

Die offizielle Dokumentation des Images (docker-library/docs) beschreibt ein statisches Deployment: ein eigenes Image mit dem Code in /usr/src/wordpress bauen und es schreibgeschützt ausführen, mit beschreibbarem Speicher nur für /tmp, /run und optional wp-content/uploads. Standardmäßig legt das Image WordPress in einem beschreibbaren Volume /var/www/html ab und aktualisiert es dort, daher bringt read_only: true auf dem Standard-Image diesen Schutz nicht.

FROM wordpress:apache
WORKDIR /usr/src/wordpress
RUN set -eux; \
	find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e "s!/var/www/html!$PWD!g" -e "s!Directory /var/www/!Directory $PWD!g" '{}' +; \
	cp -s wp-config-docker.php wp-config.php
COPY custom-theme/ ./wp-content/themes/custom-theme/
COPY custom-plugin/ ./wp-content/plugins/custom-plugin/

# docker-compose.yml: eigenes Image, schreibgeschützt
services:
  wordpress:
    image: custom-wordpress:tag
    read_only: true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - ./uploads:/usr/src/wordpress/wp-content/uploads

Ist die Code-Schicht versiegelt, erreicht eine Lücke, die das Schreiben von Dateien erlaubt, nur noch das Uploads-Volume. Deshalb bleiben die Uploads-Prüfungen aus diesem Leitfaden nötig. Aktualisieren heißt, das Image neu zu bauen und neu auszurollen, und die Dokumentation erinnert daran, das regelmäßig zu tun, um die Sicherheitsupdates von WordPress zu erhalten.

#Was der WordPress-Hardening-Leitfaden nach einer Bereinigung ergänzt

Der Leitfaden Hardening WordPress setzt wp-config.php auf 400 oder 440, damit nur Sie und der Webserver die Datei lesen können. Zu DISALLOW_FILE_EDIT heißt es, die Einstellung “verhindert nicht, dass ein Angreifer schädliche Dateien auf Ihre Website hochlädt, kann aber einige Angriffe stoppen” (WordPress.org, Hardening WordPress, eigene Übersetzung). Für den Datenbankbenutzer genügen im Normalbetrieb Lese- und Schreibrechte, der Leitfaden rät aber davon ab, strukturelle Rechte wie ALTER zu entziehen, weil manche Updates und Plugins das Schema ändern. Zur Überwachung empfiehlt er, die Dateikontrolle als root auszuführen, damit der Angreifer sie nicht einfach abschalten kann, nur ausführbare Dateitypen wie .php zu beobachten, um das Rauschen zu senken, und regelmäßige Kopien aufzubewahren, sodass Versionen von vor und nach einer Kompromittierung vorliegen.

#Wie man prüft, ob die WordPress-Malware entfernt ist

#Checkliste nach der Malware-Entfernung

• WordPress-Core mit Prüfsummen verifiziert
• Alle Plugins aus sauberen Quellen neu installiert
• PHP-Dateien aus uploads entfernt
• Falsche Administratorkonten gelöscht
• Passwörter aller Benutzer geändert
• Salt-Keys erneuert
• Dateirechte korrigiert
• DISALLOW_FILE_EDIT aktiviert
• XML-RPC deaktiviert, falls nicht benötigt
• Sicherheits-Plugin installiert (Wordfence, Sucuri)
• Automatische Backups eingerichtet

#Wie Google eine gehackte Website meldet und wie lange die Prüfung dauert

Googles Befunde erscheinen in der Search Console im Bericht zu Sicherheitsproblemen (Search-Console-Hilfe). Betroffene Seiten können einen Warnhinweis in den Suchergebnissen oder eine Warnseite im Browser zeigen. Der Bericht nutzt vier Hack-Kategorien:

Dieselbe Seite legt drei Regeln fest. Beheben Sie das Problem auf der gesamten Website, denn eine Korrektur einzelner Seiten bringt die Website nicht teilweise in die Suchergebnisse zurück. Klicken Sie auf Request Review erst, wenn alle Probleme aus dem Bericht auf allen Seiten behoben sind. Reichen Sie keinen neuen Antrag ein, solange ein anderer offen ist. Ein guter Antrag erklärt das genaue Problem, beschreibt die Schritte zur Behebung und dokumentiert das Ergebnis.

Googles Leitfaden Request a review nennt die Voraussetzungen: bestätigte Inhaberschaft in der Search Console, eine saubere Website, eine behobene Schwachstelle und eine wieder erreichbare Website, damit der Googlebot sie crawlen kann. Prüfen Sie vorher mit cURL oder Wget die Startseite und eine URL, die der Angreifer verändert hat. Ein Antrag, der gestellt wird, während das Problem fortbesteht, verlängert die Zeit, in der die Website markiert bleibt.

Hält Google die Website für sauber, werden die Warnungen in Browser und Suche innerhalb von 72 Stunden entfernt. Andernfalls kann der Bericht weitere Beispiel-URLs zeigen, und die Warnungen bleiben bestehen. Google ist nicht die einzige Liste: Die WordPress.org-FAQ empfiehlt, die Website auch bei Bing Webmaster Tools, Yandex Webmaster und Norton Safe Web zu registrieren, weil Besucher jede dieser Listen nutzen können.

Google hat am 20. Oktober 2026 angekündigt, dass Chrome die Safe-Browsing-Warnungen vor Websites in zwei Stufen zeigt, sofern der erweiterte Schutz aktiviert ist: verdächtige Websites (Einstufung mit geringerer Sicherheit, mögliches Risiko für Nutzer) und gefährliche Websites (Einstufung mit hoher Sicherheit, hohes Risiko für Nutzer) (Google, 20. Oktober 2026). Gefährliche Websites bekommen weiterhin die rote Warnseite über den ganzen Bildschirm. Die Warnung vor verdächtigen Websites unterscheidet sich in Format, Symbol, Farbe und Text und erscheint, wenn eine Seite täuschende Muster zeigt, die häufig mit bekannten schädlichen Websites verbunden sind.

#Wie man verhindert, dass WordPress erneut gehackt wird

Die beste Verteidigung ist Vorbeugung:

• Immer aktualisieren: Core, Plugins und Themes, nach Möglichkeit automatisch
• Starke Passwörter: mindestens 16 Zeichen, für jedes Konto eigene
• 2FA einführen: Zwei-Faktor-Authentifizierung für alle Admin-Konten
• Sicheres Hosting: VPS mit Firewall statt Shared Hosting
• Tägliche Backups: automatisiert und extern gespeichert
• Laufende Überwachung: Alarme bei Dateiänderungen und verdächtigen Aktivitäten

#Wie ein 90-Tage-Sicherheitsplan für WordPress aussieht

• Tage 1 bis 30 (Sofortmaßnahmen): vollständige Integritätsprüfung der Dateien per WP-CLI, um veränderte Core-Dateien zu finden. Rotieren Sie die Datenbankpasswörter, die Root-Zugangsdaten der Datenbank und die SSH- und SFTP-Schlüssel. Erneuern Sie die Salts in wp-config.php, um aktive Sitzungen zu beenden, und sperren Sie die direkte Bearbeitung von Themes und Plugins mit DISALLOW_FILE_EDIT.
• Tage 31 bis 60 (Forensik und WAF): Prüfen Sie die aktiven Cron-Aufgaben, um sicherzustellen, dass keine schädliche Funktion mehr geplant ist. Werten Sie die Webserver-Logs auf auffälliges Verhalten, POST-Spitzen auf XML-RPC oder LFI-Muster aus. Richten Sie eine Web Application Firewall (WAF) auf dem Server oder einen Reverse Proxy (zum Beispiel Cloudflare) ein, um SQLi- und XSS-Payloads am Rand des Netzes zu blockieren.
• Tage 61 bis 90 (Härtung und Audits): Richten Sie automatische externe Backups in einem WORM-Speicher ein (einmal schreiben, mehrfach lesen). Führen Sie statische Codeanalysen und Penetrationstests für eigene Themes und individuelle Plugins durch. Planen Sie quartalsweise Sicherheitsscans und legen Sie ein Protokoll zur Reaktion auf Vorfälle für das Team fest.

Lernen Sie unser WordPress-Sicherheitsaudit und die WordPress-Wartung kennen, um Ihre Website professionell zu schützen, oder nehmen Sie direkt Kontakt mit uns auf.