Kurz gesagt: Eine Datei, die nur phpinfo() aufruft, zeigt jedem Besucher Version, Module, Pfade und Einstellungen von PHP, oft auch Umgebungsvariablen mit Zugangsdaten. Für die phpinfo-Sicherheit gilt deshalb: solche Dateien nie dauerhaft im Webroot lassen, nach Gebrauch löschen und den PHP-Stand lieber über Paketverwaltung und Konfiguration prüfen. Den Patchstand gegen PHP2Shell belegt eine phpinfo-Ausgabe ohnehin nicht.
Die Testdatei, die bleibt
Seit dem 21.10.2026 prüfen Tausende Admins, welche PHP-Version ihre Websites ausliefern. Der schnellste Weg ist bekannt: eine Datei info.php mit einer einzigen Zeile anlegen, im Browser aufrufen, Ergebnis ablesen. Das funktioniert. Das Problem beginnt danach, wenn die Datei vergessen wird.
Solche Dateien überleben erstaunlich lange. Sie wandern bei Umzügen mit, landen in Backups und tauchen nach Jahren in Verzeichnissen auf, die niemand mehr kennt. Automatisierte Scanner fragen typische Dateinamen ständig ab. Was für den Admin ein Hilfsmittel war, ist für einen Angreifer eine Bauanleitung des Servers.
Besonders betroffen sind Agenturen und Hoster mit vielen Kundenseiten. Wer in einer hektischen Woche Dutzende Websites prüft, legt schnell Dutzende Testdateien an. Ein einziger vergessener Ordner genügt, damit die Datei Monate später noch abrufbar ist.
Was phpinfo() verrät und warum das für die Sicherheit zählt
Laut PHP-Handbuch gibt phpinfo() den aktuellen Zustand von PHP aus. Über Konstanten lässt sich steuern, welche Teile erscheinen; ohne Angabe ist es alles.
| Bereich (Konstante) | Inhalt laut Handbuch | Warum heikel |
|---|---|---|
INFO_GENERAL |
Build, Ort der php.ini, Webserver, System | verrät Betriebssystem und Pfade |
INFO_CONFIGURATION |
lokale und Master-Werte aller Direktiven | zeigt, ob disable_functions oder open_basedir greifen |
INFO_MODULES |
geladene Erweiterungen mit Einstellungen | Angreifer sehen, welche Funktionen verfügbar sind |
INFO_ENVIRONMENT |
Umgebungsvariablen | hier stehen oft Datenbank- oder API-Zugangsdaten |
INFO_VARIABLES |
vordefinierte Variablen (Environment, GET, POST, Cookie, Server) | enthält Header und Cookies der aktuellen Anfrage |
Am gefährlichsten sind die beiden letzten Zeilen. Moderne Anwendungen laden Zugangsdaten gern aus Umgebungsvariablen, etwa aus einer .env-Datei oder aus der Container-Konfiguration. Diese Werte stehen dann im Klartext in der Ausgabe. Wie Sie solche Geheimnisse grundsätzlich schützen, beschreibt der Beitrag Zugangsdaten und .env-Dateien richtig schützen.
Hinzu kommt: Die Ausgabe zeigt die Werte der laufenden Anfrage, also auch Cookies und Header. Kann ein Angreifer einen Besucher auf die Seite lenken und die Antwort auslesen, etwa über eine Cross-Site-Scripting-Lücke an anderer Stelle, werden selbst als HttpOnly markierte Cookies sichtbar.
Warum phpinfo kein Nachweis gegen PHP2Shell ist
Viele haben die Datei gerade angelegt, um den Patchstand zu prüfen. Genau dafür taugt sie nur bedingt. Distributionen und Hoster spielen Korrekturen oft als Backport ein; laut Berichten zeigt etwa Ubuntu 24.04 nach dem Update weiter 8.3.6. Die angezeigte Nummer sagt also wenig. Umgekehrt beweist eine aktuelle Nummer nicht, dass alle Worker neu gestartet wurden.
Belastbar ist der Paketstand mit den CVE-Nummern im Changelog, ergänzt um den Neustart aller PHP-Prozesse. Wie das geht, erklärt der Beitrag PHP-Version und Patchstand richtig prüfen.
Eine kurzzeitige Ausgabe im Webkontext hat trotzdem ihren Platz: Sie zeigt, welche php.ini und welche Werte für die Website tatsächlich gelten, denn die Kommandozeile liest oft eine andere Konfiguration. Die Hintergründe zu Ebenen und Vorrang erklärt Die php.ini erklärt. Wenn Sie das brauchen, dann zugriffsgeschützt, mit zufälligem Dateinamen und nur für Minuten.
Für die meisten Fragen gibt es ohnehin bessere Wege. Die PHP-Version eines FPM-Pools steht in dessen Konfiguration und in der Prozessliste. Einzelne Werte lassen sich mit einem Skript ausserhalb des Webroots über ini_get() abfragen, ohne alles offenzulegen. Und in Hosting-Panels zeigt die Oberfläche die zugewiesene Version je Website an, wenn auch ohne Aussage über Backports.
Vergessene Dateien finden: konkrete Prüfschritte
So spüren Sie Altlasten auf einem Linux-Server auf. Die Befehle lesen nur und ändern nichts.
- Dateien mit phpinfo-Aufruf suchen (Pfad anpassen):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Typische Dateinamen prüfen, auch ohne Treffer im Inhalt:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Treffer bewerten: Nicht jede Fundstelle ist eine Testdatei. Admin-Werkzeuge, Panels oder Frameworks können
phpinfo()hinter einer Anmeldung nutzen. Entscheidend ist, ob die Datei ohne Anmeldung aus dem Internet erreichbar ist. -
Zugriffe im Log nachsehen, bevor Sie löschen:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Löschen und Geheimnisse tauschen: Stand in der Ausgabe ein Passwort oder Schlüssel und war die Datei öffentlich, gilt der Wert als bekannt. Ändern Sie ihn.
Eine Fundstelle mit unbekanntem Erstelldatum und auffälligem Inhalt neben dem phpinfo-Aufruf kann auch eine Hintertür sein. Dann nicht nur löschen, sondern sichern und prüfen lassen, siehe Webshells erkennen und entfernen.
Dauerhaft vorbeugen statt aufräumen
Drei Massnahmen sorgen dafür, dass das Thema nicht wiederkommt. Erstens: phpinfo in die Liste disable_functions der php.ini für den Webkontext aufnehmen. Prüfen Sie vorher, ob Ihr Panel die Funktion für eine Statusseite braucht. Wie die Einstellung wirkt und wo ihre Grenzen liegen, steht unter disable_functions richtig einsetzen.
; php.ini für FPM oder Apache, danach alle PHP-Prozesse neu starten
disable_functions = phpinfo
expose_php = Off
Zweitens: Bereitstellung nur über einen festen Ablauf, etwa per Git oder Build-Pipeline, damit keine Einzeldateien von Hand ins Webroot gelangen. Drittens: Statusinformationen gehören in Monitoring oder Inventar, nicht in eine öffentliche Seite.
expose_php = Off entfernt zusätzlich den Header, mit dem PHP seine Version in jeder Antwort mitteilt. Das ersetzt kein Update, nimmt automatisierten Scannern aber eine bequeme Information. Wer mehrere Personen mit Serverzugang hat, sollte ausserdem eine einfache Regel vereinbaren: Testdateien werden im selben Arbeitsschritt gelöscht, in dem sie angelegt wurden, und nicht erst „später“.
Wie hilft PHP SOS konkret?
- Wir durchsuchen Ihre Webroots nach phpinfo-Dateien, Testskripten und anderen Altlasten und bewerten jede Fundstelle.
- Wir werten die Zugriffe auf gefundene Dateien aus und sagen Ihnen, welche Geheimnisse Sie austauschen sollten.
- Wir belegen den Patchstand gegen PHP2Shell über Paket-Changelog und Prozessstart statt über eine Versionsanzeige.
- Wir setzen
disable_functions,expose_phpund weitere Härtungen im Rahmen der Server-Härtung dauerhaft um.
Fazit: Eine phpinfo-Datei ist in Sekunden angelegt und wird ebenso schnell vergessen. Wer sie jetzt sucht und entfernt, schliesst ein unnötiges Datenleck und verlässt sich beim Patchstand auf belastbare Nachweise.
Häufige Fragen
Ist eine phpinfo-Datei an sich eine Sicherheitslücke?
Sie öffnet keinen Zugang, liefert Angreifern aber eine detaillierte Beschreibung des Servers: Version, Module, Pfade, Einstellungen und je nach Umgebung auch Umgebungsvariablen. Das erleichtert gezielte Angriffe und kann Zugangsdaten offenlegen.
Beweist die Versionsnummer in phpinfo, dass PHP2Shell gepatcht ist?
Nein. Distributionen und Hoster spielen Korrekturen oft als Backport ein, die angezeigte Nummer bleibt dann gleich. Den Patchstand belegen Paket-Changelog und Bestätigung des Anbieters, dazu der Neustart aller PHP-Prozesse.
Was tun, wenn eine phpinfo-Datei längere Zeit öffentlich war?
Datei löschen, im Access-Log nachsehen, wer sie abgerufen hat, und alle Geheimnisse austauschen, die in der Ausgabe standen, etwa Datenbankpasswörter oder API-Schlüssel aus Umgebungsvariablen.
Kann ich phpinfo() komplett abschalten?
Ja, über disable_functions in der php.ini des Webkontexts. Prüfen Sie vorher, ob ein Panel oder eine Anwendung die Funktion für Statusseiten nutzt, und starten Sie die PHP-Prozesse danach neu.