1. Start
  2. /
  3. CMS ADMINS Security Check...
  4. /
  5. PHP im Uploads-Ordner blo...

PHP im Uploads-Ordner blockieren: Apache und nginx

Wenn Ihr Server PHP-Dateien im Uploads-Ordner ausführt, wird aus jeder Upload-Lücke eine komplette Website-Übernahme. Ein Konfigurationsblock in Apache oder nginx stellt das ab. Diese Anleitung zeigt beide Varianten und wie Sie das Ergebnis testen.

Von den 60 Prüfungen in unserem Plugin Security Check Report gibt es eine, die wir bei jedem Wartungskunden zuerst ansehen: Führt der Server PHP-Dateien im Uploads-Ordner aus? Die Antwort entscheidet darüber, ob eine einzelne Upload-Lücke in einem Plugin ein Ärgernis bleibt oder zur vollständigen Übernahme der Website wird.

Die Angriffskette, Schritt für Schritt

WordPress selbst verhindert den Upload von PHP-Dateien über die Mediathek. Das Problem sind die Erweiterungen. Formular-Plugins, Bild-Uploader, Import-Funktionen in Themes: Überall, wo Dateien entgegengenommen werden, kann ein Programmierfehler stecken, der die Dateiendung nicht sauber prüft. Solche Lücken tauchen regelmäßig in verbreiteten Plugins auf.

Die Kette läuft dann so ab:

  1. Der Angreifer findet eine Upload-Funktion, die sich austricksen lässt, und lädt eine Datei namens shell.php hoch. Sie landet, wie fast alle Uploads in WordPress, unter /wp-content/uploads/2026/09/shell.php.
  2. Der Uploads-Ordner ist per Design öffentlich erreichbar. Der Angreifer ruft die Datei direkt im Browser auf: https://ihre-domain.de/wp-content/uploads/2026/09/shell.php.
  3. Führt der Server die Datei aus, läuft ab diesem Moment fremder Code mit den Rechten des Webservers. Eine solche Webshell kann die wp-config.php samt Datenbank-Zugangsdaten lesen, Admin-Konten anlegen, Schadcode in Theme-Dateien schreiben und sich in andere Sites auf demselben Hosting-Account ausbreiten.

Der entscheidende Punkt: Schritt 1 können Sie nicht vollständig verhindern, solange Sie Plugins mit Upload-Funktionen einsetzen. Schritt 3 können Sie verhindern, mit einer einzigen Server-Einstellung. Genau deshalb ist das die wirksamste einzelne Härtungsmaßnahme für WordPress: Sie macht eine ganze Angriffsklasse wertlos. Eine hochgeladene shell.php, die der Server nicht ausführt, ist nur noch eine Textdatei.

Warum der Uploads-Ordner nie PHP ausführen muss

Der Ordner /wp-content/uploads/ ist für Medien da: Bilder, PDFs, Videos. WordPress legt dort im Normalbetrieb keinen einzigen ausführbaren Code ab. Es gibt also keinen legitimen Grund, warum der Webserver dort jemals eine PHP-Datei ausführen sollte. Das macht die Sperre so angenehm: Sie hat praktisch keine Nebenwirkungen. Bilder und Downloads funktionieren weiter wie bisher.

Apache: .htaccess im Uploads-Ordner

Legen Sie im Ordner /wp-content/uploads/ eine Datei namens .htaccess mit diesem Inhalt an:

# PHP-Ausfuehrung in diesem Ordner blockieren
<FilesMatch ".(php|phar|phtml|php3|php4|php5|php7|php8)$">
    Require all denied
</FilesMatch>

Der FilesMatch-Block greift bei allen Dateiendungen, unter denen PHP-Code typischerweise ausgeführt wird, nicht nur bei .php. Die Direktive Require all denied ist die Syntax für Apache ab Version 2.4, die seit Jahren Standard ist. Jeder direkte Aufruf einer solchen Datei liefert dann den Status 403 statt der Code-Ausführung.

Zwei Voraussetzungen sollten Sie kennen:

  • Die Server-Konfiguration muss .htaccess-Dateien erlauben (AllowOverride). Bei praktisch allen Shared-Hosting-Angeboten ist das der Fall, sonst würde WordPress selbst nicht funktionieren.
  • Die Regel blockiert den Zugriff über den Webserver. Sie schützt nicht davor, dass bereits laufender PHP-Code eine Datei einbindet. Für den beschriebenen Angriffsweg über den direkten URL-Aufruf ist sie aber genau das richtige Werkzeug.

nginx: location-Block vor dem PHP-Handler

nginx wertet keine .htaccess-Dateien aus. Die Sperre gehört in die Server-Konfiguration, also in den server-Block Ihrer Site (je nach Distribution unter /etc/nginx/sites-available/ oder /etc/nginx/conf.d/):

location ~* /wp-content/uploads/.*.(php|phar|phtml)$ {
    deny all;
}

Ein Detail ist hier entscheidend: die Reihenfolge. nginx wertet Regex-Locations in der Reihenfolge aus, in der sie in der Konfiguration stehen, und die erste passende gewinnt. Dieser Block muss deshalb vor dem allgemeinen PHP-Block stehen (der Zeile location ~ .php$ mit der fastcgi_pass-Anweisung). Steht er dahinter, greift zuerst der PHP-Handler und die Sperre ist wirkungslos.

Danach Konfiguration testen und neu laden:

nginx -t
systemctl reload nginx

Auf Managed Hosting ohne Zugriff auf die nginx-Konfiguration bleibt nur der Weg über den Hoster. Fragen Sie den Support konkret: „Ist die Ausführung von PHP-Dateien unterhalb von /wp-content/uploads/ blockiert?“ Gute Hoster haben das längst als Standard gesetzt, und die Frage zeigt ihnen, dass Sie wissen, wonach Sie suchen.

So testen Sie, ob Ihr Server verwundbar ist

Verlassen Sie sich nicht auf die Annahme, dass die Sperre greift. Testen Sie es. Der manuelle Weg:

  1. Legen Sie per FTP oder Dateimanager eine Datei namens test-exec.php in /wp-content/uploads/ an, mit genau einer Zeile Inhalt: <?php echo 'PHP wird ausgefuehrt'; ?>
  2. Rufen Sie https://ihre-domain.de/wp-content/uploads/test-exec.php im Browser auf.
  3. Sehen Sie den Text „PHP wird ausgefuehrt“, hat der Server den Code ausgeführt: Ihre Site ist verwundbar. Sehen Sie einen 403-Fehler oder den Quelltext als Klartext, greift die Sperre.
  4. Löschen Sie die Testdatei sofort wieder.

Genau diesen Test führt auch unser kostenloses Plugin Security Check Report durch, nur automatisiert: Es schreibt eine temporäre PHP-Datei mit zufälligem Namen in den Uploads-Ordner, ruft sie einmal auf und löscht sie noch im selben Request wieder. Das ist übrigens der einzige Schreibzugriff des ansonsten rein lesenden Konfigurations-Audits, und es ist der einzige Weg, diese Frage verlässlich zu beantworten. Die Konfigurationsdateien nur zu lesen reicht nicht, denn ob eine .htaccess-Regel wirklich greift, entscheidet am Ende der Server, nicht die Datei. Wir erwähnen das so deutlich, weil ein Sicherheitswerkzeug, das selbst Dateien schreibt, das transparent machen muss. Der Quelltext ist öffentlich auf GitHub einsehbar.

Schlägt die Prüfung fehl, steht sie im Report weit oben in der Prioritätenliste, zusammen mit der Anleitung aus dieser Doku-Seite. Fällt bei so einem Audit auf, dass bereits eine fremde PHP-Datei im Uploads-Ordner liegt, ist das ein Fall für die Vorfall-Analyse, nicht mehr für die Härtung allein.

Häufige Fragen

Reicht ein Security-Plugin mit Firewall nicht aus?

Eine Firewall filtert eingehende Requests und fängt viele Angriffe ab, aber keine Firewall erkennt jede Upload-Lücke in jedem Plugin. Die Server-Sperre wirkt eine Ebene tiefer: Selbst wenn der Upload durchkommt, wird die Datei nicht ausgeführt. Beide Maßnahmen ergänzen sich, sie ersetzen sich nicht.

Gehen durch die Sperre Bilder oder Downloads kaputt?

Nein. Die Regeln greifen ausschließlich bei Dateiendungen wie .php oder .phtml. Bilder, PDFs, Videos und andere Medien werden unverändert ausgeliefert. WordPress legt im Normalbetrieb keine PHP-Dateien im Uploads-Ordner ab, die Sperre trifft also keinen legitimen Anwendungsfall.

Kann WordPress die .htaccess im Uploads-Ordner überschreiben?

WordPress verwaltet nur die .htaccess im Stammverzeichnis (für die Permalinks). Eine .htaccess in /wp-content/uploads/ fasst der Core nicht an. Einzelne Plugins können dort Dateien anlegen; nach größeren Plugin-Installationen lohnt ein kurzer Blick, ob Ihre Regeln noch vorhanden sind. Ein wiederkehrender Konfigurations-Check erledigt das automatisch.

Ich habe eine fremde PHP-Datei im Uploads-Ordner gefunden. Was jetzt?

Dann ist die Härtung nicht mehr der erste Schritt, sondern die Aufräumarbeit: Die Site muss auf weitere Hintertüren untersucht werden, Zugangsdaten gehören gewechselt, und die Lücke, über die die Datei hereinkam, muss gefunden werden. Wie Sie dabei vorgehen, beschreiben wir unter WordPress gehackt: Soforthilfe.

Weitere Härtungsmaßnahmen rund um WordPress, vom Datei-Editor bis zu XML-RPC, finden Sie in unserer Übersicht WordPress-Sicherheit. Und wenn Sie wissen wollen, wo Ihre Site heute steht: Security Check Report installieren, einen Lauf starten, und die Prioritätenliste sagt Ihnen, was zuerst dran ist. Kostenlos, ohne Pro-Version, ohne Telemetrie.

Still stuck? Contact

Wie können wir helfen?