Kurz gesagt: Eine PHP-Datei im Upload-Ordner ist ein ernstes Warnsignal, denn dort sollten nur Bilder und Dokumente liegen. Öffnen Sie die Datei nie im Browser, sondern lesen Sie sie als Text, prüfen Sie Zeitstempel und Eigentümer und suchen Sie den Dateinamen in den Zugriffslogs. Harmlos sind meist nur leere Platzhalter wie eine index.php ohne Inhalt; alles andere behandeln Sie als möglichen Einbruch.
Warum PHP im Upload-Ordner nichts zu suchen hat
Upload-Ordner sind für Inhalte da, die Besucher oder Redakteure hochladen: Bilder, PDFs, Videos. Der Webserver-Benutzer darf dort schreiben, sonst funktionieren Uploads nicht. Genau das macht diese Ordner attraktiv für Angreifer. Wer über eine Lücke Dateien schreiben kann, legt sie dort ab, wo das Schreiben erlaubt ist.
Neue PHP-Dateien in Upload- oder Cache-Ordnern zählen laut den uns vorliegenden Berichten zu den allgemeinen Warnsignalen nach einem Einbruch. Für PHP2Shell gibt es keine bestätigten Indicators of Compromise; ein Fund sagt also nichts darüber, über welche Lücke die Datei kam. Wie Upload-Funktionen sicher gebaut werden, beschreibt Datei-Uploads in PHP sicher umsetzen.
Ob eine solche Datei Schaden anrichten kann, entscheidet die Konfiguration des Webservers. Führt er PHP-Dateien im Upload-Ordner aus, wird jede dort abgelegte Datei zur möglichen Fernsteuerung. Ist die Ausführung dort gesperrt, bleibt die Datei ein Fremdkörper, aber zunächst ohne Wirkung. Viele Installationen haben diese Sperre nie eingerichtet.
Wie kommt eine PHP-Datei in den Upload-Ordner?
Für die Bewertung hilft es, die möglichen Wege zu kennen. Jeder führt zu anderen Folgefragen.
| Weg | Typischer Hintergrund | Folgefrage |
|---|---|---|
| Unsicheres Upload-Formular | Prüfung nur der Endung oder des vom Browser gemeldeten Typs | Welche Formulare nehmen Dateien an? |
| Lücke in einem Plugin oder Theme | bekannte Schwachstelle in veralteter Erweiterung | Welche Erweiterungen sind veraltet? |
| Gestohlene Zugangsdaten | Admin-, FTP- oder Hosting-Konto | Welche Anmeldungen gab es zuletzt? |
| Codeausführung über eine Lücke | etwa im Interpreter, wie bei PHP2Shell möglich | War PHP im Zeitraum verwundbar? |
| Legitimes Plugin | Platzhalter, selten Cache-Dateien | Gehört die Datei zum Originalpaket? |
Mehrere Wege können zusammenkommen. Ein Angreifer, der über eine Lücke Code ausführt, legt die Datei vielleicht nur ab, um später bequemer zurückzukehren.
Fundstellen systematisch auflisten
Bevor Sie eine einzelne Datei bewerten, verschaffen Sie sich einen Überblick. Die Befehle lesen nur. Pfade sind Beispiele für WordPress; bei anderen Systemen passen Sie den Upload-Pfad an.
# PHP-ähnliche Dateien im Upload-Ordner mit Größe, Eigentümer, mtime und ctime
find /var/www/html/wp-content/uploads -type f \
\( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
-printf '%s Bytes %u m:%T+ c:%C+ %p\n'
# Dateityp nach Inhalt statt nach Endung bestimmen (Bilder mit PHP-Inhalt fallen auf)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Andere Systeme nutzen andere Schreibordner, etwa fileadmin bei TYPO3, images bei Joomla oder den Medienordner unter public bei Shopware 6. Hinzu kommen Cache- und Temp-Verzeichnisse der Anwendung. Bei Multisite-Installationen und mehreren Websites auf einem Server gibt es entsprechend viele Upload-Ordner; jeder gehört in die Suche.
Auch .htaccess- und .user.ini-Dateien im Upload-Ordner sind verdächtig. Mit ihnen lässt sich die Ausführung von PHP in diesem Ordner wieder einschalten oder die Konfiguration verändern.
PHP-Datei im Uploads-Ordner: den Fund richtig deuten
Nicht jeder Treffer ist gleich ernst. Die folgende Einordnung hilft bei der ersten Bewertung. Sie ersetzt keine genaue Untersuchung.
| Befund | Erste Einordnung |
|---|---|
index.php mit null Bytes oder nur einem Kommentar |
meist Platzhalter gegen Verzeichnisauflistung, mit Plugin abgleichen |
| PHP-Datei mit Inhalt in einem Monatsordner | hoher Verdacht |
Doppelte Endung wie bild.jpg.php oder .php.png |
hoher Verdacht, typische Tarnung |
Bild, das laut file PHP-Code enthält |
hoher Verdacht, kann über Einbindung ausgeführt werden |
.htaccess oder .user.ini im Upload-Ordner |
Verdacht, Konfiguration prüfen |
| Datei gehört dem Webserver-Benutzer, ctime nach dem 17.10. | passt zu einem Einbruch über die Website |
Lesen Sie verdächtige Dateien nur als Text, etwa mit head -c 2000 datei.php oder less. Auffällig sind sehr lange Zeilen, kodierte Zeichenketten und Funktionsnamen wie eval oder base64_decode. Woran Sie verschleierten Code erkennen, zeigt Verschleierten PHP-Code erkennen.
Wurde die Datei aufgerufen? Ein Blick ins Log
Die wichtigste Frage nach dem Fund lautet: Hat jemand die Datei benutzt? Die Antwort steht in den Zugriffslogs des Webservers. Suchen Sie nach dem Dateinamen, auch in archivierten Logs.
# Aufrufe der verdächtigen Datei in aktuellen und gepackten Logs (Name als Beispiel)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null
# Nur erfolgreiche Aufrufe mit IP-Adresse und Zeitpunkt
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Viele erfolgreiche POST-Anfragen von wenigen Adressen deuten auf aktive Nutzung als Webshell. Keine Treffer heißen nicht automatisch Entwarnung, denn Logs können rotiert, gelöscht oder unvollständig sein. Läuft die Website hinter einem CDN oder einem Proxy, liegen weitere Protokolle dort; beim Shared Hosting stellt der Hoster die Zugriffslogs meist im Kundenbereich bereit. Achten Sie außerdem auf Anfragen an andere neue Dateien aus denselben Adressen, denn sie führen oft zu weiteren Bestandteilen. Bewahren Sie Logs ab dem 20. Oktober auf. Wie Sie Logs gründlich auswerten, steht im Ratgeber Webserver-Logs nach einem Angriff auswerten.
Zeigt das Log erfolgreiche Aufrufe einer unbekannten PHP-Datei, gehen Sie von einem Einbruch aus. Sichern Sie Datei und Logs, schränken Sie den Zugriff auf den Server ein und prüfen Sie, ob personenbezogene Daten betroffen sein können.
Nach der Bewertung: die richtige Reihenfolge
- Sichern: Datei mit Prüfsumme und Zeitstempeln kopieren, Logs sichern.
- Herkunft klären: Upload-Formulare, Plugins und den Zeitraum vor dem Fund prüfen.
- Weitere Bestandteile suchen: zusätzliche Dateien, Cronjobs, neue Admin-Konten.
- Ausführung sperren: PHP im Upload-Ordner auf Webserver-Ebene verbieten, wie im Beitrag PHP-Ausführung in Upload-Ordnern verbieten beschrieben.
- Bereinigen und Zugänge wechseln: erst dann die Datei entfernen und alle Passwörter erneuern.
Wie hilft PHP SOS konkret?
- Fund bewerten: Wir prüfen die Datei, ohne sie auszuführen, und ordnen sie ein.
- Nutzung klären: Wir werten die Logs aus und rekonstruieren, wer die Datei wann aufgerufen hat.
- Vollständig bereinigen: Mit der Malware-Entfernung suchen wir alle Bestandteile, schließen die Ursache und wechseln die Zugänge.
- Wiederholung verhindern: Wir sperren die PHP-Ausführung in Schreibordnern und überwachen neue Dateien.
Häufige Fragen
Ist jede PHP-Datei im Upload-Ordner gefährlich?
Nicht jede. Manche Plugins legen eine leere index.php ab, damit der Ordnerinhalt nicht aufgelistet wird. Alles andere, besonders Dateien mit Inhalt, ungewöhnlichem Namen oder doppelter Endung, sollten Sie als Verdachtsfall behandeln.
Darf ich die verdächtige Datei im Browser öffnen?
Nein. Ein Aufruf über die Website führt den Code aus. Lesen Sie die Datei nur als Text auf dem Server oder in einer Kopie, etwa mit less oder head.
Wie finde ich heraus, ob die Datei benutzt wurde?
Suchen Sie den Dateinamen in den Zugriffslogs des Webservers. Anfragen mit Status 200 und POST-Methode zeigen, dass die Datei aufgerufen wurde. Die zugehörigen IP-Adressen und Zeitpunkte helfen bei der weiteren Untersuchung.
Reicht es, die Datei zu löschen und PHP im Upload-Ordner zu sperren?
Beides ist nötig, aber nicht ausreichend. Klären Sie zusätzlich, wie die Datei dorthin kam, suchen Sie nach weiteren Bestandteilen und wechseln Sie die Zugangsdaten. Sonst kommt der Angreifer über denselben Weg zurück.