Joomla absichern: Welche Schutzmaßnahmen zuerst kommen

Warum werden Joomla-Websites angegriffen?

Automatisierte Scanner prüfen über öffentlich erreichbare Dateien, welches System auf einer Website läuft und welche Versionsnummer installiert ist. Wer Joomla absichern will, schließt deshalb zuerst die Lücken, nach denen diese Scanner suchen – mit laufender Pflege am Systemkern, geschützten Benutzerkonten, aufgeräumten Erweiterungen, festen Server-Regeln und durchgängiger Verschlüsselung.

Die meisten gehackten Seiten, die auf meinem Tisch landen, hatten ein Wartungsproblem: veraltete Erweiterungen, kein Backup, kein Verantwortlicher. Mit jedem liegen gelassenen Update bleiben bekannte Sicherheitslücken offen. Die folgenden Maßnahmen härten eine saubere Installation präventiv ab, um typische Einfallstore für automatisierte Angriffe zu schließen. Zeigt Ihre Website dagegen bereits fremde Unterseiten in den Suchergebnissen, Weiterleitungen auf dubiose Domains oder eine Browser-Warnung, helfen Härtungsschritte allein nicht mehr, weil Angreifer Hintertüren im Dateisystem abgelegt haben können. Den Ablauf einer Bereinigung lesen Sie unter Website nach Hack wiederherstellen oder direkt bei meiner Joomla-Hack-Hilfe.

Welche Joomla-Versionen bekommen noch Sicherheitsupdates?

Die erste Schutzmaßnahme ist ein Systemkern, der noch Sicherheitsupdates bekommt, denn nur ein unterstützter Zweig erhält offizielle Sicherheitskorrekturen vom Entwicklerteam. Aktuell bekommen ausschließlich Joomla 5.4 und Joomla 6 solche Updates, während Joomla 3 und Joomla 4 aus der offiziellen Versorgung gefallen sind. Neu entdeckte Lücken im Kern schließt das Joomla-Projekt in diesen alten Hauptversionen deshalb nicht mehr.

Joomla 6 ist im Oktober 2025 erschienen und erhält nach der offiziellen Roadmap von Joomla bis Oktober 2028 reguläre Fehlerkorrekturen und bis zum 16. Oktober 2029 Sicherheitsupdates. Bei Joomla 5.4 ist die reguläre Fehlerbehebung zwar am 13. Oktober 2026 ausgelaufen; reine Sicherheitsupdates erscheinen noch bis zum 12. Oktober 2027. Für Joomla 4 endeten die Sicherheitsupdates hingegen schon im Oktober 2025, und für Joomla 3 lief im Februar 2025 auch das kostenpflichtige Zusatzprogramm (eLTS) aus, sodass für beide Zweige keine Sicherheitsupdates des Projekts mehr erscheinen.

Die Folgen eines abgelaufenen Supports zeigten sich im September 2026 an der Sicherheitslücke CVE-2026-92227: Ein vorzeitig ausgestelltes rememberme-Cookie ermöglichte es Angreifern, die Multi-Faktor-Authentifizierung in Joomla 4, 5 und 6 zu umgehen. Das Projekt schloss die Lücke mit den Versionen 5.4.9 und 6.1.4; Joomla 4 bekommt seit dem 14. Oktober 2025 keine Sicherheitsupdates mehr. Läuft Ihre Seite noch auf Joomla 3 oder 4, planen Sie zuerst das Upgrade auf eine unterstützte Version ein; die Schritte zeigen der Beitrag Joomla 3 Update und meine Joomla-Migration.

Innerhalb eines unterstützten Zweigs dürfen neue Zwischenversionen laut Roadmap die Rückwärtskompatibilität nicht brechen, damit bestehende Seiten stabil weiterlaufen. Seit Joomla 5.4 bringt das System dafür automatische Core-Updates (Automated Core Updates) mit. Bei Sicherheitskorrekturen am Kern zählt nämlich das Tempo: Die Zeit zwischen dem Bekanntwerden einer Lücke und ihrer Ausnutzung schrumpft, und keine manuelle Update-Routine ist schnell genug für dieses Fenster. Dennoch gilt mein Rat: Spielen Sie kein Update ohne frisches Backup ein – und probieren Sie aus, ob es sich zurückspielen lässt.

Neben dem Content-Management-System (CMS) zählt auch die PHP-Version auf dem Server, weil Joomla seinen gesamten Code über den PHP-Interpreter des Hosters ausführt. Joomla 6 verlangt mindestens PHP 8.3 und empfiehlt PHP 8.4. Der Sicherheits-Support für PHP 8.2 endet laut der offiziellen PHP-Versionsübersicht am 31. Dezember 2026, während PHP 8.3 bis Ende 2027, PHP 8.4 bis Ende 2028 und PHP 8.5 bis Ende 2029 versorgt werden (Stand November 2026).

Wer von PHP 8.2 wechselt, geht nach einem Erweiterungstest am besten gleich auf PHP 8.4; PHP 8.3 nehme ich nur als Zwischenschritt, wenn eine Erweiterung 8.4 noch nicht verträgt. Den Ablauf zeige ich im Beitrag PHP-Version beim Hoster umstellen.

Wie schützen Sie Benutzerkonten und den Joomla-Administrator?

Selbst ein tagesaktueller Systemkern hilft nicht weiter, wenn Angreifer sich mit erbeuteten oder erratenen Zugangsdaten regulär unter /administrator anmelden können. Weil die Anmeldeseite des Backends bei jeder Standardinstallation unter derselben Adresse erreichbar ist, gehört die Absicherung der Benutzerkonten zu den ersten Aufgaben im Backend.

In einer frischen Installation von Joomla 5.4 ist die öffentliche Benutzerregistrierung in den Optionen der Komponente com_users zwar abgeschaltet und die Mindestlänge für Passwörter auf zwölf Zeichen voreingestellt. Doch die Vorgaben für Ziffern, Großbuchstaben und Sonderzeichen stehen ab Werk auf null. Prüfen Sie in den Optionen der Benutzerverwaltung zuerst, dass die Registrierung neuer Konten gesperrt bleibt, damit sich niemand unbemerkt ein eigenes Konto anlegt, und setzen Sie verbindliche Mindestwerte für alle Zeichenklassen.

Gegen gestohlene Passwörter hilft die Multi-Faktor-Authentifizierung (MFA), im Alltag als Zwei-Faktor-Authentifizierung bekannt. Sie ist seit Joomla 4.2 fest im Systemkern eingebaut, eine Zusatzsoftware brauchen Sie dafür nicht. Joomla liefert fünf MFA-Plugins mit, von denen vier ab Werk aktiviert sind: zeitbasierte Einmalcodes per App (totp), Sicherheitsschlüssel (yubikey), Passkeys im Browser (webauthn) sowie sechsstellige Codes per E-Mail (email). Solange dieser zweite Schritt nach dem Passwort nicht abgeschlossen ist, sperrt Joomla jeden Wechsel auf andere Backend-Seiten.

Schreiben Sie die Multi-Faktor-Authentifizierung in den Benutzer-Optionen über Enforce Multi-factor Authentication für ausgewählte Benutzergruppen verpflichtend vor, damit kein Administrator diesen Schutz überspringt, und verwahren Sie die erzeugten Notfallcodes (Backup Codes) getrennt vom Gerät. Zur Zugangsabsicherung gehört auch die Rollentrennung über die neun Standard-Benutzergruppen, denn nur Super Users besitzen ab Werk das globale Vollrecht core.admin sowie den API-Zugriff core.login.api. Redakteure arbeiten daher mit Konten wie Editor, Publisher oder Manager; das Super-User-Konto bleibt so geschützt. In der Rechtevererbung gilt Denied always wins: Ein verweigertes Recht bleibt auch in den untergeordneten Gruppen gesperrt.

Warum sind Erweiterungen ein eigenes Einfallstor und wie misten Sie aus?

Wer nur auf die Versionsnummer von Joomla selbst achtet, übersieht einen großen Teil der Angriffsfläche, denn nachinstallierte Komponenten, Module, Plugins und Templates stammen von Drittanbietern. Für ihre Sicherheitsupdates ist allein der jeweilige Hersteller zuständig, und ungenutzte Erweiterungen deinstallieren Sie vollständig, statt sie nur abzuschalten.

Das Security Centre von Joomla zieht eine eindeutige Grenze: Das offizielle Sicherheitsteam, das Joomla! Security Strike Team (JSST), betreut ausschließlich das Joomla-CMS selbst, das Joomla-Framework und die Projektseiten unter *.joomla.org. Erweiterungen von Drittanbietern liegen außerhalb dieser Zuständigkeit. Sie sind als Betreiber bei jedem Formular-Werkzeug, jeder Galerie und jedem Page-Builder darauf angewiesen, dass der Hersteller Sicherheitslücken schließt, damit Sie das Update zeitnah einspielen können.

In gewachsenen Installationen sammeln sich über die Jahre zudem Zusatzprogramme an, die einmal getestet und später lediglich abgeschaltet wurden. Deaktivieren allein reicht nicht. Joomla lädt ein deaktiviertes Plugin zwar nicht mehr in den Seitenaufbau, seine PHP-Dateien liegen aber unverändert auf dem Server. Wenn sich eine verwundbare Datei direkt über ihre Adresse aufrufen lässt, genügt schon der vorhandene Ordner für einen Angriff. Deinstallieren Sie unter System → Verwalten → Erweiterungen jede ungenutzte Komponente und jedes alte Template vollständig, sodass die Dateien vom Server verschwinden.

Für die verbleibenden, aktiv genutzten Erweiterungen empfehle ich ein anderes Vorgehen als für kleine Sicherheitskorrekturen am Systemkern. Umfangreiche Drittanbieter-Komponenten wie Page-Builder oder Shop-Erweiterungen greifen tief in Templates und Datenbanktabellen ein, sodass ein unkontrolliertes Auto-Update Darstellungsfehler oder einen PHP-Abbruch auslösen kann. Das Joomla-Projekt rät in seinen Versionshinweisen ebenfalls dazu, das Upgrade auf eine neue Hauptversion zuerst an einer Kopie der Produktivseite zu testen. Große Erweiterungs-Updates spielen Sie deshalb erst nach einem frischen Backup ein oder testen sie vorher in einer Staging-Umgebung.

Welche Server-Regeln und Sicherheits-Header härten Ihre Joomla-Installation?

Schutzmaßnahmen im Joomla-Backend greifen erst dann, wenn eine Anfrage bereits bei der PHP-Anwendung angekommen ist. Eine Ebene davor sitzt der Webserver. Mit einer aktiven Konfigurationsdatei weisen Sie dort Verzeichnisabfragen und typische Angriffsmuster ab, bevor das System überhaupt geladen wird, und mit passenden Sicherheits-Headern geben Sie dem Browser zusätzliche Regeln mit.

Joomla liefert im Stammverzeichnis zwar eine vorbereitete Datei namens htaccess.txt aus, doch auf Apache-Servern wird sie erst wirksam, wenn Sie die Datei in .htaccess umbenennen; ihre Rewrite-Regeln greifen nur, wenn das Modul mod_rewrite aktiv ist. Auf Nginx-Servern wirkt die Datei nicht, dort gehören die Regeln in die Server-Konfiguration. Die Vorlage aus dem Joomla-5.4-Quellcode unterbindet per Options -Indexes das Auflisten von Ordnerinhalten, blockiert per Rewrite-Regeln typische Exploit-Muster in der Adresszeile (wie base64_encode) und sperrt Skripte in SVG-Dateien per Content-Security-Policy "script-src 'none'", damit hochgeladene Grafiken keinen Code ausführen. Der Ratgeber .htaccess-Weiterleitung einrichten gibt Hinweise zur sicheren Bearbeitung.

Ergänzend zur .htaccess-Datei enthält Joomla das ab Werk aktivierte System-Plugin System - HTTP Headers (plg_system_httpheaders), sodass Sie keine Zusatzkomponente installieren müssen. Darüber richten Sie Sicherheits-Header wie X-Frame-Options gegen fremde Frame-Einbettung, Referrer-Policy und Strict-Transport-Security (HSTS) direkt im Backend ein, während die .htaccess-Vorlage bereits Header always set X-Content-Type-Options "nosniff" setzt. Prüfen Sie außerdem die Datei configuration.php, denn sie enthält die Datenbank-Zugangsdaten sowie das System-Secret und sollte nach Änderungen schreibgeschützt sein (0444).

Darüber hinaus lassen sich auf Serverebene die öffentlich lesbaren Systemdateien sperren, an denen Scanner den genauen Versionsstand ablesen. An einer im Sommer 2026 auf Joomla 6 migrierten Installation antworten beispielsweise die XML-Manifest-Datei und die README.txt mit dem Statuscode 403 Forbidden, und der Server sendet Sicherheits-Header.

Warum gehört HTTPS zu den unverzichtbaren Grundlagen?

Auf den ersten Blick wirkt die Transportverschlüsselung zwar wie ein reines Thema für Suchmaschinen oder das Kontaktformular. Für Ihre Joomla-Website ist durchgehendes HTTPS aber die technische Voraussetzung dafür, dass Passwort und zweiter Faktor geschützt bleiben, weil Anmeldedaten und Sitzungs-Cookies unter /administrator sonst im Klartext über das Netzwerk wandern.

Ein Zertifikat genügt nicht. Solange der Webserver Aufrufe über http:// nicht lückenlos per Statuscode 301 auf https:// weiterleitet und in der globalen Konfiguration von Joomla unter Server die Option zum Erzwingen von HTTPS (Force HTTPS) nicht für die gesamte Website aktiviert ist, bleibt der unverschlüsselte Zugangsweg offen.

Wie oft diese Grundabsicherung fehlt, zeigt meine passive Prüfung von 469.696 Firmen-Startseiten in Deutschland im dritten Quartal 2026: Bei 2.681 der 16.499 Joomla-Startseiten darunter (16,2 Prozent) endete der Abruf nach allen Weiterleitungen auf einer unverschlüsselten HTTP-Adresse. Seit Oktober 2026 fragt Google Chrome vor Seiten ohne HTTPS nach; die Messdaten und die Schritte zur Umstellung stehen im Beitrag Chrome warnt vor HTTP-Seiten.

Joomla selbst absichern oder Wartung beauftragen?

Wenn Sie eine bestehende Website mit Joomla absichern und Ihre Installation selbst überprüfen möchten, bringt eine feste Reihenfolge Ruhe in die Arbeit, denn erst wenn die Transportverschlüsselung, der Systemkern und die Benutzerkonten abgesichert sind, entfalten feinere Server-Regeln ihren Nutzen. Die folgende Übersicht zeigt die fünf Schritte nach Priorität und grenzt ab, wo im Betrieb Prüfaufwand entsteht.

Die Grundeinstellungen im Backend und das Umbenennen der .htaccess-Datei lassen sich zwar selbst umsetzen, doch im Betrieb steigt der Aufwand: Jedes Sicherheitsupdate an Joomla oder einer Drittanbieter-Komponente muss zeitnah bemerkt, nach einem externen Backup eingespielt und auf Nebenwirkungen geprüft werden. Selbst bei gewissenhafter Pflege bleibt im Internet ein Restrisiko durch neu entdeckte Schwachstellen bestehen, weil für solche Lücken noch kein Patch bereitsteht.

„Eine Garantie, dass eine Website nie gehackt wird, kann niemand geben, denn eine Lücke, die noch niemand kennt, schließt auch das beste Update nicht. Darum gehört die Bereinigung bei mir zur Wartung.“

— Sascha Fix

Wenn Sie diese laufende Verantwortung nicht neben Ihrem Tagesgeschäft tragen möchten, übernehme ich die Betreuung in meiner Joomla-Wartung. Das Paket Joomla-Wartung Basis kostet 39 € im Monat zzgl. 19 % USt. und umfasst wöchentliche Updates mit vorherigem Backup, monatliche Backups außerhalb des Webspace, die Überwachung der Erreichbarkeit rund um die Uhr, monatliche Sicherheits-Scans, einen monatlichen Statusbericht sowie die Bereinigung ohne Aufpreis, falls Ihre Website während der Betreuung doch einmal kompromittiert wird und gekaufte Erweiterungen eine gültige Lizenz haben. Der Erstcheck Ihrer Installation vor dem Start ist kostenlos, damit Sie vorab wissen, wo Ihre Seite steht.

Ist Ihre Website dagegen bereits akut betroffen, bereinige ich sie in meiner Joomla-Hack-Hilfe (ab 299 € zzgl. 19 % USt.). Steht stattdessen der Wechsel von Joomla 3 oder 4 auf Joomla 6 oder eine technische Weiterentwicklung an, finden Sie alle Informationen unter Joomla-Migration sowie in der Übersicht zur Joomla-Entwicklung.