Kort sagt: En fil som bara anropar phpinfo() visar för varje besökare PHP:s version, moduler, sökvägar och inställningar, ofta också miljövariabler med inloggningsuppgifter. För phpinfo-säkerheten gäller därför: lämna aldrig sådana filer permanent i webbroten, radera dem efter användning och kontrollera PHP-läget hellre via pakethantering och konfiguration. Patchläget mot PHP2Shell belägger en phpinfo-utskrift ändå inte.
Testfilen som blir kvar
Sedan den 21 oktober 2026 kontrollerar tusentals administratörer vilken PHP-version deras webbplatser levererar. Den snabbaste vägen är välkänd: skapa en fil info.php med en enda rad, anropa den i webbläsaren, läs av resultatet. Det fungerar. Problemet börjar efteråt, när filen glöms bort.
Sådana filer överlever förvånansvärt länge. De följer med vid flyttar, hamnar i backuper och dyker upp efter år i kataloger som ingen längre känner till. Automatiserade skannrar frågar ständigt efter typiska filnamn. Det som för administratören var ett hjälpmedel är för en angripare en ritning över servern.
Särskilt berörda är byråer och webbhotell med många kundwebbplatser. Den som under en hektisk vecka kontrollerar dussintals webbplatser skapar snabbt dussintals testfiler. En enda bortglömd mapp räcker för att filen månader senare fortfarande går att hämta.
Vad phpinfo() avslöjar och varför det spelar roll för säkerheten
Enligt PHP-manualen skriver phpinfo() ut PHP:s aktuella tillstånd. Via konstanter går det att styra vilka delar som visas; utan angivelse är det allt.
| Område (konstant) | Innehåll enligt manualen | Varför känsligt |
|---|---|---|
INFO_GENERAL |
Build, plats för php.ini, webbserver, system | avslöjar operativsystem och sökvägar |
INFO_CONFIGURATION |
lokala värden och huvudvärden för alla direktiv | visar om disable_functions eller open_basedir verkar |
INFO_MODULES |
laddade tillägg med inställningar | angripare ser vilka funktioner som finns |
INFO_ENVIRONMENT |
miljövariabler | här står ofta inloggningsuppgifter till databas eller API |
INFO_VARIABLES |
fördefinierade variabler (Environment, GET, POST, Cookie, Server) | innehåller headers och cookies från den aktuella förfrågan |
Farligast är de båda sista raderna. Moderna applikationer läser gärna in inloggningsuppgifter från miljövariabler, till exempel från en .env-fil eller containerkonfigurationen. Dessa värden står då i klartext i utdata. Hur ni skyddar sådana hemligheter i grunden beskriver inlägget Skydda inloggningsuppgifter och .env-filer rätt.
Dessutom gäller: Utdata visar värdena för den pågående förfrågan, alltså också cookies och headers. Kan en angripare locka en besökare till sidan och läsa ut svaret, till exempel via en cross-site-scripting-sårbarhet på ett annat ställe, blir till och med cookies som markerats som HttpOnly synliga.
Varför phpinfo inte är något bevis mot PHP2Shell
Många har just skapat filen för att kontrollera patchläget. Just för det duger den bara begränsat. Distributioner och webbhotell lägger ofta in rättelser som backport; enligt rapporter visar till exempel Ubuntu 24.04 efter uppdateringen fortfarande 8.3.6. Det visade numret säger alltså lite. Omvänt bevisar ett aktuellt nummer inte att alla workers har startats om.
Hållbart är paketläget med CVE-numren i changelog, kompletterat med omstart av alla PHP-processer. Hur det går till förklarar inlägget Kontrollera PHP-version och patchläge rätt.
En tillfällig utskrift i webbkontexten har ändå sin plats: Den visar vilken php.ini och vilka värden som faktiskt gäller för webbplatsen, för kommandoraden läser ofta en annan konfiguration. Bakgrunden om nivåer och företräde förklarar php.ini förklarad. Behöver ni det, gör det åtkomstskyddat, med slumpmässigt filnamn och bara i några minuter.
För de flesta frågor finns ändå bättre vägar. En FPM-pools PHP-version står i dess konfiguration och i processlistan. Enskilda värden går att fråga efter med ett skript utanför webbroten via ini_get(), utan att allt röjs. Och i webbhotellspaneler visar gränssnittet den tilldelade versionen per webbplats, om än utan besked om backporter.
Hitta bortglömda filer: konkreta kontrollsteg
Så spårar ni upp gamla rester på en Linux-server. Kommandona läser bara och ändrar ingenting.
- Sök filer med phpinfo-anrop (anpassa sökvägen):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Kontrollera typiska filnamn, även utan träff i innehållet:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Bedöm träffarna: Inte varje fynd är en testfil. Administrationsverktyg, paneler eller ramverk kan använda
phpinfo()bakom en inloggning. Avgörande är om filen går att nå från internet utan inloggning. -
Se i loggen efter åtkomster innan ni raderar:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Radera och byt ut hemligheter: Stod ett lösenord eller en nyckel i utdata och filen var offentlig räknas värdet som känt. Ändra det.
Ett fynd med okänt skapandedatum och ett påfallande innehåll vid sidan av phpinfo-anropet kan också vara en bakdörr. Radera då inte bara utan säkra och låt granska, se Upptäcka och ta bort webshells.
Förebygg varaktigt i stället för att städa
Tre åtgärder ser till att ämnet inte kommer tillbaka. För det första: Ta upp phpinfo i listan disable_functions i php.ini för webbkontexten. Kontrollera först om er panel behöver funktionen för en statussida. Hur inställningen verkar och var dess gränser går står under Använd disable_functions rätt.
; php.ini för FPM eller Apache, starta därefter om alla PHP-processer
disable_functions = phpinfo
expose_php = Off
För det andra: Tillhandahåll bara via ett fast förlopp, till exempel via Git eller byggpipeline, så att inga enstaka filer hamnar för hand i webbroten. För det tredje: Statusinformation hör hemma i övervakning eller inventering, inte på en offentlig sida.
expose_php = Off tar dessutom bort headern som PHP använder för att meddela sin version i varje svar. Det ersätter ingen uppdatering men tar från automatiserade skannrar en bekväm uppgift. Den som har flera personer med serveråtkomst bör dessutom komma överens om en enkel regel: Testfiler raderas i samma arbetssteg som de skapades, inte ”senare”.
Hur hjälper PHP SOS konkret?
- Vi söker igenom era webbrötter efter phpinfo-filer, testskript och andra rester och bedömer varje fynd.
- Vi utvärderar åtkomsterna till funna filer och talar om vilka hemligheter ni bör byta ut.
- Vi belägger patchläget mot PHP2Shell via paketets changelog och processomstart i stället för via en versionsvisning.
- Vi genomför
disable_functions,expose_phpoch ytterligare härdningar varaktigt inom ramen för serverhärdning.
Slutsats: En phpinfo-fil skapas på sekunder och glöms lika snabbt. Den som söker och tar bort den nu stänger ett onödigt dataläckage och förlitar sig för patchläget på hållbara belägg.
Vanliga frågor
Är en phpinfo-fil i sig en säkerhetslucka?
Den öppnar ingen åtkomst men ger angripare en detaljerad beskrivning av servern: version, moduler, sökvägar, inställningar och beroende på miljön även miljövariabler. Det underlättar målinriktade angrepp och kan röja inloggningsuppgifter.
Bevisar versionsnumret i phpinfo att PHP2Shell är patchat?
Nej. Distributioner och webbhotell lägger ofta in rättelser som backport, och det visade numret förblir då detsamma. Patchläget belägger paketets changelog och leverantörens bekräftelse, dessutom omstarten av alla PHP-processer.
Vad gör man om en phpinfo-fil har varit offentlig en längre tid?
Radera filen, se i åtkomstloggen vem som har hämtat den och byt ut alla hemligheter som stod i utdata, till exempel databaslösenord eller API-nycklar från miljövariabler.
Kan jag stänga av phpinfo() helt?
Ja, via disable_functions i php.ini för webbkontexten. Kontrollera först om en panel eller en applikation använder funktionen för statussidor, och starta därefter om PHP-processerna.