Website gehackt? Erkennen, prüfen und richtig reagieren

Website-Sicherheit in der Praxis

Website gehackt – was jetzt?

Warum Updates allein nicht reichen und wie Unternehmen und Vereine ihre Website beobachten, absichern und nach einem Angriff richtig reagieren

Redaktionsstand: 21. September 2026

Eine Website funktioniert plötzlich nicht mehr richtig. Besucher werden auf fremde Seiten weitergeleitet. In Suchmaschinen erscheinen merkwürdige Unterseiten. Im Webspace liegen Dateien, die dort niemand bewusst abgelegt hat. Oder die Zugriffszahlen steigen plötzlich ungewöhnlich stark an.

Manchmal ist ein Angriff dagegen überhaupt nicht zu übersehen: Auf der Startseite erscheint plötzlich das Logo oder eine Botschaft des Angreifers.

Spätestens dann steht eine unangenehme Frage im Raum:

Wurde die Website gehackt?

In meiner Arbeit sind mir zuletzt mehrere tatsächlich kompromittierte Websites begegnet. Die von uns untersuchten Fälle betrafen Joomla!-Installationen der Hauptversionen 4, 5 und 6. Das liegt allerdings auch daran, dass Joomla! seit vielen Jahren mein bevorzugtes Content-Management-System ist und entsprechend viele der von mir betreuten Websites darauf basieren.

Aus dieser Häufung lässt sich deshalb nicht ableiten, dass Joomla! grundsätzlich unsicherer wäre als andere Content-Management-Systeme. Im Gegenteil: Ein Blick auf andere verbreitete Systeme wie WordPress zeigt, dass Sicherheitslücken, notwendige Aktualisierungen und Angriffsversuche grundsätzlich zum Betrieb öffentlich erreichbarer Webanwendungen gehören.

Für mich war besonders interessant, dass nicht nur ältere Installationen betroffen waren. Auch eine von uns betreute Website auf Basis von Joomla! 6 gehörte zu den kompromittierten Systemen.

Gerade dieser Fall zeigt, warum es nicht genügt, eine Website nur auf einem aktuellen technischen Stand zu halten. Sicherheitsupdates sind wichtig und sollten zeitnah installiert werden. Gleichzeitig müssen aber auch die übrigen Bestandteile einer Website – etwa Erweiterungen, Zugangsdaten, Serverumgebung und Benutzerkonten – berücksichtigt und die Website selbst regelmäßig kontrolliert werden.

Ein aktuelles CMS reduziert bekannte Risiken. Es ersetzt jedoch weder die laufende technische Pflege noch die Beobachtung des tatsächlichen Betriebs.

Die Erfahrung zeigt aber sehr deutlich:

Eine aktuelle Website ist nicht automatisch dauerhaft sicher. Aktualität, Kontrolle und laufende Pflege gehören zusammen.

Kurz zusammengefasst

Auch aktuelle Content-Management-Systeme können Sicherheitslücken enthalten oder über andere Komponenten kompromittiert werden.
Ein Angriff kann offensichtlich sein – oder sich nur bei einzelnen Links, Aufrufwegen oder Besuchern zeigen.
Updates sind notwendig, ersetzen aber keine regelmäßige Kontrolle der Website.
Auffällige Zugriffszahlen, ungewöhnliche Fehler und unbekannte Aufrufe sollten untersucht werden.
Für die technische Pflege muss eine Person oder ein externer Dienstleister klar zuständig sein.
Bei einem Verdacht sollten Dateien, Logs und der aktuelle Zustand gesichert werden, bevor vorschnell gelöscht wird.
Backups helfen nur, wenn sie vollständig, überprüft und aus einem vertrauenswürdigen Zustand stammen.
Automatisierte Website-Checks können Hinweise liefern, ersetzen aber keine Malware-Forensik oder vollständige Sicherheitsanalyse.

Ein Angriff kann offensichtlich sein – oder fast unsichtbar

Unsere eigenen Fälle haben gezeigt, wie unterschiedlich eine kompromittierte Website aussehen kann.

Bei einem Fall war die Manipulation sofort sichtbar. Die eigentliche Startseite war durch eine Darstellung mit dem Logo beziehungsweise der Botschaft des Angreifers ersetzt worden. Ein solches sichtbares Verändern einer Website wird häufig als Defacement bezeichnet.

Andere Fälle waren wesentlich unauffälliger. Die Website sah beim normalen Aufruf zunächst völlig in Ordnung aus. Erst wenn bestimmte Links angeklickt wurden, erfolgte eine Weiterleitung auf dubiose Glücksspiel- oder Erotikseiten.

Genau solche Manipulationen können besonders lange unentdeckt bleiben. Google beschreibt bei gehackten Websites unter anderem eingeschleusten Code, neue Spam-Seiten, verborgene Inhalte und schädliche Weiterleitungen. Solche Redirects können sogar davon abhängen, über welchen Link, welches Gerät oder welchen Referrer ein Besucher auf die Website gelangt.

Deshalb reicht es nicht immer, nur die Startseite aufzurufen und festzustellen: „Sie funktioniert doch.“

Mögliche Hinweise auf eine Manipulation können beispielsweise sein:

ein fremdes Logo oder eine fremde Botschaft auf der Website,
Weiterleitungen auf Glücksspiel-, Erotik-, Spam- oder andere dubiose Seiten,
Links, die plötzlich auf andere Ziele führen,
unbekannte PHP-, JavaScript- oder andere Dateien,
neu angelegte oder unbekannte Administrationskonten,
veränderte System- oder Konfigurationsdateien,
fremde Seiten oder Inhalte in Suchmaschinenergebnissen,
ungewöhnliche ausgehende E-Mails,
Warnungen von Browsern, Suchmaschinen oder dem Hosting-Anbieter,
auffällig hohe Serverlast,
ungewöhnlich viele Zugriffe,
auffällige Aufrufe unbekannter Dateien oder Verzeichnisse,
plötzlich stark zunehmende Fehler oder fehlgeschlagene Anfragen.

Die Website nicht nur ansehen – sondern regelmäßig benutzen

Bei unseren betroffenen Websites wurden die Probleme vergleichsweise zeitnah festgestellt. Das war ein wichtiger Vorteil.

Eine kompromittierte Website muss nicht vollständig ausfallen. Sie kann weiterhin erreichbar sein und für den Betreiber zunächst normal aussehen. Wer sie nur dann besucht, wenn ein neuer Text eingestellt werden soll, bemerkt Veränderungen möglicherweise lange nicht.

Deshalb halte ich es für sinnvoll, die eigene Website regelmäßig selbst aufzurufen und wichtige Funktionen tatsächlich zu benutzen.

Dazu gehört beispielsweise:

die Startseite und wichtige Unterseiten aufzurufen,
die Navigation zu benutzen,
interne und wichtige externe Links anzuklicken,
Kontakt- und Anfrageformulare zu testen,
Downloads stichprobenartig aufzurufen,
die Website gelegentlich auch mit einem Smartphone zu prüfen,
auf ungewöhnliche Weiterleitungen oder Fehlermeldungen zu achten.

Das ist keine vollständige Sicherheitsprüfung. Eine solche regelmäßige Sichtkontrolle erhöht aber die Chance, offensichtliche Veränderungen früh wahrzunehmen.

Plötzlich viele Zugriffe? Nicht automatisch ein Angriff – aber ein Anlass zum Nachsehen

Auch technische Daten können wichtige Hinweise liefern.

Wenn eine Website plötzlich erheblich mehr Zugriffe verzeichnet als üblich, bedeutet das nicht automatisch, dass sie angegriffen wird. Vielleicht wurde ein Beitrag häufig geteilt, eine Suchmaschine erfasst neue Inhalte oder ein legitimer Bot besucht viele Seiten.

Ungewöhnliche Veränderungen sollten trotzdem nicht einfach ignoriert werden.

Die interessante Frage lautet dann nicht nur:

Wie viele Zugriffe hatten wir?

Sondern vor allem:

Was wurde aufgerufen?

Zugriffs- und Fehlerprotokolle können beispielsweise zeigen:

welche URLs besonders häufig aufgerufen wurden,
ob nach Dateien oder Verzeichnissen gesucht wurde, die auf der Website gar nicht existieren,
ob Login- oder Administrationsbereiche ungewöhnlich oft angesprochen wurden,
ob sehr viele Anfragen in kurzer Zeit eingegangen sind,
ob bestimmte Fehlercodes plötzlich deutlich häufiger auftreten,
ob immer wieder dieselben ungewöhnlichen Pfade abgefragt werden.

Solche Auffälligkeiten sind zunächst Hinweise und noch kein Beweis für einen erfolgreichen Angriff. Sie können aber Anlass sein, genauer hinzusehen.

Warum unsere Joomla!-Fälle kein „Joomla!-Problem“ belegen

Unsere bisherigen konkreten Fälle betrafen Joomla! 4, 5 und 6. Die Häufung erklärt sich vor allem daraus, dass Joomla! mein bevorzugtes CMS ist und sich deshalb ein großer Teil der von mir betreuten Installationen in diesem Umfeld befindet.

Joomla! wird aktiv weiterentwickelt und veröffentlicht Sicherheitskorrekturen. Im Jahr 2026 wurden auch Probleme behoben, die Installationen der Version 6 betrafen. Das Joomla! Security Centre dokumentiert beispielsweise für August 2026 mehrere korrigierte Schwachstellen in Versionen bis einschließlich 6.1.2. Die bereitgestellten Aktualisierungen auf 5.4.8 beziehungsweise 6.1.3 schlossen unter anderem Probleme bei Zugriffskontrollen, Mehr-Faktor-Authentifizierung und bestimmten Dateiuploads.

Genau darin liegt ein wesentlicher Punkt: Eine Version kann heute aktuell sein und morgen ein Sicherheitsupdate benötigen.

Das gilt nicht nur für Joomla!.

Auch WordPress zeigt 2026, warum laufende Pflege notwendig ist

WordPress ist ein gutes Gegenbeispiel zu der Annahme, Sicherheitsprobleme seien auf ein bestimmtes Content-Management-System beschränkt.

Am 17. Juli 2026 veröffentlichte WordPress die Sicherheitsversion 7.0.2. Nach Angaben des WordPress-Projekts wurden damit ein kritisches und ein als hoch eingestuftes Sicherheitsproblem behoben. Eines der Probleme verband eine REST-API-Problematik mit einer SQL-Injection und konnte zur Ausführung von Code aus der Ferne führen. Aufgrund der Schwere aktivierte WordPress für betroffene Versionen sogar erzwungene automatische Updates.

Nur wenige Tage vor Redaktionsschluss dieses Beitrags folgte am 18. September 2026 WordPress 7.1.1 mit insgesamt elf weiteren Sicherheitskorrekturen. Darunter waren unter anderem Cross-Site-Scripting-, Pfadtraversal- und Berechtigungsprobleme.

Auch hier lautet die sinnvolle Schlussfolgerung nicht „WordPress ist unsicher“.

Die richtige Schlussfolgerung lautet:

Komplexe und öffentlich erreichbare Software muss fortlaufend gepflegt werden – unabhängig vom Namen des CMS.

Ein CMS ist nur ein Teil der Website

Bei einem Sicherheitsvorfall sollte außerdem nicht vorschnell angenommen werden, dass der eigentliche CMS-Kern die Ursache gewesen sein muss.

Eine moderne Website besteht meist aus mehreren technischen Ebenen:

dem Content-Management-System selbst,
Plugins, Komponenten, Modulen oder anderen Erweiterungen,
Themes beziehungsweise Templates,
PHP und weiteren Server-Komponenten,
Webserver und Datenbank,
Hosting-Konfiguration und Dateirechten,
Benutzerkonten und Zugangsdaten,
SFTP-, Hosting- und Domainzugängen,
Formularen, Upload-Funktionen und Schnittstellen,
gegebenenfalls weiteren Anwendungen im selben Hosting-Paket.

Eine aktuelle CMS-Version ist deshalb wichtig, aber nur ein Teil des Gesamtbildes.

Die entscheidende Frage nach einem Vorfall lautet nicht:

Welches CMS ist schuld?

Sondern:

Wie konnte diese konkrete Website verändert werden – und ist dieser Weg inzwischen zuverlässig geschlossen?

Ältere Installationen bleiben trotzdem ein besonderes Risiko

Dass auch ein aktuelles System betroffen sein kann, macht Updates nicht weniger wichtig.

Gerade bei Unternehmens- und Vereinswebsites begegnet mir häufig ein trügerischer Satz:

„Die Seite läuft doch.“

Eine Website kann optisch vollkommen funktionieren und technisch trotzdem längst überholt sein.

Typische Situationen sind:

das CMS wurde lange nicht aktualisiert,
Erweiterungen werden vom Hersteller nicht mehr gepflegt,
ein Theme oder Template benötigt eine veraltete PHP-Version,
alte Benutzerkonten existieren weiterhin,
frühere Dienstleister besitzen noch Zugänge,
Passwörter wurden mehrfach verwendet,
Backups existieren zwar, ihre Wiederherstellung wurde aber nie getestet.

Solche Websites können über Jahre scheinbar problemlos funktionieren.

Das bedeutet jedoch nicht, dass sie sicher sind.

Sicherheit braucht eine klare Zuständigkeit

Ein Punkt wird bei Websites häufig unterschätzt:

Wer kümmert sich eigentlich darum?

Für Texte, Bilder, Veranstaltungen oder Social Media gibt es in vielen Unternehmen und Vereinen eine zuständige Person. Bei der technischen Pflege einer Website ist die Verantwortung dagegen häufig weniger eindeutig.

Solange die Website funktioniert, beschäftigt sich niemand intensiver mit der Technik. Das ist nachvollziehbar – auf Dauer aber problematisch.

Für jede geschäftlich oder organisatorisch relevante Website sollte deshalb klar geregelt sein, wer mindestens folgende Aufgaben übernimmt:

CMS- und Sicherheitsupdates prüfen und installieren,
Erweiterungen, Themes und Templates kontrollieren,
nicht mehr benötigte Komponenten entfernen,
Benutzerkonten und Berechtigungen überprüfen,
Backups überwachen und Wiederherstellungen gelegentlich testen,
wichtige Funktionen und Links regelmäßig kontrollieren,
Auffälligkeiten bei Zugriffen oder Servermeldungen einordnen,
bei einem möglichen Sicherheitsvorfall reagieren oder fachkundige Unterstützung hinzuziehen.

Diese Aufgaben müssen nicht zwingend an einen externen Dienstleister vergeben werden.

Eine entsprechend eingewiesene Person innerhalb eines Unternehmens oder Vereins kann viele regelmäßige Kontrollen übernehmen. Wichtig ist, dass die Aufgabe tatsächlich vergeben ist und die betreffende Person weiß, worauf sie achten soll.

Fehlen Zeit oder technisches Wissen, kann die laufende Webseitenpflege auch an einen externen Dienstleister übertragen werden.

Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt Organisationen ebenfalls, Systeme regelmäßig auf Aktualität zu prüfen, Zuständigkeiten für Sicherheitsvorfälle festzulegen, Mitarbeitende vorzubereiten und Daten regelmäßig zu sichern.

Entscheidend ist weniger, wer die Website betreut, sondern dass sich jemand verantwortlich darum kümmert.

Was sollte unmittelbar nach einem Verdacht passieren?

Bei einer möglichen Kompromittierung ist schnelles Handeln wichtig.

Hektisches Handeln kann die spätere Untersuchung allerdings erschweren.

1. Die Situation zunächst begrenzen

Bei einem ernsthaften Verdacht sollte verhindert werden, dass die Website weiterhin Besucher gefährdet, Schadsoftware verteilt, Daten überträgt oder Nutzer auf schädliche Seiten weiterleitet.

Je nach Vorfall kann es sinnvoll sein, die Website vorübergehend vom öffentlichen Zugriff zu nehmen oder technisch einzuschränken.

2. Nicht sofort alle Spuren löschen

Vor dem Löschen sollten nach Möglichkeit der aktuelle Zustand, relevante Dateien und vorhandene Protokolle gesichert werden.

Diese Informationen können später helfen herauszufinden:

was verändert wurde,
wann Veränderungen erfolgt sind,
welche Dateien oder Daten betroffen waren,
welche ungewöhnlichen Zugriffe stattgefunden haben,
welcher Zugang möglicherweise verwendet wurde.

Wer sofort alles Verdächtige entfernt, kann gleichzeitig Hinweise auf den Angriffsweg vernichten.

3. Zugriffs- und Fehlerprotokolle sichern

Access-, Error- und weitere Serverprotokolle können bei der Untersuchung sehr hilfreich sein.

Viele Hosting-Pakete bewahren solche Informationen nur für einen begrenzten Zeitraum auf. Je früher ein Problem erkannt wird, desto größer ist deshalb die Chance, noch aussagekräftige Daten vorzufinden.

4. Nicht nur die sichtbare Manipulation suchen

Eine Website besteht nicht nur aus ihren öffentlich sichtbaren Seiten.

Je nach System und Vorfall sollten unter anderem geprüft werden:

Dateien auf dem Webspace,
Datenbank,
Administrations- und Benutzerkonten,
installierte Erweiterungen, Plugins oder Komponenten,
Themes beziehungsweise Templates,
Konfigurationsdateien,
Webserver-Regeln wie beispielsweise eine .htaccess,
geplante Aufgaben und Cronjobs,
Zugriffs- und Fehlerprotokolle,
Hosting-, SFTP- und Datenbankzugänge,
Domain- und DNS-Verwaltung,
weitere Anwendungen innerhalb desselben Hosting-Pakets.

Die sichtbar manipulierte Datei kann nur ein Symptom sein.

Warum das Löschen der gefundenen Schadstelle nicht reicht

Wenn ein fremder Code oder eine manipulierte Datei gefunden wird, liegt es nahe, diese zu entfernen und die Website wieder online zu stellen.

Damit ist aber noch nicht geklärt, wie die Manipulation möglich war.

Ein Angreifer kann beispielsweise weitere Dateien verändert, zusätzliche Benutzer angelegt oder eine Hintertür hinterlassen haben.

Deshalb müssen nach einer Kompromittierung mindestens zwei Fragen beantwortet werden:

Welche Veränderungen wurden vorgenommen?
Über welchen Weg konnten diese Veränderungen erfolgen und ist dieser Weg geschlossen?

Erst wenn beide Bereiche betrachtet wurden, lässt sich die Vertrauenswürdigkeit einer Installation sinnvoll beurteilen.

Warum ein automatisierter Scanner allein nicht genügt

Automatisierte Prüfungen können wertvolle Hinweise liefern.

Sie können je nach Prüfumfang beispielsweise ungewöhnliche externe Links, Weiterleitungen, technische Veränderungen, verdächtige Ressourcen oder andere Auffälligkeiten erkennen.

Sie beantworten aber nicht automatisch die entscheidenden Fragen:

Wie kam der Angreifer hinein?
Ist dieser Zugang inzwischen geschlossen?
Gibt es noch weitere manipulierte Dateien?
Existiert eine versteckte Hintertür?
Wurden Daten ausgelesen oder verändert?

Ein automatisierter Check ist deshalb ein Werkzeug zur Orientierung und möglichen Früherkennung.

Er ist kein Beweis dafür, dass eine Website sicher oder nicht kompromittiert ist.

Warum wir unseren Website-Schnellcheck weiterentwickelt haben

Die Erfahrungen mit kompromittierten Websites waren für mich auch ein Anlass, den BHV-media Website-Schnellcheck und die Technische Websiteprüfung weiterzuentwickeln.

Der Schnellcheck betrachtet heute neben klassischen technischen Themen auch mögliche Manipulations- und Integritätshinweise. Die ausführlichere technische Websiteprüfung untersucht den öffentlich erreichbaren Webauftritt über einen vollständigen Crawl und betrachtet dabei unter anderem externe Links, Weiterleitungen, neue Ressourcen und mögliche Kompromittierungsindikatoren.

Gerade die Fälle, in denen eine Manipulation erst nach dem Anklicken eines Links sichtbar wurde, zeigen, warum ein breiterer Blick auf eine Website sinnvoll sein kann.

Die Grenzen müssen dabei klar benannt werden.

Der Website-Schnellcheck ist eine nicht-invasive Ersteinschätzung öffentlich erreichbarer Informationen. Es werden keine Passwörter ausprobiert und keine Schwachstellen ausgenutzt.

Auch die umfassendere technische Websiteprüfung ist kein Penetrationstest und keine Malware-Forensik.

Versteckter Schadcode kann unauffällig bleiben. Manipulationen können nur unter bestimmten Bedingungen ausgelöst werden. Serverdateien, Datenbanken und geschützte Bereiche lassen sich von außen nicht vollständig beurteilen.

Ein unauffälliges Prüfergebnis bedeutet deshalb ausdrücklich nicht:

„Diese Website kann nicht kompromittiert sein.“

Der Check kann Auffälligkeiten sichtbar machen und einen Anlass für eine weitergehende Untersuchung liefern. Eine konkrete Verdachtslage muss anschließend fachlich und gegebenenfalls forensisch untersucht werden.

Einfach ein Backup einspielen?

Ein vorhandenes Backup ist im Ernstfall äußerst wertvoll.

Trotzdem sollte nicht automatisch das jüngste Backup wiederhergestellt werden.

Wenn eine Website heute erstmals sichtbar auffällig wird, kann die eigentliche Kompromittierung bereits Tage oder Wochen zurückliegen. Dann können auch Sicherungen bereits manipulierte Dateien enthalten.

Vor einer Wiederherstellung sollte deshalb möglichst geklärt werden:

Von wann stammt das Backup?
Wann könnte die Kompromittierung begonnen haben?
Sind Dateien und Datenbank vollständig enthalten?
Ist bekannt, ob das Backup bereits manipulierte Daten enthält?
Kann die Sicherung zunächst in einer getrennten Umgebung geprüft werden?
Wurde die Wiederherstellung grundsätzlich schon einmal getestet?

Das BSI betont ebenfalls die Bedeutung regelmäßiger Datensicherungen und einer vorbereiteten Wiederherstellung. Ein Backup hilft im Ernstfall nur, wenn es tatsächlich verwendet werden kann.

Ein gutes Backup ist deshalb nicht nur eine Kopie, sondern eine überprüfbare Wiederherstellungsmöglichkeit.

Zugangsdaten müssen mit betrachtet werden

Wenn ein Angreifer Änderungen an einer Website vornehmen konnte, muss auch geprüft werden, welche Zugangsdaten möglicherweise betroffen waren.

Dazu können gehören:

Administrationskonten des CMS,
Hosting-Konto,
SFTP- oder FTP-Zugänge,
Datenbankzugänge,
E-Mail-Konten,
Domain- und DNS-Verwaltung,
externe Dienste und technische Schnittstellen.

Betroffene oder potenziell kompromittierte Zugangsdaten sollten über ein vertrauenswürdiges Gerät erneuert werden.

Wo möglich, sollten unterschiedliche Zugangsdaten und eine Mehr-Faktor-Authentifizierung eingesetzt werden.

Ein neues Passwort im CMS hilft wenig, wenn beispielsweise der Hosting-Zugang weiterhin missbraucht werden kann.

Wann reicht eine Bereinigung – und wann ist ein Neuaufbau sinnvoller?

Nicht jede kompromittierte Website muss vollständig neu entwickelt werden.

Es gibt jedoch Situationen, in denen eine punktuelle Bereinigung technisch und wirtschaftlich kaum noch sinnvoll ist.

Ein Neuaufbau sollte insbesondere geprüft werden, wenn:

das CMS oder wesentliche Erweiterungen nicht mehr unterstützt werden,
der Zeitpunkt der Kompromittierung nicht nachvollziehbar ist,
kein vertrauenswürdiger sauberer Ausgangszustand vorhanden ist,
zahlreiche Dateien verändert wurden,
mehrere Hintertüren oder unbekannte Komponenten gefunden werden,
die vorhandene Installation technisch kaum noch nachvollziehbar ist,
die Server- oder PHP-Basis ohnehin modernisiert werden müsste.

Dann kann die vermeintlich schnelle Reparatur am Ende aufwendiger sein als ein kontrollierter Neuaufbau.

Vor allem bleibt bei einer nur teilweise verstandenen Kompromittierung immer eine unangenehme Frage:

Was haben wir möglicherweise noch nicht gefunden?

Bei einem Neuaufbau nicht einfach alles übernehmen

Auch bei einem Neuaufbau besteht ein Risiko.

Wer den gesamten alten Webspace unverändert auf ein neues System kopiert, kann unbemerkt genau die Dateien oder Komponenten übernehmen, die zuvor Bestandteil des Problems waren.

Ein sauberer Neuaufbau sollte deshalb auf einer vertrauenswürdigen und aktuellen Basis beginnen.

Anschließend werden nur tatsächlich benötigte und geprüfte Inhalte, Daten und Komponenten übernommen.

Das ist gleichzeitig eine gute Gelegenheit, nicht mehr benötigte Erweiterungen zu entfernen.

Weniger unnötige Software bedeutet weniger Wartungsaufwand und in der Regel auch eine kleinere Angriffsfläche.

Was ist mit personenbezogenen Daten?

Eine kompromittierte Website ist nicht ausschließlich ein technisches Problem.

Wenn über die Website personenbezogene Daten verarbeitet werden, muss geprüft werden, ob auf diese Daten unbefugt zugegriffen werden konnte oder ob sie verändert beziehungsweise offengelegt wurden.

Dazu können beispielsweise gehören:

Kontaktformular-Anfragen,
Kundenkonten,
Mitgliederdaten,
Bestellungen,
Newsletter-Daten,
Bewerbungen,
interne oder geschützte Dokumente.

Nach Artikel 33 DSGVO muss eine Verletzung des Schutzes personenbezogener Daten grundsätzlich unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde gemeldet werden, sofern die Verletzung voraussichtlich nicht ohne Risiko für die Rechte und Freiheiten natürlicher Personen bleibt.

Bei einem voraussichtlich hohen Risiko kann nach Artikel 34 DSGVO zusätzlich eine Information der betroffenen Personen erforderlich sein.

Ob diese Voraussetzungen im konkreten Fall erfüllt sind, muss individuell geprüft werden.

Eine technische Bereinigung ersetzt diese datenschutzrechtliche Bewertung nicht.

Was kann vorbeugend getan werden?

Eine hundertprozentige Sicherheit gibt es nicht.

Das Risiko lässt sich aber deutlich reduzieren – und ein möglicher Vorfall kann schneller erkannt werden.

Für eine verantwortungsvoll betriebene CMS-Website gehören aus meiner Sicht mindestens folgende Punkte dazu:

CMS regelmäßig aktualisieren,
Sicherheitsupdates zeitnah installieren,
Erweiterungen, Plugins, Komponenten, Themes und Templates aktuell halten,
nicht mehr benötigte Erweiterungen vollständig entfernen,
nur aktiv gepflegte Komponenten einsetzen,
PHP und Serverumgebung aktuell halten,
Administrationsrechte auf tatsächlich benötigte Personen begrenzen,
getrennte Benutzerkonten verwenden,
Mehr-Faktor-Authentifizierung einsetzen, wo sie verfügbar ist,
sichere und unterschiedliche Zugangsdaten verwenden,
regelmäßige externe Backups erstellen,
die Wiederherstellung von Backups testen,
die Website regelmäßig selbst aufrufen und benutzen,
Navigation, Links und Formulare stichprobenartig kontrollieren,
Zugriffszahlen und Servermeldungen auf ungewöhnliche Veränderungen beobachten,
bei Auffälligkeiten Access- und Error-Logs prüfen,
eine verantwortliche Person für die technische Pflege benennen.

Der letzte Punkt ist aus meiner Sicht besonders wichtig.

Technische Pflege darf keine Aufgabe sein, von der alle annehmen, dass sich schon jemand darum kümmern wird.

Updates sind notwendig – aber nicht die ganze Lösung

Eine der wichtigsten Erkenntnisse aus unseren bisherigen Fällen lautet:

Aktualisieren ist notwendig. Beobachten aber ebenso.

Eine veraltete Installation erhöht vermeidbare Risiken.

Eine aktuelle Installation ist trotzdem kein Grund, sich in vollständiger Sicherheit zu wiegen.

Die Sicherheitsmeldungen von Joomla! und WordPress aus dem Jahr 2026 machen deutlich, warum: Selbst aktiv gepflegte Software erhält regelmäßig neue Sicherheitskorrekturen. „Aktuell“ ist deshalb kein Zustand, den man einmal erreicht und anschließend abhaken kann.

Websites sind öffentlich erreichbare Systeme. Sie werden permanent von Suchmaschinen, Bots, automatisierten Scannern und auch Angreifern aufgerufen.

Wer die eigene Website regelmäßig kontrolliert, Links tatsächlich anklickt, technische Auffälligkeiten ernst nimmt und ungewöhnlichen Zugriffszahlen nachgeht, erhöht die Chance, ein Problem frühzeitig zu bemerken.

Genau das hat uns bei den bisher untersuchten Fällen geholfen.

Fazit: Eine Website braucht nicht nur Updates, sondern Verantwortung

Wenn eine Website gehackt wurde, ist die Versuchung groß, möglichst schnell die sichtbaren Schäden zu beseitigen und die Seite wieder online zu stellen.

Doch Sicherheit beginnt wesentlich früher.

Eine Website benötigt nicht nur Updates, sondern laufende Aufmerksamkeit.

Jemand muss zuständig sein.

Das kann eine entsprechend eingewiesene Person im eigenen Unternehmen oder Verein sein. Es kann ebenso ein externer Dienstleister sein.

Wichtig ist, dass regelmäßig geprüft wird, ob die Website technisch gepflegt ist und ob etwas Ungewöhnliches passiert.

Kommt es tatsächlich zu einem Sicherheitsvorfall, sollte strukturiert vorgegangen werden:

Angriff begrenzen. Zustand und Protokolle sichern. Ursache untersuchen. Zugänge prüfen. Manipulationen vollständig beseitigen oder eine vertrauenswürdige Basis neu aufbauen. Backups überprüfen. Datenschutzfragen klären. Erst anschließend wieder veröffentlichen.

Und vielleicht ist die wichtigste Erkenntnis aus unseren eigenen Erfahrungen:

Nicht nur alte Websites können betroffen sein.

Updates reduzieren Risiken.

Aufmerksamkeit hilft dabei, Probleme rechtzeitig zu erkennen.

Klare Zuständigkeiten sorgen dafür, dass beides tatsächlich passiert.

Häufige Fragen

Ist eine aktuelle CMS-Website automatisch sicher?

Nein. Ein aktueller Softwarestand schließt bekannte Sicherheitslücken und ist ein wichtiger Bestandteil der Absicherung. Eine Website besteht aber zusätzlich aus Erweiterungen, Themes beziehungsweise Templates, Benutzerkonten, Zugangsdaten, Servertechnik und weiteren Komponenten. Außerdem können auch für aktuelle Software später neue Sicherheitslücken bekannt werden.

Warum betrafen die beschriebenen Fälle Joomla!?

Joomla! ist das von BHV-media bevorzugt eingesetzte Content-Management-System. Entsprechend basiert ein großer Teil der betreuten Websites darauf. Die beobachtete Häufung erlaubt deshalb keine Aussage darüber, dass Joomla! grundsätzlich unsicherer als andere CMS wäre. Die konkreten Fälle betrafen Joomla! 4, 5 und 6.

Können auch aktuelle CMS-Versionen betroffen sein?

Ja. Auch aktuelle Software kann später Sicherheitskorrekturen benötigen. Zusätzlich kann ein Angriff über Erweiterungen, Zugangsdaten, Hosting, Serverkonfiguration oder andere Komponenten erfolgen. Die Ursache muss im konkreten Fall untersucht werden.

Gibt es solche Sicherheitsprobleme auch bei WordPress?

Ja. WordPress veröffentlichte 2026 mehrere Sicherheitsupdates. Im Juli 2026 wurde mit WordPress 7.0.2 unter anderem ein kritisches Sicherheitsproblem behoben; im September folgte WordPress 7.1.1 mit elf Sicherheitskorrekturen. Das zeigt, dass laufende Sicherheitsupdates grundsätzlich zum Betrieb moderner Content-Management-Systeme gehören.

Kann eine gehackte Website vollkommen normal aussehen?

Ja. Manipulationen können nur einzelne Links, bestimmte Besucher oder bestimmte Aufrufwege betreffen. Schädliche Weiterleitungen können beispielsweise abhängig vom Referrer, Browser oder Gerät ausgelöst werden. Deshalb sollte eine Website nicht nur angesehen, sondern regelmäßig auch tatsächlich benutzt werden.

Ist ungewöhnlich hoher Website-Traffic ein Zeichen für einen Angriff?

Nicht automatisch. Suchmaschinen, legitime Bots, Kampagnen oder ein erfolgreicher Beitrag können ebenfalls hohe Zugriffszahlen verursachen. Ein ungewöhnlicher Anstieg ist aber ein sinnvoller Anlass, die aufgerufenen URLs sowie Access- und Error-Logs genauer zu betrachten.

Wie oft sollte eine Unternehmens- oder Vereinswebsite kontrolliert werden?

Dafür gibt es kein allgemeingültiges Intervall. Entscheidend ist, dass Kontrollen regelmäßig stattfinden und eine Person dafür verantwortlich ist. Sicherheitsupdates sollten unabhängig davon zeitnah geprüft und eingespielt werden.

Muss die technische Pflege ein externer Dienstleister übernehmen?

Nein. Viele regelmäßige Kontrollen können von entsprechend eingewiesenen Personen im Unternehmen oder Verein übernommen werden. Fehlen Zeit oder technisches Wissen, kann die laufende Betreuung an einen externen Dienstleister vergeben werden.

Erkennt der BHV-media Website-Schnellcheck sicher, ob eine Website gehackt wurde?

Nein. Der Website-Schnellcheck kann mögliche Manipulations- und Integritätshinweise erkennen und damit einen Anlass für eine genauere Prüfung liefern. Er ist jedoch kein Penetrationstest und keine Malware-Forensik. Auch ein unauffälliges Ergebnis kann eine Kompromittierung deshalb nicht sicher ausschließen.

Reicht es, eine gefundene manipulierte Datei zu löschen?

Nicht unbedingt. Es können weitere Dateien verändert, zusätzliche Benutzer angelegt oder Hintertüren eingerichtet worden sein. Zusätzlich muss geklärt werden, über welchen Weg der Zugriff möglich war und ob dieser Weg geschlossen wurde.

Kann ich einfach ein Backup wiederherstellen?

Nur wenn ausreichend sicher ist, dass das Backup vollständig und aus einem vertrauenswürdigen Zustand stammt. Auch Sicherungen können bereits manipulierte Dateien oder Daten enthalten.

Muss ein Website-Hack der Datenschutzbehörde gemeldet werden?

Nicht jeder Angriff ist automatisch meldepflichtig. Entscheidend ist, ob eine Verletzung des Schutzes personenbezogener Daten vorliegt und welches Risiko daraus für betroffene Personen entsteht. Artikel 33 und 34 DSGVO regeln die entsprechenden Melde- und Informationspflichten.

Quellen und weiterführende Informationen

Die genannten Sicherheitsmeldungen und Versionsangaben entsprechen dem Redaktionsstand vom 21. September 2026. Sicherheitslagen, unterstützte Softwareversionen und verfügbare Updates können sich kurzfristig ändern. Die Hinweise in diesem Beitrag sind eine allgemeine fachliche Einordnung und ersetzen keine individuelle Sicherheitsanalyse, Malware-Forensik, Datenschutz- oder Rechtsberatung.

Hinweis zur Erstellung: Bei der Recherche, Strukturierung und sprachlichen Überarbeitung dieses Beitrags wurde künstliche Intelligenz als Hilfsmittel eingesetzt. Die fachliche Einordnung, Auswahl der Inhalte, Bewertung und Verantwortung liegen bei Thomas Lindenau und BHV-media.