Kort sagt: En fil, der kun kalder phpinfo(), viser enhver besøgende PHP's version, moduler, stier og indstillinger, ofte også miljøvariabler med adgangsdata. For phpinfo-sikkerheden gælder derfor: Lad aldrig sådanne filer ligge varigt i webroot, slet dem efter brug, og kontrollér hellere PHP-status via pakkestyring og konfiguration. Patchstatus mod PHP2Shell dokumenterer et phpinfo-output under alle omstændigheder ikke.
Testfilen, der bliver liggende
Siden 21.10.2026 kontrollerer tusindvis af administratorer, hvilken PHP-version deres websites leverer. Den hurtigste vej er kendt: Opret en fil info.php med en enkelt linje, kald den i browseren, aflæs resultatet. Det fungerer. Problemet begynder bagefter, når filen glemmes.
Sådanne filer overlever overraskende længe. De følger med ved flytninger, havner i backups og dukker efter år op i mapper, som ingen længere kender. Automatiserede scannere forespørger løbende typiske filnavne. Det, der for administratoren var et hjælpemiddel, er for en angriber en byggevejledning til serveren.
Særligt berørt er bureauer og hostingudbydere med mange kundesites. Den, der i en hektisk uge kontrollerer dusinvis af websites, opretter hurtigt dusinvis af testfiler. Én eneste glemt mappe er nok til, at filen måneder senere stadig kan hentes.
Hvad phpinfo() afslører, og hvorfor det tæller for sikkerheden
Ifølge PHP-manualen udskriver phpinfo() PHP's aktuelle tilstand. Via konstanter kan det styres, hvilke dele der vises; uden angivelse er det alt.
| Område (konstant) | Indhold ifølge manualen | Hvorfor kildent |
|---|---|---|
INFO_GENERAL |
build, placering af php.ini, webserver, system | afslører operativsystem og stier |
INFO_CONFIGURATION |
lokale værdier og master-værdier for alle direktiver | viser, om disable_functions eller open_basedir virker |
INFO_MODULES |
indlæste udvidelser med indstillinger | angribere ser, hvilke funktioner der er tilgængelige |
INFO_ENVIRONMENT |
miljøvariabler | her står ofte database- eller API-adgangsdata |
INFO_VARIABLES |
foruddefinerede variabler (Environment, GET, POST, Cookie, Server) | indeholder headere og cookies fra den aktuelle forespørgsel |
Farligst er de to sidste rækker. Moderne applikationer henter gerne adgangsdata fra miljøvariabler, f.eks. fra en .env-fil eller fra containerkonfigurationen. Disse værdier står så i klartekst i outputtet. Hvordan I generelt beskytter sådanne hemmeligheder, beskriver indlægget Beskyt adgangsdata og .env-filer rigtigt.
Dertil kommer: Outputtet viser værdierne fra den igangværende forespørgsel, altså også cookies og headere. Kan en angriber lede en besøgende hen til siden og aflæse svaret, f.eks. via en cross-site-scripting-sårbarhed et andet sted, bliver selv cookies, der er markeret HttpOnly, synlige.
Hvorfor phpinfo ikke er et bevis mod PHP2Shell
Mange har netop oprettet filen for at kontrollere patchstatus. Netop til det egner den sig kun betinget. Distributioner og hostingudbydere indspiller ofte rettelser som backport; ifølge rapporter viser f.eks. Ubuntu 24.04 efter opdateringen fortsat 8.3.6. Det viste nummer siger altså lidt. Omvendt beviser et aktuelt nummer ikke, at alle workers er blevet genstartet.
Holdbar er pakkestatus med CVE-numrene i changelog, suppleret med genstart af alle PHP-processer. Hvordan det gøres, forklarer indlægget Kontrollér PHP-version og patchstatus rigtigt.
Et kortvarigt output i webkonteksten har alligevel sin plads: Det viser, hvilken php.ini og hvilke værdier der faktisk gælder for websitet, for kommandolinjen læser ofte en anden konfiguration. Baggrunden om niveauer og forrang forklarer php.ini forklaret. Hvis I har brug for det, så adgangsbeskyttet, med et tilfældigt filnavn og kun i få minutter.
Til de fleste spørgsmål findes der alligevel bedre veje. PHP-versionen for en FPM-pool står i dens konfiguration og i procesoversigten. Enkelte værdier kan forespørges med et script uden for webroot via ini_get(), uden at alt lægges frem. Og i hostingpaneler viser brugerfladen den tildelte version pr. website, om end uden udsagn om backports.
Find glemte filer: konkrete kontroltrin
Sådan opspørger I levn på en Linux-server. Kommandoerne læser kun og ændrer intet.
- Søg filer med phpinfo-kald (tilpas stien):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Kontrollér typiske filnavne, også uden fund i indholdet:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Vurdér fund: Ikke ethvert fund er en testfil. Administrationsværktøjer, paneler eller frameworks kan bruge
phpinfo()bag et login. Afgørende er, om filen kan nås fra internettet uden login. -
Se på adgange i loggen, før I sletter:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Slet og udskift hemmeligheder: Stod en adgangskode eller nøgle i outputtet, og var filen offentlig, gælder værdien som kendt. Ændr den.
Et fund med ukendt oprettelsesdato og påfaldende indhold ved siden af phpinfo-kaldet kan også være en bagdør. Så slet ikke blot, men sikr og lad kontrollere, se Opdag og fjern webshells.
Forebyg varigt i stedet for at rydde op
Tre foranstaltninger sørger for, at emnet ikke vender tilbage. For det første: Optag phpinfo på listen disable_functions i php.ini for webkonteksten. Kontrollér på forhånd, om jeres panel har brug for funktionen til en statusside. Hvordan indstillingen virker, og hvor dens grænser går, står under Brug disable_functions rigtigt.
; php.ini til FPM eller Apache, genstart derefter alle PHP-processer
disable_functions = phpinfo
expose_php = Off
For det andet: Udrulning kun via et fast forløb, f.eks. via Git eller build-pipeline, så ingen enkeltfiler kommer manuelt ind i webroot. For det tredje: Statusoplysninger hører hjemme i overvågning eller oversigt, ikke på en offentlig side.
expose_php = Off fjerner desuden den header, hvormed PHP meddeler sin version i hvert svar. Det erstatter ingen opdatering, men tager en bekvem oplysning fra automatiserede scannere. Den, der har flere personer med serveradgang, bør desuden aftale en enkel regel: Testfiler slettes i samme arbejdstrin, som de oprettes, og ikke først "senere".
Hvordan hjælper PHP SOS konkret?
- Vi gennemsøger jeres webroots efter phpinfo-filer, testscripts og andre levn og vurderer hvert fund.
- Vi analyserer adgangene til fundne filer og fortæller jer, hvilke hemmeligheder I bør udskifte.
- Vi dokumenterer patchstatus mod PHP2Shell via pakkens changelog og processtart i stedet for en versionsvisning.
- Vi gennemfører
disable_functions,expose_phpog yderligere hærdninger varigt som led i serverhærdningen.
Konklusion: En phpinfo-fil er oprettet på sekunder og glemt lige så hurtigt. Den, der søger og fjerner den nu, lukker et unødvendigt datalæk og støtter sig ved patchstatus til holdbare beviser.
Ofte stillede spørgsmål
Er en phpinfo-fil i sig selv en sikkerhedssårbarhed?
Den åbner ingen adgang, men giver angribere en detaljeret beskrivelse af serveren: version, moduler, stier, indstillinger og afhængigt af miljøet også miljøvariabler. Det letter målrettede angreb og kan afsløre adgangsdata.
Beviser versionsnummeret i phpinfo, at PHP2Shell er patchet?
Nej. Distributioner og hostingudbydere indspiller ofte rettelser som backport, og det viste nummer forbliver så det samme. Patchstatus dokumenteres af pakkens changelog og udbyderens bekræftelse, dertil genstarten af alle PHP-processer.
Hvad gør man, hvis en phpinfo-fil har været offentlig i længere tid?
Slet filen, se i access-loggen, hvem der har hentet den, og udskift alle hemmeligheder, der stod i outputtet, f.eks. databaseadgangskoder eller API-nøgler fra miljøvariabler.
Kan jeg slå phpinfo() helt fra?
Ja, via disable_functions i php.ini for webkonteksten. Kontrollér på forhånd, om et panel eller en applikation bruger funktionen til statussider, og genstart PHP-processerne bagefter.