Kort sagt: Sätt session.upload_progress.enabled=0 i php.ini, i PHP-FPM-poolen eller i Apache-serverkonfigurationen, aldrig via ini_set() eller .user.ini, och starta därefter om alla PHP-workers. Permanent blir åtgärden först när värdet är spärrat mot återaktivering, gäller i varje driftläge och varje installerad PHP-version och kontrolleras efter uppdateringar.
En liten inställning med dubbel verkan
Sällan har en enskild PHP-inställning fått så mycket uppmärksamhet. När php.net den 21 oktober 2026 publicerade patcharna mot PHP2Shell stod session.upload_progress.enabled=0 på listan över övergångsåtgärder. Två dagar senare följde meddelandet om CVE-2026-115560, och den rekommenderade åtgärden var samma inställning.
Många administratörer satte den snabbt de dagarna. Om den verkar överallt är en annan fråga. Typiska luckor är snabbt uppräknade: värdet står bara i CLI-konfigurationen, en andra PHP-version glömdes, eller en webbhotellspanel skrev över filen vid nästa sparande. Det här inlägget visar hur ni genomför åtgärden så att den fortfarande gäller om tre månader.
Viktigt i förväg: avstängningen ersätter inte PHP-uppdateringen. Enligt fackrapporter stänger session.upload_progress.enabled=0 ensamt inte båda PHP2Shell-sårbarheterna. Vad CVE-2026-115560 exakt berör förklarar sidan CVE-2026-115560: meddelandet om session upload progress.
Vad funktionen gör och vem som behöver den
Session upload progress skriver under en filuppladdning löpande förloppet till sessionen, så att en applikation kan visa en förloppsindikator. I PHP är funktionen påslagen som standard. PHP-manualen påpekar själv att fil- och fältnamn som levereras av avsändaren då hamnar ogranskade i sessionslagret, och rekommenderar att stänga av funktionen om applikationen inte använder den.
Om er applikation använder den tar ni reda på med en rent läsande sökning i koden:
# Söker efter användning av förloppsfunktionen i applikationskoden
grep -rn --include="*.php" -e "upload_progress" -e "PHP_SESSION_UPLOAD_PROGRESS" /var/www/
Hittar sökningen ingenting kan ni stänga av funktionen utan märkbara följder. Finns det träffar förlorar applikationen bara förloppsvisningen, inte uppladdningen. Moderna formulär mäter oftast förloppet i webbläsaren ändå.
Sätta session.upload_progress.enabled på rätt ställe
Inställningen har enligt PHP-manualen läget INI_PERDIR. Det betyder: den kan sättas i php.ini, i serverkonfigurationen, i .htaccess (bara mod_php) och i .user.ini (bara FPM och CGI), men inte vid körning. php.net utesluter uttryckligen .user.ini som plats för åtgärden. Tabellen nedan visar de rimliga platserna per driftläge.
| Driftläge | Rekommenderad plats | Spärrar mot överskrivning? | Starta därefter om |
|---|---|---|---|
| PHP-FPM | Poolfil med php_admin_flag |
ja | varje FPM-tjänst |
| PHP-FPM | php.ini för FPM-SAPI | nej, .user.ini kan skriva över |
varje FPM-tjänst |
| Apache med mod_php | VirtualHost eller serverkonfiguration med php_admin_flag |
ja | Apache fullständigt |
| php-cgi, LiteSpeed, FrankenPHP | php.ini för respektive körmiljö | kontrollera beroende på uppbyggnad | alla processer i körmiljön |
| Docker-image | egen fil i /usr/local/etc/php/conf.d/ vid bygget |
ja, om ingen override tillåts | skapa om containern |
De två robusta varianterna ser ut så här:
; PHP-FPM, t.ex. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[session.upload_progress.enabled] = off
# Apache med mod_php, i VirtualHost eller servergemensamt
<IfModule php_module>
php_admin_flag session.upload_progress.enabled off
</IfModule>
Dessutom lönar sig posten i php.ini för varje webb-SAPI som grundvärde. Då gäller inställningen även för nya pooler som någon skapar senare. Varför php_admin_flag gör skillnaden beskriver inlägget php_admin_value: spärra inställningar mot överskrivning.
Kontrollera verkan i webbkontexten
Kommandoraden läser ofta en annan php.ini än webbservern. Ett php -i bevisar därför lite. Även php-fpm8.3 -i visar bara php.ini-värdena, inte posterna från poolerna. Tillförlitlig är bara en förfrågan som faktiskt körs via poolen.
Så går ni till väga:
- Starta om alla PHP-tjänster, till exempel
systemctl restart php8.3-fpmeller Apache vid mod_php. Utan omstart fortsätter det gamla värdet att gälla. - Lägg en kort kontrollfil med slumpmässigt namn i webbroten som bara skriver ut det aktuella värdet.
- Anropa filen en gång via den riktiga domänen och anteckna resultatet.
- Radera filen direkt igen och upprepa steget för varje webbplats och varje pool.
<?php
// Kontrollfil: lägg ut den bara kort, radera den därefter direkt
header('Content-Type: text/plain');
echo 'session.upload_progress.enabled = ', var_export(ini_get('session.upload_progress.enabled'), true), "\n";
echo 'PHP ', PHP_VERSION, ' / SAPI ', PHP_SAPI, "\n";
Förväntat är ett tomt värde eller '0'. Står det '1' verkar er inställning inte i den poolen. Efter en PHP-uppdatering kontrollerar ni dessutom att alla workers har startats om, som beskrivs i Starta om PHP-FPM och alla workers.
Låt aldrig kontrollfiler ligga kvar. De avslöjar versioner och konfiguration och är ett omtyckt mål för automatiserade skanningar.
Så att inställningen förblir permanent
De flesta bakslag uppstår inte genom angripare utan genom driften. En ny pool kopieras från en gammal mall, en paketuppdatering skapar en ny php.ini, eller någon ställer om PHP-versionen i webbhotellspanelen. Mot sådana bakslag hjälper fasta vanor.
- Täck alla versioner: På många servrar körs flera PHP-versioner parallellt. Var och en har egna konfigurationsmappar och behöver posten.
- Anpassa mallar: Poolmallar, Ansible-roller, Dockerfiles och panelmallar innehåller värdet, så att nya webbplatser ärver det automatiskt.
- Använd panelinställningarna: I webbhotellspaneler hör värdet hemma i de tilläggsdirektiv som panelen tillhandahåller, annars skriver nästa ändring över handarbetet.
- Kontrollera efter uppdateringar: Kontrollen från föregående avsnitt hör hemma i checklistan för varje PHP-uppdatering.
- Dokumentera: Anteckna datum, server, pooler och resultat. Det hjälper senare gentemot ledning, försäkringsgivare eller granskare.
Den som överhuvudtaget inte använder .user.ini kan stänga av inläsningen av sådana filer helt med user_ini.filename = i php.ini. Det berör dock alla inställningar som applikationer lägger där. Testa därför det steget i förväg, särskilt för CMS som skriver egna .user.ini-filer.
De övriga övergångsåtgärderna från php.net, till exempel gränserna för post_max_size och minnesgränsen via cgroup, finns samlade under Akuta åtgärder när ni ännu inte kan patcha. Hur PHP i grunden ordnar sina konfigurationsnivåer förklarar php.ini förklarad.
Hur hjälper PHP SOS konkret?
- Ta inventering: Vi tar reda på alla PHP-versioner, driftlägen och pooler på era servrar och läser ut de verksamma värdena i webbkontexten.
- Sätta rent: Vi lägger in inställningen spärrad i pooler och serverkonfiguration och startar om alla workers kontrollerat.
- Testa funktionen: Uppladdningsformulär och mediehantering kontrollerar vi efter omställningen.
- Förhindra bakslag: Mallar, driftsättningar och panelinställningar anpassar vi och dokumenterar läget inom ramen för serverhärdningen.
Vanliga frågor
Varför verkar inte session.upload_progress.enabled=0 via ini_set()?
Inställningen hör enligt PHP-manualen till läget INI_PERDIR. Den kan därför inte ändras vid körning med ini_set() överhuvudtaget. php.net anger php.ini, FPM-poolen eller serverkonfigurationen som rätt platser och utesluter uttryckligen .user.ini.
Fungerar filuppladdningar fortfarande efter avstängningen?
Ja. Det som stängs av är bara förloppsmeddelandet som PHP skriver till sessionen under en uppladdning. Själva uppladdningen fortsätter. Berörda är bara applikationer som bygger sin förloppsindikator på just den PHP-funktionen.
Kan en applikation slå på funktionen igen?
Via en .htaccess-fil vid mod_php eller en .user.ini vid PHP-FPM är det i princip möjligt så länge värdet inte är spärrat. Med php_admin_flag i poolen eller i Apache-konfigurationen förhindrar ni det.
Måste jag återställa värdet efter nästa PHP-uppdatering?
Nej, det behövs inte. Funktionen behövs inte i de flesta applikationer, och PHP-manualen råder själv att stänga av den i sådana fall. Kontrollera efter varje uppdatering bara att värdet fortfarande gäller.