Wie die Lücke entsteht
Eine Kleinigkeit an der eigenen Website ändern - eine Telefonnummer, ein Preis, ein Satz im Impressum. Früher hieß das: Dienstleister anschreiben, Termin abwarten, Rechnung bezahlen. Heute erledigt ein KI-Assistent das in zehn Minuten, und die Versuchung, es selbst zu machen, ist entsprechend groß. Meistens geht das auch gut.
Der Assistent arbeitet dabei sogar sorgfältig. Bevor er die Datei ändert, legt er eine Sicherungskopie an - genau so, wie es ein vorsichtiger Mensch täte. Dann ändert er die Datei, prüft sie, testet das Ergebnis. Die Website läuft.
Nur liegt die Kopie an derselben Stelle wie das Original: im Webroot, also in dem Verzeichnis, aus dem der Webserver Dateien direkt an Besucher ausliefert. Sie heißt dann etwa index.php.bak-2026-08-14. Wer diese Adresse im Browser aufruft, bekommt je nach Serverkonfiguration keine Fehlermeldung, sondern den Quelltext der Datei geliefert.
Auffallen kann das niemandem. An der Website hat sich sichtbar nichts geändert, die zusätzliche Datei ist von keiner Seite verlinkt und steht in keinem Menü. Wer sie nicht gezielt sucht, findet sie nicht. Es sucht nur leider jemand.
Warum die Kopie gefährlicher ist als das Original
Ruft jemand eine Adresse wie /index.php auf, führt der Server das Programm aus und schickt nur das Ergebnis: die fertige Seite. Den PHP-Quelltext selbst bekommt ein Besucher bei korrekt konfiguriertem Server normalerweise nicht zu sehen.
Bei /index.php.bak kann das anders ausgehen. Die Endung .bak ist für den Server üblicherweise kein Programm, das er ausführt. Je nach Konfiguration liefert er die Datei stattdessen aus wie ein Bild oder ein PDF - als Text, vollständig lesbar.
In solchen Dateien kann mehr als Programmlogik stehen: Zugangsdaten, API-Schlüssel oder interne Adressen. Und selbst wenn keine Geheimnisse enthalten sind, verrät der Quelltext Aufbau und Funktionsweise der Anwendung. Das ist der Anfang eines Angriffs, nicht sein Ende.
Neu ist das Problem nicht. Die OWASP-Richtlinien, an denen sich die Branche bei Sicherheitsprüfungen orientiert, führen alte, vergessene und gesicherte Dateien im Webverzeichnis seit Jahren als eigene Prüfkategorie.
Danach wird gesucht, und zwar dauerhaft
Wir werten die automatisierten Zugriffe auf unsere eigenen Server aus und führen darüber eine Statistik: welcher Pfad abgefragt wird, mit welcher Kennung und wie oft. So werden typische Scanmuster und neue Angriffsziele sichtbar.
Der Teil, der ausschließlich auf Sicherungen und Datenbankauszüge zielt, umfasst mehrere hundert verschiedene Pfade und einige tausend Anfragen - allein seit Februar 2026.
Das sind keine Zufallstreffer, sondern abgearbeitete Listen. Immer wieder dieselben Namen:
- /wp-config.php.bak und /wp-config.php.old - die Konfigurationsdatei von WordPress, in der der Datenbank-Zugang steht
- /config.php.bak, /configuration.php.bak, /settings.php.bak - dieselbe Idee für andere Systeme
- /.env.bak - die Datei, in der viele moderne Anwendungen ihre Passwörter und Schlüssel ablegen
- /backup.zip, /backup.tar.gz, /dump.sql, /database.sql - komplette Archive und Datenbankauszüge
- /wp-config.php.swp - die unsichtbare Arbeitsdatei, die ein Texteditor beim Bearbeiten anlegt und nach einem Absturz zurücklässt
Wie sich solche Anfragen tarnen
Ein Teil dieser Zugriffe meldet sich mit einer Kennung, die nach einer seriösen Suchmaschine oder einem bekannten Dienst aussieht. Das ist billig zu fälschen und sagt nichts aus.
Deshalb bewerten wir einen Zugriff danach, was er anfragt, und nicht danach, wie er sich nennt. Wer der Reihe nach Sicherungsdateien durchprobiert, ist kein Crawler, egal was in der Kennung steht.
Nicht der Assistent ist das Problem, sondern der Ort
Vor einer Änderung zu sichern, ist richtig. Falsch ist allein die Stelle. Dieselbe Kopie in einem Verzeichnis neben der Website ist von außen nie erreichbar und erfüllt denselben Zweck.
Noch besser ist meistens: gar keine zusätzliche Datei. Wo ein Projekt in einer Versionsverwaltung liegt, ist der alte Stand ohnehin gespeichert und mit einem Befehl zurückgeholt. Die Kopie daneben löst dann ein Problem, das schon gelöst ist, und schafft ein neues.
Neu ist an all dem nicht der Fehler, sondern das Tempo. Ein KI-Assistent führt in wenigen Minuten Dutzende Befehle aus, ändert Dateien, legt Zwischenstände an - und räumt sie nicht zwingend wieder weg. Was einem Menschen vielleicht einmal im Jahr passiert, kann hier an einem Nachmittag mehrfach passieren. Wer die Änderung selbst macht, sieht davon nichts: Der Assistent berichtet, dass alles funktioniert, und das stimmt ja auch.
Die Regel, die daraus folgt
Für die Arbeit mit KI-Assistenten kursieren viele Regeln zur Codequalität: keine Zugangsdaten ins Projekt schreiben, Änderungen klein halten, Tests laufen lassen, bestehende Struktur respektieren. Eine Betriebsregel gehört aus unserer Sicht zwingend dazu:
Im öffentlich erreichbaren Verzeichnis einer Website entsteht keine Datei, die dort nicht hingehört. Keine Sicherungen, keine Zwischenstände, keine Archive. Ein Webverzeichnis ist kein Arbeitsplatz.
Weil sich niemand dauerhaft zu hundert Prozent an Regeln hält - Mensch wie Maschine - sichern wir das auf den Servern, die wir betreuen, zusätzlich technisch ab:
- Der Webserver blockiert bereits mehrere typische Sicherungs- und Konfigurationsdateien, etwa mit den Endungen .bak, .old und .sql.
- Zusätzlich sucht ein regelmäßiger Prüflauf nach weiteren verdächtigen Dateitypen - Endungen wie .orig, .save, .swp, .zip oder .tar.gz, und Namen, die eine blockierte Endung um ein Datum ergänzen.
- Rückbau läuft über die Versionsverwaltung, nicht über Kopien im Verzeichnis.
Was das für Ihre Website heißt
Der Fall ist nicht auf KI-Assistenten beschränkt. Solche Dateien bleiben genauso nach einem Serverumzug liegen, nach einem Theme-Wechsel, nach einer schnellen Korrektur per FTP - oder weil eine Agentur vor Jahren sicherheitshalber ein Archiv der alten Seite abgelegt hat. Sie stören niemanden, sie fallen nicht auf, und deshalb schaut auch niemand mehr nach.
Die Prüfung selbst dauert Minuten. Wer Zugriff auf den Server hat, durchsucht das Website-Verzeichnis nach den genannten Endungen. Wer keinen Zugriff hat, ruft einige der oben genannten Adressen einfach im Browser auf: Erscheint Text statt einer Fehlermeldung, ist die Datei öffentlich.
Gegen die eigene Änderung mit KI-Hilfe spricht nichts. Man sollte nur wissen, wonach man hinterher schaut - und dass der Assistent selbst diese Frage nicht stellt. Auf den Servern, die wir betreuen, läuft dieser Suchlauf regelmäßig und meldet derzeit nichts. Ein Scanner probiert es trotzdem weiter. Er braucht nur einmal eine Antwort.