# phpinfo()-bestanden: waarom ze moeten verdwijnen

> Een vergeten phpinfo-bestand verraadt paden, modules en soms toegangsgegevens. Zo vindt en verwijdert u zulke bestanden en controleert u PHP veiliger.

Bron: https://phpsos.de/nl/blog/phpinfo-dateien-entfernen/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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](https://phpsos.de/nl/blog/env-dateien-schuetzen/).

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](https://phpsos.de/nl/php2shell/php-version-pruefen/) 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](https://phpsos.de/nl/php/php-ini-erklaert/) 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):

```bash
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
```

2. **Typische bestandsnamen controleren**, ook zonder treffer in de inhoud:

```bash
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
```

3. **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.

4. **Toegangen in het logboek nakijken** voordat u verwijdert:

```bash
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
```

5. **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](https://phpsos.de/nl/ratgeber/webshell-erkennen/).

## 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](https://phpsos.de/nl/ratgeber/disable-functions/).

```ini
; 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](https://phpsos.de/nl/leistungen/server-haertung/) 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

- [PHP-handleiding: phpinfo()](https://www.php.net/manual/de/function.phpinfo.php)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: beveiligingsmeldingen](https://www.php.net/)