Joomla-Malware entfernen: Schadcode erkennen, Hintertüren löschen und die Website absichern

Warum reicht das Löschen der gemeldeten Dateien bei Joomla nicht aus?

Wenn Google vor Ihrer Website warnt, Besucher weitergeleitet werden oder der Hoster schädliche Dateien meldet, kann Schadcode auf dem Server stecken. Das bloße Löschen einer gemeldeten Datei beseitigt nur ein Symptom, während versteckte Hintertüren im System bleiben. Um Joomla-Malware entfernen zu können, sichern Sie zuerst den Befall, bereinigen Dateien samt Konten und schließen im letzten Schritt die Sicherheitslücke.

Ein Content-Management-System (CMS) wie Joomla trennt zwar zwischen dem Systemkern, den Erweiterungen und den beschreibbaren Ordnern für Medien. Sobald aber ein Angreifer über eine Lücke eindringt, legt er eigene Skripte außerhalb der gemeldeten Stelle ab. Infiziert heißt in diesem Zusammenhang, dass fremder Code auf der Website liegt; kompromittiert heißt dagegen, dass jemand einen eigenen Schlüssel zum System besitzt. Diesen Schlüssel nimmt ihm weder das Löschen einer Datei noch eine Neuinstallation der Kerndateien ab, weil Hintertüren in Medienordnern und Konten erhalten bleiben, wie mein Ratgeber zum allgemeinen Ablauf einer Website-Bereinigung zeigt.

Im eigenen Browser kann eine gehackte Seite völlig intakt aussehen, weil der Schadcode die manipulierten Inhalte nur dem Googlebot oder nur Besuchern vom Smartphone ausliefert. Dieses Verfahren heißt Cloaking. Bei meiner Prüfung im dritten Quartal 2026 stand auf befallenen Joomla-Startseiten nur bei 32 von 408 Messungen ein Spam-Begriff im normalen Abruf. Bei 374 bekam allein der Abruf mit Googlebot-Kennung eine deutlich andere Seite. Wie diese Tarnung technisch funktioniert, erkläre ich im Beitrag über SEO-Spam nach einem Hack.

Wenn Sie nur die gemeldete Datei entfernen, riskieren Sie rasch den nächsten Ausfall oder eine Sperrung durch den Hoster, sobald versteckte Skripte Spam versenden. Damit Sie nicht im Blindflug löschen und wichtige Spuren vernichten, prüfen Sie zuerst, was auf Ihrer Joomla-Seite tatsächlich passiert.

Woran erkennen Sie einen Malware-Befall Ihrer Joomla-Website?

Einen Befall Ihrer Joomla-Website erkennen Sie an Warnungen im Bericht „Sicherheitsprobleme“ der Google Search Console, an fremden Suchergebnissen unter Ihrer Domain, an bedingten Weiterleitungen für Smartphone-Besucher oder an unbekannten Konten im Backend. Weil Schadcode den normalen Browser-Aufruf verschonen kann, prüfen Sie Ihre Startseite zusätzlich mit der Kennung des Googlebots.

Der Blick in den Browser täuscht. Auch ein einfacher Online-Check übersieht getarnte Inhalte leicht, wie mein Vergleich kostenloser Malware-Scanner für Websites zeigt. Verlässlichere Daten liefert die Search Console: Laut der offiziellen Google-Hilfe zum Bericht „Sicherheitsprobleme“ nennt dieser Bereich konkrete Beispiel-URLs für Malware oder eingeschleusten Code, während das URL-Prüftool eine Seite so zeigt, wie Google sie sieht. Diesen Abruf stellen Sie auf Ihrem Rechner per curl nach, indem Sie die Kennung des Googlebots (User-Agent) sowie die Google-Suche als Herkunftsseite (Referer) mitsenden (ersetzen Sie example.com durch Ihre Domain):

curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -e "https://www.google.com/" https://example.com/ | head -n 40

Wenn in dieser Ausgabe fremde Links oder Weiterleitungen auftauchen, die Ihr Browser nicht zeigt, spricht das für Cloaking. Nicht jeder Ausfall ist ein Einbruch. Eine Seite, die auf Startseite und Administrator-Bereich nur noch einen Serverfehler mit dem Statuscode HTTP 500 zeigt, wirkt zwar auf den ersten Blick wie ein Angriff. Von außen lässt sich damit jedoch nur der Ausfall belegen. Bei einer im Jahr 2026 untersuchten Joomla-Installation fand ich weder fremde Inhalte noch Umleitungen. Die Ursache steht erst in den Protokollen auf dem Server, die ich sichere, bevor ich etwas ändere.

Wie sichern Sie den befallenen Zustand vor dem ersten Eingriff?

Bevor Sie den ersten Bereinigungsschritt starten, legen Sie eine vollständige Offlinekopie Ihrer Joomla-Installation an: Laden Sie sämtliche Dateien per Secure File Transfer Protocol (SFTP), die Datenbank als SQL-Datei und die Zugriffs- sowie Fehlerprotokolle des Webservers auf Ihren Rechner herunter. Erst danach ändern Sie alle Passwörter von einem virenfreien Gerät aus.

Wenn der Hoster eine infizierte Datei meldet, liegt sofortiges Löschen nahe. Aber dieser Schnellschuss vernichtet Spuren. Auch Google rät im Leitfaden zur Behebung gehackter Websites, vor der Bereinigung sämtliche Dateien und die Datenbank lokal zu sichern, damit der Ausgangszustand erhalten bleibt.

„Bevor ich etwas ändere, sichere ich Ihre Website vollständig. So gibt es jederzeit einen Weg zurück, und der befallene Zustand bleibt für die Ursachenanalyse erhalten.“

— Sascha Fix

Die verdächtigen Dateien und ihre Zeitstempel zeigen später, auf welchem Weg der Angreifer in Ihre Joomla-Seite gelangt ist. Sichern Sie deshalb neben Stammverzeichnis und Datenbank vor allem die Server-Protokolle (access.log und error.log). Wenn Sie die Seite für die Dauer der Analyse sperren wollen, richten Sie einen Verzeichnisschutz ein, etwa im Kundenmenü Ihres Hosters, falls er diese Funktion anbietet.

Spielen Sie in dieser Phase kein älteres Backup ungeprüft ein. Wenn auf dem Server etwa ein Archiv von Akeeba Backup liegt, kann die Hintertür darin schon enthalten sein, während das Überschreiben aktuelle Spuren löscht. Worauf es beim Einspielen ankommt, zeigt mein Beitrag Website nach einem Hack aus dem Backup wiederherstellen. Erst nachdem die Sicherung abgeschlossen ist, ändern Sie alle Passwörter für Hosting, SFTP, Datenbank, E-Mail und Joomla-Konten – und zwar ausschließlich von einem virenfreien Rechner aus, weil Angreifer neue Zugangsdaten sonst sofort wieder mitlesen.

Wo versteckt sich Schadcode in den Joomla-Verzeichnissen?

Angreifer legen Hintertüren in Joomla dort ab, wo der Webserver Schreibrechte besitzt oder bestehende Systemdateien unauffällig geladen werden: in den Ordnern für Bilder und temporäre Daten, im aktiven Template, in der Konfigurationsdatei sowie in der Server-Steuerdatei. Den Schadcode finden Sie nur, wenn Sie alle Serverdateien mit dem offiziellen Joomla-Originalarchiv abgleichen.

Nachdem der Einbruch gelungen ist, sichert sich der Angreifer seinen Rückweg über eine Backdoor oder Webshell – ein Skript, mit dem sich Dateien per Browser hochladen und ausführen lassen. Laut Google gelangen solche Skripte über Verzeichnisse mit offenen Berechtigungen, Lücken in älteren CMS-Versionen oder Erweiterungen von Drittanbietern auf den Server. Wie leicht ein solches Skript auf den Server gelangt, zeigte das Joomla Security Centre unter CVE-2026-73373 (Common Vulnerabilities and Exposures (CVE)): Über diese Kern-Lücke ließen sich .shtml-Dateien hochladen, weil die Endung auf der Standard-Sperrliste fehlte; auf Servern, die solche Dateien ausführen, konnte das zur Codeausführung führen.

Auf Dateinamen ist kein Verlass. Schadcode steckt auch in bestehenden Dateien mit unauffälligen Namen wie index.php. Laden Sie deshalb aus dem offiziellen Joomla-Download-Verzeichnis das passende Release-Archiv Ihrer Version herunter und gleichen Sie die Serverdateien mit diesem Paket ab. Laut Googles Bereinigungsleitfaden achten Sie beim Vergleich vor allem auf Dateien, die im Originalpaket fehlen, sowie auf Kerndateien, die größer als das Original sind. Kontrollieren Sie im selben Schritt die .htaccess mithilfe meines Ratgebers zum Einrichten und Prüfen von .htaccess-Weiterleitungen.

Prüftabelle: Wo sich Schadcode in Joomla versteckt

Wenn Sie per SSH Zugriff auf den Server haben, spüren Sie verdächtige Dateien im Stammverzeichnis (im Beispiel /var/www/html/) mit zwei lesenden Befehlen auf. Der erste Befehl sucht ausführbare Skripte in den Ordnern /images/, /tmp/ und /cache/; der zweite durchsucht den Code nach Verschleierungsfunktionen wie base64_decode, gzinflate, str_rot13 oder eval, weil Google diese als typische Tarnmuster nennt:

find /var/www/html/images /var/www/html/tmp /var/www/html/cache \
  -type f \( -name "*.php*" -o -name "*.shtml" -o -name "*.phtml" \)
grep -rnE "(base64_decode|gzinflate|str_rot13|eval\s*\()" /var/www/html/

Skript-Treffer in /images/ gehören dort nicht hin; grep-Treffer in Erweiterungen gleichen Sie mit dem Originalpaket des Herstellers ab. Sobald das Dateisystem überblickt ist, folgt die Bereinigung der Benutzer und der Datenbank.

Wie bereinigen Sie Benutzer, Erweiterungen und die Joomla-Datenbank?

Wenn Sie Joomla-Malware vollständig entfernen wollen, ersetzen Sie zuerst veränderte Kerndateien durch das Originalpaket, löschen fremde Konten in der Benutzertabelle samt Super-User-Zuordnung, beenden aktive Sitzungs-Cookies und säubern manipulierte Erweiterungen. Greifen Sie in die Joomla-Datenbank erst ein, nachdem ein vollständiges Backup vorliegt und sofern Sie SQL-Tabellen sicher beurteilen können.

Warum reicht der Dateivergleich nicht aus? Weil Angreifer ihren Zugang und fremde Inhalte direkt in der Datenbank verankern können. Im September 2026 meldete das Joomla Security Centre zwei solcher Kern-Lücken: Über profile.save (CVE-2026-90907) ließen sich selbst bei abgeschalteter Registrierung Benutzerkonten anlegen, und ein vorzeitig ausgestelltes rememberme-Cookie (CVE-2026-92227) hebelte die Zwei-Faktor-Authentifizierung aus. Wenn Sie bei Spam nur die sichtbaren Texte löschen, bleibt der Erzeuger im System. Arbeiten Sie die Bereinigung in diesen fünf Schritten ab:

1. Kerndateien und Erweiterungen gegen das Original ersetzen

   Überschreiben Sie veränderte Systemdateien mit den sauberen Dateien aus dem offiziellen Joomla-Release-Archiv Ihrer Version und installieren Sie genutzte Erweiterungen aus frischen Originalpaketen der Hersteller neu. Löschen Sie im Anschluss alle Fremddateien aus /images/, /tmp/ und /cache/ sowie verwaiste Erweiterungsordner, damit keine Webshell zurückbleibt.

2. Unbekannte Konten und Super-User-Rechte entfernen

   Prüfen Sie in der Benutzerverwaltung des Backends oder – nachdem Sie ein Backup angelegt haben und sofern SQL-Kenntnisse vorliegen – in phpMyAdmin die Tabellen jos_users und jos_user_usergroup_map (jos_ steht für Ihr Tabellenpräfix). Löschen Sie fremde Konten und kontrollieren Sie alle Zuordnungen zur Gruppe „Super Users“ (Gruppen-ID 8).

3. Laufende Sitzungen und Remember-Me-Cookies ungültig machen

   Leeren Sie nach einem Backup in der Datenbank die Sitzungstabelle jos_session sowie die Tabelle jos_user_keys mit den gespeicherten Remember-Me-Tokens. Ändern Sie in der configuration.php den Wert für $secret und vergeben Sie ein neues Datenbank-Passwort.

4. Manipulierte Beiträge und Erweiterungen in der Datenbank prüfen

   Kontrollieren Sie mit vorliegendem Datenbank-Backup in der Tabelle jos_extensions, ob unbekannte Plugins aktiviert wurden, und durchsuchen Sie jos_content sowie jos_modules nach fremden <script>-, <iframe>- oder Spam-Einträgen. Greifen Sie in SQL-Tabellen nur ein, wenn Sie die Tabellenstruktur sicher kennen, weil falsche Abfragen die Seite sonst beschädigen.

5. Fremde Inhaber und Bestätigungstoken in der Search Console löschen

   Prüfen Sie in der Google Search Console unter „Nutzer und Berechtigungen“, ob dort ein unbekannter Inhaber eingetragen ist. Dokumentieren Sie dessen Bestätigungstoken (HTML-Datei im Stammverzeichnis oder .htaccess-Regel), löschen Sie das Token auf dem Server und widerrufen Sie im Anschluss die Inhaberschaft.

Sofern Ihnen SSH zur Verfügung steht, leeren Sie im Joomla-Hauptverzeichnis mit php cli/joomla.php cache:clean den System-Cache, damit keine zwischengespeicherten Spam-Ausgaben übrig bleiben.

Wann können Sie Joomla selbst bereinigen und wann ist Hilfe nötig?

Sie können eine befallene Joomla-Website selbst bereinigen, wenn Sie Zugriff per SFTP und auf die Datenbankverwaltung haben, PHP-Code sowie Server-Konfigurationen lesen können und keine Kundendaten betroffen sind. Fehlt eine dieser Voraussetzungen oder kehrt der Schadcode zurück, geben Sie die Bereinigung besser ab.

Wo verläuft die Grenze zur Beauftragung? Laut Google müssen Sie für die eigene Bereinigung Code lesen und verstehen können und sich eventuell mit der Webserver-Konfiguration auskennen. Wenn personenbezogene Daten aus Kontaktformularen, Mitgliederbereichen oder einem Shop betroffen sind, kann eine Meldepflicht nach Art. 33 DSGVO bestehen. Ob diese Pflicht für Ihren Fall greift, beurteilen ein Rechtsanwalt oder Ihr Datenschutzbeauftragter auf Basis einer sauberen technischen Dokumentation des Vorfalls. Falls Sie Strafanzeige erstatten oder ein gerichtsverwertbares Gutachten benötigen, wenden Sie sich an einen zertifizierten IT-Forensiker.

Wenn Sie die Bereinigung abgeben möchten, übernehme ich die Arbeit über meine Hilfe bei gehackten Joomla-Websites. Die Erstanalyse ist kostenlos, damit Sie Umfang und Festpreis kennen, bevor ich beginne. Für einen klaren Dateibefall startet die Basis-Bereinigung ab 299 € zzgl. 19 % USt.; tiefere Eingriffe inklusive Datenbank, SEO-Spam und Google-Überprüfungsantrag deckt das Paket Deep-Clean (ab 499 € zzgl. 19 % USt.) ab. Ich melde mich in der Regel innerhalb eines Werktags persönlich, sichere zuerst den Stand und liefere nach der Bereinigung (in der Regel in ein bis drei Werktagen) einen Abschlussbericht; in den Deep-Clean-Paketen folgt eine kostenfreie Nachkontrolle von 14 oder 30 Tagen. Weitere Arbeiten am System bündelt meine Joomla-Entwicklung.

Wie schließen Sie das Einfallstor und sichern Joomla nach der Bereinigung ab?

Nachdem der Schadcode entfernt ist, schließen Sie das Einfallstor, indem Sie Joomla sowie sämtliche Erweiterungen aktualisieren, Dateirechte härten und die Zwei-Faktor-Authentifizierung für Administratoren aktivieren. Wenn Ihre Website noch mit Joomla 3 oder 4 läuft, muss im Anschluss ein Wechsel auf das aktuelle System folgen.

Vor dem Weiterbetrieb einer bereinigten Website steht der Blick auf die Versionsgrenze – vom laufenden Hersteller-Support hängt ab, ob ein einfaches Update reicht oder ein Systemwechsel ansteht. Für Joomla 3 endete selbst der erweiterte Support im Februar 2025, wie mein Beitrag zum Supportende von Joomla 3 zeigt; für Joomla 4 liefen die Updates im Oktober 2025 aus. Laut der offiziellen Joomla-Roadmap erhalten nur noch Joomla 5 (bis Oktober 2027) und Joomla 6 (bis Oktober 2029) Sicherheits-Patches (Stand November 2026). Wenn Sie noch ein älteres System nutzen, übernehme ich nach dem Säubern die Migration auf Joomla 6 (ab 1.490 € zzgl. 19 % USt.).

Gegen das Risiko, dass ein Update die Seite lahmlegt, hilft kein Update-Verzicht, sondern ein fester Ablauf mit Rückweg: Sichern Sie die Website außerhalb des Webspace, bevor Sie ein Update starten, und testen Sie größere Versionssprünge zuerst an einer Kopie. Damit im Alltag keine Lücke offen bleibt, übernehme ich die laufende Pflege in meiner Joomla-Wartung zum Festpreis (ab 39 € im Monat zzgl. 19 % USt.). Eine Garantie, dass eine Seite nie gehackt wird, kann niemand seriös geben, weil kein Update eine am Angriffstag noch unbekannte Lücke schließt. Deshalb ist die Bereinigung in meinen Wartungspaketen enthalten, wenn der Befall nach Beginn der Wartung entsteht und gekaufte Erweiterungen eine gültige Lizenz haben.

Härten Sie ergänzend die Konfiguration ab: Aktivieren Sie im Backend die Zwei-Faktor-Authentifizierung und schalten Sie eine Web Application Firewall (WAF) ein, falls Ihr Hoster eine anbietet. Auf einer 2026 migrierten Joomla-Installation sind beispielsweise die Manifest- und README-Dateien, an denen Scanner die Version ablesen, mit HTTP 403 gesperrt, und der Server sendet Sicherheits-Header. Solche Maßnahmen ersetzen keine Updates.

Erst wenn alle Hintertüren entfernt und sämtliche Updates eingespielt sind, beantragen Sie in der Search Console die erneute Überprüfung. Laut Google ist bei den meisten Überprüfungen mit mehreren Tagen oder Wochen zu rechnen, und ein verfrühter Antrag kann die Bearbeitung des nächsten Antrags verlängern. Den genauen Ablauf zeigt mein Beitrag Google-Blacklist und Warnseite nach einem Hack entfernen.