Actuele situatie: PHP2Shell. Twee kritieke PHP-kwetsbaarheden (CVSS 9.2) maken schadelijke code zonder inloggen mogelijk. Patches sinds 21-10-2026.Wat u nu moet doen →

phpinfo()-bestanden: waarom ze moeten verdwijnen

Na PHP2Shell maken veel beheerders snel een info.php aan. Waarom zulke bestanden een datalek zijn, hoe u ze vindt en welke controlewegen beter zijn.

Stand 5 min. leestijdVeilig ontwikkelen

Kort gezegd: Een bestand dat alleen phpinfo() aanroept, toont elke bezoeker versie, modules, paden en instellingen van PHP, vaak ook omgevingsvariabelen met toegangsgegevens. Voor de beveiliging rond phpinfo geldt daarom: laat zulke bestanden nooit blijvend in de webroot staan, verwijder ze na gebruik en controleer de PHP-status liever via pakketbeheer en configuratie. De patchstatus tegen PHP2Shell bewijst een phpinfo-uitvoer sowieso niet.

Het testbestand dat blijft

Sinds 21-10-2026 controleren duizenden beheerders welke PHP-versie hun websites uitleveren. De snelste weg is bekend: een bestand info.php met één enkele regel aanmaken, in de browser openen, het resultaat aflezen. Dat werkt. Het probleem begint daarna, wanneer het bestand wordt vergeten.

Zulke bestanden overleven verrassend lang. Ze verhuizen mee bij migraties, belanden in back-ups en duiken na jaren op in mappen die niemand meer kent. Geautomatiseerde scanners vragen voortdurend typische bestandsnamen op. Wat voor de beheerder een hulpmiddel was, is voor een aanvaller een bouwtekening van de server.

Vooral bureaus en hostingproviders met veel klantwebsites worden erdoor getroffen. Wie in een hectische week tientallen websites controleert, maakt snel tientallen testbestanden aan. Eén enkele vergeten map volstaat om het bestand maanden later nog op te kunnen halen.

Wat phpinfo() verraadt en waarom dat voor de beveiliging telt

Volgens de PHP-handleiding geeft phpinfo() de actuele toestand van PHP weer. Via constanten is te sturen welke onderdelen verschijnen; zonder opgave is het alles.

Onderdeel (constante) Inhoud volgens de handleiding Waarom gevoelig
INFO_GENERAL build, locatie van de php.ini, webserver, systeem verraadt besturingssysteem en paden
INFO_CONFIGURATION lokale en masterwaarden van alle directieven toont of disable_functions of open_basedir werken
INFO_MODULES geladen extensies met instellingen aanvallers zien welke functies beschikbaar zijn
INFO_ENVIRONMENT omgevingsvariabelen hier staan vaak database- of API-toegangsgegevens
INFO_VARIABLES vooraf gedefinieerde variabelen (Environment, GET, POST, Cookie, Server) bevat headers en cookies van het actuele verzoek

Het gevaarlijkst zijn de twee laatste regels. Moderne applicaties laden toegangsgegevens graag uit omgevingsvariabelen, bijvoorbeeld uit een .env-bestand of uit de containerconfiguratie. Die waarden staan dan in leesbare tekst in de uitvoer. Hoe u zulke geheimen in het algemeen beschermt, beschrijft het artikel Toegangsgegevens en .env-bestanden correct beveiligen.

Daar komt bij: de uitvoer toont de waarden van het lopende verzoek, dus ook cookies en headers. Kan een aanvaller een bezoeker naar de pagina leiden en het antwoord uitlezen, bijvoorbeeld via een cross-site-scriptingkwetsbaarheid elders, dan worden zelfs als HttpOnly gemarkeerde cookies zichtbaar.

Waarom phpinfo geen bewijs is tegen PHP2Shell

Velen hebben het bestand net aangemaakt om de patchstatus te controleren. Daarvoor is het maar beperkt geschikt. Distributies en hostingproviders voeren correcties vaak als backport door; volgens berichten toont bijvoorbeeld Ubuntu 24.04 na de update nog steeds 8.3.6. Het getoonde nummer zegt dus weinig. Omgekeerd bewijst een actueel nummer niet dat alle workers zijn herstart.

Betrouwbaar is de pakketstatus met de CVE-nummers in de changelog, aangevuld met de herstart van alle PHP-processen. Hoe dat gaat, legt het artikel PHP-versie en patchstatus correct controleren uit.

Een kortstondige uitvoer in de webcontext heeft toch zijn plaats: ze toont welke php.ini en welke waarden werkelijk voor de website gelden, want de opdrachtregel leest vaak een andere configuratie. De achtergronden over niveaus en voorrang legt De php.ini uitgelegd uit. Hebt u dat nodig, doe het dan met toegangsbeveiliging, met een willekeurige bestandsnaam en slechts voor enkele minuten.

Voor de meeste vragen bestaan sowieso betere wegen. De PHP-versie van een FPM-pool staat in de configuratie ervan en in de proceslijst. Afzonderlijke waarden zijn met een script buiten de webroot via ini_get() op te vragen, zonder alles bloot te leggen. En in hostingpanelen toont de interface de toegewezen versie per website, zij het zonder uitspraak over backports.

Vergeten bestanden vinden: concrete controlestappen

Zo spoort u oude lasten op een Linux-server op. De opdrachten lezen alleen en wijzigen niets.

  1. Bestanden met een phpinfo-aanroep zoeken (pad aanpassen):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
  1. Typische bestandsnamen controleren, ook zonder treffer in de inhoud:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
  1. Treffers beoordelen: Niet elke vindplaats is een testbestand. Beheerhulpmiddelen, panelen of frameworks kunnen phpinfo() achter een aanmelding gebruiken. Beslissend is of het bestand zonder aanmelding vanaf het internet bereikbaar is.

  2. Toegangen in het logboek nakijken voordat u verwijdert:

grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
  1. Verwijderen en geheimen vervangen: Stond er in de uitvoer een wachtwoord of sleutel en was het bestand openbaar, dan geldt de waarde als bekend. Wijzig haar.
Tip

Een vindplaats met onbekende aanmaakdatum en opvallende inhoud naast de phpinfo-aanroep kan ook een achterdeur zijn. Verwijder dan niet alleen, maar bewaar en laat controleren, zie Webshells herkennen en verwijderen.

Blijvend voorkomen in plaats van opruimen

Drie maatregelen zorgen ervoor dat het onderwerp niet terugkeert. Eerste: neem phpinfo op in de lijst disable_functions van de php.ini voor de webcontext. Controleer vooraf of uw paneel de functie voor een statuspagina nodig heeft. Hoe de instelling werkt en waar haar grenzen liggen, staat onder disable_functions correct gebruiken.

; php.ini voor FPM of Apache, herstart daarna alle PHP-processen
disable_functions = phpinfo
expose_php = Off

Tweede: levering alleen via een vast proces, bijvoorbeeld via Git of een buildpipeline, zodat geen losse bestanden met de hand in de webroot terechtkomen. Derde: statusinformatie hoort in monitoring of inventaris, niet op een openbare pagina.

expose_php = Off verwijdert bovendien de header waarmee PHP zijn versie in elk antwoord meedeelt. Dat vervangt geen update, maar ontneemt geautomatiseerde scanners een handige informatiebron. Wie meerdere mensen met servertoegang heeft, moet bovendien een eenvoudige regel afspreken: testbestanden worden in dezelfde werkstap verwijderd als waarin ze zijn aangemaakt, en niet pas "later".

Hoe helpt PHP SOS concreet?

  • Wij doorzoeken uw webroots op phpinfo-bestanden, testscripts en andere oude lasten en beoordelen elke vindplaats.
  • Wij beoordelen de toegangen tot gevonden bestanden en vertellen u welke geheimen u moet vervangen.
  • Wij onderbouwen de patchstatus tegen PHP2Shell via de pakket-changelog en procesherstart in plaats van via een versieweergave.
  • Wij voeren disable_functions, expose_php en andere hardeningmaatregelen in het kader van de serverhardening blijvend door.

Conclusie: Een phpinfo-bestand is in seconden aangemaakt en even snel vergeten. Wie het nu zoekt en verwijdert, dicht een onnodig datalek en vertrouwt voor de patchstatus op betrouwbaar bewijs.

Veelgestelde vragen

Is een phpinfo-bestand op zich een beveiligingslek?

Het opent geen toegang, maar geeft aanvallers wel een gedetailleerde beschrijving van de server: versie, modules, paden, instellingen en afhankelijk van de omgeving ook omgevingsvariabelen. Dat vergemakkelijkt gerichte aanvallen en kan toegangsgegevens blootleggen.

Bewijst het versienummer in phpinfo dat PHP2Shell is gepatcht?

Nee. Distributies en hostingproviders voeren correcties vaak als backport door, het getoonde nummer blijft dan gelijk. De patchstatus bewijzen de pakket-changelog en de bevestiging van de aanbieder, plus de herstart van alle PHP-processen.

Wat te doen als een phpinfo-bestand langere tijd openbaar was?

Bestand verwijderen, in het toegangslogboek nagaan wie het heeft opgehaald en alle geheimen vervangen die in de uitvoer stonden, zoals databasewachtwoorden of API-sleutels uit omgevingsvariabelen.

Kan ik phpinfo() helemaal uitschakelen?

Ja, via disable_functions in de php.ini van de webcontext. Controleer vooraf of een paneel of applicatie de functie voor statuspagina's gebruikt en herstart daarna de PHP-processen.

Bronnen

Direct contact

Elk uur telt. Schrijf ons nu.

Beschrijf kort het systeem, de PHP-versie en wat u opmerkt. Wij nemen contact op, brengen de situatie in kaart en werken op afstand tot het incident is afgerond en gedocumenteerd.

Directe hulp