Kort sagt: För säkerheten i php.ini är framför allt fyra områden viktiga: inga felmeddelanden utåt, säkra sessionscookies, begränsade uppladdningar och låsta värden som applikationer inte kan skriva över. Efter PHP2Shell tillkommer php.nets tillfälliga åtgärder, framför allt session.upload_progress.enabled=0. En säker konfiguration ersätter dock aldrig uppdateringen.
Varför php.ini är i fokus igen efter PHP2Shell
php.ini är PHP:s centrala konfigurationsfil. På många servrar sattes den upp en gång och rördes sedan knappt. Med PHP2Shell har det ändrats: För de två sårbarheterna CVE-2026-109618 och CVE-2026-109619 anger php.net tillfälliga åtgärder som sätter in just här.
Själva sårbarheterna finns i PHP-tolken. De är åtgärdade i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35, publicerade den 21 oktober 2026. En bra konfiguration hjälper ändå på två sätt: Den kan försvåra utnyttjandet, och den begränsar skadan om något trots allt tar sig igenom.
Många driftansvariga vet dessutom inte exakt vilka inställningar som gäller på deras server. Det är det första steget.
Vilken php.ini gäller på er server?
PHP kan beroende på driftläge läsa olika konfigurationsfiler. Kommandoraden, PHP-FPM och Apache med mod_php har under Debian och Ubuntu till exempel var sin mapp under /etc/php/<version>/. Den som bara ändrar CLI-filen ändrar ingenting för webbplatsen.
# Konfigurationsfiler för kommandoraden
php --ini
# Konfiguration för PHP-FPM (anpassa versionsnumret)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Kontrollera enskilda värden för PHP-FPM
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Dessutom kan värden stå i FPM-poolen, i Apache-konfigurationen, i .htaccess (bara mod_php) eller i .user.ini (FPM och CGI). Vilken version som faktiskt körs på servern och om en backport ingår reder artikeln Kontrollera PHP-version och patchstatus rätt ut.
Grundinställningar för bättre php.ini-säkerhet
Följande värden är lämpliga för de flesta produktionsservrar. Kontrollera i en testmiljö före användning att er applikation fungerar med alla värden.
; Ingen versionsuppgift i HTTP-headern
expose_php = Off
; Logga fel, men visa dem aldrig i webbläsaren
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Inkludera inga filer från externa adresser
allow_url_include = Off
; Låt allow_url_fopen vara aktivt bara om applikationen behöver det
allow_url_fopen = Off
; Sessioner: strikta, bara via HTTPS, inte läsbara med JavaScript
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Begränsa körtid och indata
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
allow_url_fopen behövs av vissa applikationer för uppdateringar eller gränssnitt. Stäng av det bara om ni har kontrollerat det i förväg. Funktioner som kör systemkommandon kan dessutom spärras; hur det går utan biverkningar förklarar guiden Använda disable_functions rätt.
php.nets tillfälliga åtgärder mot PHP2Shell
Om ni inte kan patcha direkt anger php.net flera inställningar som sänker risken. De är uttryckligen inget fullständigt skydd, utan en bro fram till uppdateringen.
; Stäng av session upload progress (även på grund av CVE-2026-115560)
session.upload_progress.enabled = 0
; Begränsa förfrågningsstorlek: 8M utan uppladdningar, 32M med uppladdningar
post_max_size = 8M
upload_max_filesize = 6M
; Endast PHP 8.5: inga backtraces vid allvarliga fel
fatal_error_backtraces = 0
Dessutom rekommenderar php.net att sätta memory_limit=-1 så att applikationer inte kan skriva över värdet, och att i stället dra minnesgränsen via container eller cgroup, inte via RLIMIT_AS eller RLIMIT_DATA. Den åtgärden hör hemma i FPM-poolen eller serverkonfigurationen och bör kombineras med en fungerande cgroup-gräns. Den fullständiga översikten finns under Omedelbara åtgärder när ni ännu inte kan patcha.
session.upload_progress.enabled=0 fungerar bara från php.ini, FPM-pool eller serverkonfiguration. Sätts den via ini_set() eller .user.ini får åtgärden ingen verkan. Starta därefter om alla workers.
Låsa värden mot överskrivning
Många applikationer sätter egna värden, till exempel för minne eller uppladdningar. Med php_admin_value och php_admin_flag fastställer ni inställningar så att varken ini_set() eller .user.ini kan ändra dem. I FPM-poolen ser det ut så här:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (utdrag)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
Under Apache med mod_php gäller samma logik med php_admin_value och php_admin_flag i VirtualHost-konfigurationen. Ladda därefter om tjänsten och kontrollera det aktiva värdet:
sudo systemctl reload php8.3-fpm
# Processernas starttid: Ligger den efter ändringen?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
En reload startar om PHP-FPM:s workers. Efter en PHP-uppdatering krävs däremot en fullständig omstart av alla PHP-processer, så att ingen gammal process fortsätter köra i minnet. Med flera webbplatser på en server lönar sig dessutom en egen pool per webbplats, mer om det i guiden open_basedir och isolering per webbplats.
Vanliga fel och en kort checklista
De flesta problem med php.ini beror inte på fel värden utan på värden på fel ställe. Typiskt är att CLI-filen ändrats medan webbplatsen körs via PHP-FPM. Lika ofta uteblir omstarten efter en ändring, eller så skriver en hostingpanel över den egna inställningen vid nästa sparning.
En andra klassiker är synliga felmeddelanden på den levande webbplatsen. De avslöjar sökvägar, databasnamn eller versioner och gör det lättare för angripare att orientera sig. Just efter en flytt eller nyinstallation står display_errors ofta på On igen.
Kontrollera de här punkterna efter varje ändring och efter varje PHP-uppdatering:
- Vilken konfigurationsfil läser webbdriftläget, och innehåller den era värden?
- Är
display_errorsochexpose_phpavstängda, och går det att skriva till felloggen? - Står
session.upload_progress.enabledpå0, satt via php.ini eller pool? - Är uppladdnings- och förfrågningsstorlekar begränsade så att de passar applikationen?
- Har alla PHP-processer en starttidpunkt efter den senaste ändringen?
Dokumentera resultatet med datum. Då går det senare att belägga när vilken inställning gällde.
Hur hjälper PHP SOS konkret?
- Vi tar reda på vilken konfiguration som faktiskt är aktiv i vilket driftläge.
- Vi sätter en avstämd grundkonfiguration och de tillfälliga åtgärderna mot PHP2Shell, testade med er applikation.
- Vi låser säkerhetsrelevanta värden mot överskrivning och startar om alla workers kontrollerat.
- Vi dokumenterar inställningar och kontrollresultat så att senare ändringar förblir spårbara.
Hur ett varaktigt skydd ser ut beskrivs i tjänsten Serverhärdning för PHP-webbservrar.
Vanliga frågor
Vilken php.ini använder min webbserver egentligen?
Det är ofta inte samma som på kommandoraden. PHP-FPM, Apache med mod_php och CLI har oftast egna konfigurationsmappar. Kontrollera därför den aktiva filen för respektive driftläge, till exempel med php-fpm -i eller en kontrollfil som läggs ut en kort stund.
Ersätter en säker php.ini PHP-uppdateringen?
Nej. Inställningarna minskar angreppsytan och försvårar utnyttjande men stänger ingen sårbarhet i PHP-tolken. Inte heller php.nets tillfälliga åtgärder mot PHP2Shell är ett fullständigt skydd, vilket uttryckligen sägs.
Vad är skillnaden mellan php_value och php_admin_value?
Värden som sätts med php_value kan applikationen ändra igen under körning. Värden via php_admin_value i FPM-poolen eller i Apache-konfigurationen är däremot låsta för applikationen, även mot ini_set() och .user.ini.
Måste jag starta om efter en ändring i php.ini?
Ja. PHP-FPM och Apache med mod_php läser konfigurationen bara vid start. Först efter en omstart eller reload av alla berörda tjänster gäller de nya värdena.