/wp-admin/install.php in WordPress richtig absichern

Jede WordPress-Installation bringt eine Datei namens wp-admin/install.php mit. In einer gesunden Installation ist sie weitgehend harmlos. WordPress erkennt, dass die Seite bereits eingerichtet ist, und zeigt eine kurze "Bereits installiert"-Meldung an. Es gibt aber einen Edge Case, den viele Seitenbetreiber unterschätzen. Sobald mit der Datenbank etwas schiefläuft, wird aus genau dieser Datei ein voll funktionsfähiger Setup-Assistent. Ein Angreifer, der zum richtigen Zeitpunkt auf die Datei stößt, kann WordPress einfach neu über deine Domain installieren, auf eine eigene Datenbank zeigen lassen, und hat damit die komplette Seite übernommen.

Diese Anleitung erklärt, wann install.php wirklich gefährlich ist, welche Security-Plugins diesen Fall tatsächlich abdecken (nicht alle tun das, egal was auf der Plugin-Seite steht) und wie du die Datei sauber blockierst. Auch im weniger komfortablen Fall, dass du auf einem Shared Host ohne Zugriff auf die Server-Config unterwegs bist.

Wann ist install.php wirklich ein Problem?

Wenn du auf einer gesunden Seite https://deinedomain.de/wp-admin/install.php aufrufst, prüft WordPress zunächst, ob in der Tabelle wp_options bereits ein siteurl-Wert steht. Wenn ja, landest du auf der "Bereits installiert"-Seite und die Sache ist erledigt. Kein Formular, kein Handlungsspielraum, kein Takeover.

Das Problem beginnt genau in dem Moment, in dem WordPress diesen Wert nicht lesen kann. Typische Szenarien:

• Die Datenbank-Zugangsdaten in der wp-config.php sind kaputt (falsches Passwort nach einem Umzug, Tippfehler im DB-Namen).


• Jemand hat die Tabelle wp_options gedroppt oder geleert, entweder versehentlich bei einer Migration oder gezielt durch eine SQL-Injection in einem unsicheren Plugin.


• Ein abgebrochener Staging-Klon hat das Dateisystem stehen lassen, aber die DB ist leer.


• Der Datenbank-User hat die Rechte auf bestimmte Tabellen verloren.

In all diesen Fällen ist der Setup-Assistent für jeden im Internet erreichbar. Wer zuerst drauf klickt, darf Admin-Benutzername, Passwort und E-Mail festlegen, und besitzt damit faktisch die Domain. Genau deshalb gibt es den install.php-Check in InspectWP, auch wenn die Datei auf jeder WordPress-Installation ganz "normal" vorhanden ist.

Welche Security-Plugins schützen install.php wirklich?

Das ist der Punkt, an dem die meisten Leute stolpern. Man nimmt intuitiv an, dass jedes WordPress-Security-Plugin install.php automatisch abdeckt. Das stimmt nur zur Hälfte. Die Antwort hängt davon ab, wie das Plugin geladen wird.

Ein reguläres WordPress-Plugin startet innerhalb von WordPress. Es braucht die Datenbank, um überhaupt anzulaufen. Wenn deine DB kaputt oder leer ist (und das ist das einzig realistische Szenario, in dem install.php gefährlich wird), kommt WordPress gar nicht so weit, das Plugin zu laden. Der Request landet direkt bei install.php, und PHP rendert fröhlich den Setup-Assistenten. Security-Plugins, die als normale Plugins laufen, können in diesem Fall per Definition nichts tun.

Einige Plugins nutzen aber einen PHP-Mechanismus namens auto_prepend_file. Die Direktive weist PHP an, eine bestimmte Datei vor jedem anderen PHP-Skript auf dem Server auszuführen. Wenn sich ein Security-Plugin so registriert, läuft es vor wp-config.php, bevor die Datenbankverbindung überhaupt versucht wird, und damit auch vor install.php. Es hat seine eigenen Konfigurationsdateien und, falls nötig, eine eigene DB-Verbindung. Eine defekte WordPress-Installation beeinflusst es nicht.

Plugins, die diesen Modus unterstützen (und install.php damit auch bei kaputter WordPress-Datenbank schützen können):

• Wordfence im Extended Protection-Modus (teilweise auch Optimized Mode genannt). Das ist nicht der Standard nach der Installation. Du musst ihn explizit in den Firewall-Einstellungen aktivieren. Danach liegt eine Datei namens wordfence-waf.php im WordPress-Root und wird per .htaccess, .user.ini oder php.ini registriert.


• NinjaFirewall (WP Edition). Nutzt auto_prepend_file als Standardmodus. Ist bereits bei der Installation so konfiguriert, kein extra Schalter nötig.


• NinjaFirewall (Pro / Full WAF). Gleicher Mechanismus, aber auf Server-Ebene registriert. Läuft komplett außerhalb von WordPress.


• BitFire Security. Bietet einen "Always On Protection"-Modus, ebenfalls auf Basis von auto_prepend_file. Funktional vergleichbar mit Wordfence Extended Protection.


• Shield Security (ShieldPRO). Lädt ebenfalls per auto_prepend_file, geht dabei allerdings etwas konservativer vor und fasst .htaccess nicht direkt an.


• MalCare. Nutzt auto_prepend_file als Teil seines WAF-Setups.

Plugins, die install.php nicht blockieren können, wenn WordPress nicht mehr startet, weil sie als normale WordPress-Plugins laufen:

• Wordfence im Standard-Basic Mode (bevor du Extended Protection aktivierst).


• Solid Security (früher iThemes Security). Bringt keine WAF mit, die vor WordPress läuft.


• All-In-One WP Security & Firewall. Gut bei Datei- und Login-Hardening, läuft aber innerhalb von WordPress.


• Die meisten Plugin-basierten Firewalls, die nicht auf auto_prepend_file setzen.

Ganz praktisch: Wenn du Wordfence einsetzt, geh in Wordfence, Firewall, Manage WAF und prüf, ob dort "Optimized" bzw. "Extended Protection Enabled" steht. Steht da noch "Basic Mode", führt dich der Optimization-Wizard durch das Einrichten von auto_prepend_file für deinen Server. Diese eine Änderung ist das, was Wordfence von einem reaktiven Plugin zu einer echten Pre-WordPress-Firewall macht.

Ein Caveat gilt für beide Wege. Der Mechanismus funktioniert nur, wenn dein Host auto_prepend_file per .htaccess, .user.ini oder php.ini überhaupt erlaubt. Bei den meisten Shared-Hostern ist das out of the box der Fall. Bei einzelnen stark abgeschotteten Managed-Hostern ist die Direktive gesperrt, und der Optimization-Wizard scheitert oder zeigt eine Warnung. In dem Fall bleibt dir nur der Weg über Webserver-Regeln, siehe unten.

Option 1: install.php per .htaccess blockieren (Apache)

Wenn dein Hoster Apache einsetzt (das ist bei den meisten Shared-Hostern wie IONOS, Strato, All-Inkl, Hostinger, DomainFactory, SiteGround der Fall), kannst du folgenden Block in die .htaccess im WordPress-Wurzelverzeichnis eintragen:

<Files "install.php">
  Require all denied
</Files>

Das funktioniert ab Apache 2.4, und das läuft seit Jahren bei praktisch jedem Hoster. Falls du noch auf einer älteren Version unterwegs bist (Apache 2.2), nimm stattdessen die alte Syntax:

<Files "install.php">
  Order allow,deny
  Deny from all
</Files>

Trag den Block oberhalb der # BEGIN WordPress-Marke ein, damit die automatische Rewrite-Verwaltung von WordPress ihn bei Updates in Ruhe lässt.

Nach dem Speichern rufst du https://deinedomain.de/wp-admin/install.php in einem privaten Browserfenster auf. Du solltest eine 403 Forbidden-Antwort bekommen. Wenn du trotzdem noch die "Bereits installiert"-Seite siehst, sind .htaccess-Overrides auf deinem Host abgeschaltet. Dann geht es bei Option 3 weiter.

Option 2: install.php per nginx blockieren

Auf nginx gibt es keine .htaccess. Wenn du deinen Server selbst verwaltest (VPS, Root-Server oder ein flexibler Hoster wie Hetzner Cloud), trägst du folgendes in den server-Block deiner Seite ein:

location = /wp-admin/install.php {
  deny all;
  return 403;
}

Mit sudo nginx -t && sudo systemctl reload nginx nginx neu laden und mit curl -I https://deinedomain.de/wp-admin/install.php testen. Du solltest ein 403 bekommen.

Manche Managed-Hoster, die unter der Haube nginx verwenden (z.B. Raidboxes, Kinsta, WP Engine), haben solche Regeln bereits ab Werk aktiv. Ein Blick in die Doku des Hosters oder ein kurzes Support-Ticket lohnt sich. Die Antwort ist meistens entweder "ist schon abgedeckt" oder sie tragen die Regel für dich ein.

Option 3: Shared Hosting ohne .htaccess-Unterstützung

Wenn du auf einem Shared-nginx-Host bist und .htaccess dort ignoriert wird, hast du weniger Optionen, bist aber nicht völlig aufgeschmissen. Sortiert nach Empfehlung:

1. Eine der oben genannten Pre-WordPress-Firewalls installieren. Auf Shared-Hosts, die auto_prepend_file erlauben, gibt dir ein Plugin wie NinjaFirewall oder Wordfence mit aktivierter Extended Protection denselben Schutz wie eine Server-Regel, ganz ohne in die Server-Config einzugreifen. Oft der pragmatischste Weg.


2. Hoster fragen. Die meisten Managed-WordPress-Hoster tragen eine Server-Regel auf Anfrage ein. Das dauert auf deren Seite fünf Minuten und gehört bei denen zum Tagesgeschäft.


3. Dateiinhalt ersetzen. Du kannst wp-admin/install.php per SFTP öffnen und den kompletten Inhalt durch eine einzige Zeile ersetzen:
   

   <?php // absichtlich deaktiviert, siehe install.php.bak

   
   Das Original (install.php.bak) legst du dir irgendwo außerhalb des öffentlichen Web-Verzeichnisses ab, falls du mal wirklich neu installieren musst. Nachteil: WordPress-Core-Updates stellen die Originaldatei wieder her, du musst also nach jedem größeren Update nachsteuern. Ein kleines Must-Use-Plugin kann das automatisieren (siehe das zugehörige Code-Snippet).


4. Zugriff per Dateirechte verweigern. Die Dateirechte auf 000 setzen (per SFTP) blockiert den Zugriff auf den meisten Hosts. Selber Haken wie oben: Core-Updates setzen das zurück.

Was ist mit Umbenennen oder Löschen?

Technisch kannst du die install.php einfach löschen. WordPress braucht sie im Normalbetrieb nicht. Sie wird nur beim ersten Setup und bei einigen internen Upgrade-Routinen verwendet. Der Haken ist, dass die Datei bei jedem WordPress-Core-Update wiederhergestellt wird. Löschen ist also keine dauerhafte Lösung. Zusätzlich kann der Auto-Upgrade-Prozess gelegentlich auf die Datei verweisen, was dann Warnungen im Error-Log produziert.

Umbenennen ist sogar noch schlechter. WordPress findet die Datei unter dem neuen Namen nicht mehr, legt aber beim nächsten Update brav das Original neu an. Du hast dann plötzlich zwei Kopien.

Den Zugriff auf Webserver-Ebene zu blockieren, oder eine Pre-WordPress-Firewall zu nutzen, ist fast immer die sauberere Lösung.

Wie du prüfst, ob es funktioniert hat

Nachdem du eine der obigen Optionen eingerichtet hast:

1. Öffne https://deinedomain.de/wp-admin/install.php in einem privaten Browserfenster.


2. Du solltest eine 403 Forbidden-Seite sehen (oder 404, falls du die Datei entfernt hast, oder die Block-Seite deines Firewall-Plugins).


3. Wenn du stattdessen die "Bereits installiert"-Seite oder, im schlimmsten Fall, ein echtes Setup-Formular siehst, greift die Regel nicht. Dateipfad prüfen, alle Caches leeren (Cloudflare, Varnish, serverseitiges Page-Caching) und erneut testen.


4. Starte einen neuen InspectWP-Scan. Der Check "install.php exponiert" im WordPress-Bereich sollte auf grün wechseln.

Was du gleich mit absichern solltest

Wenn du gerade schon dabei bist, die Seite abzuhärten: Dieselbe Art von Webserver-Regel (oder Pre-WordPress-Firewall-Regel) lohnt sich auch für ein paar andere sensible Endpunkte. xmlrpc.php (falls du es nicht aktiv verwendest), wp-config.php.bak, .git/, .env und sämtliche phpinfo.php-Dateien, die ein Entwickler vielleicht mal vergessen hat. InspectWP markiert all diese Sachen automatisch im Sicherheits-Bereich.

Der Fall install.php ist ein gutes Beispiel für Defense in Depth. WordPress schützt sich selbst, ein richtig konfiguriertes Security-Plugin legt eine weitere Ebene drüber, und eine Webserver-Regel deckt den einen Fall ab, in dem beide vorigen ausfallen können. Such dir die Kombination aus, die zu deinem Host passt. Fünf Zeilen Config, oder ein Schalter im Firewall-Plugin, reichen aus, um die Lücke endgültig zu schließen.