Aktuel situation: PHP2Shell. To kritiske PHP-sårbarheder (CVSS 9,2) tillader skadelig kode uden login. Rettelser siden 21.10.2026.Hvad der skal gøres nu →

Slå session.upload_progress fra: rigtigt og varigt

Afhjælpningen mod CVE-2026-115560 og en af PHP2Shell-overgangsforanstaltningerne er hurtigt sat. For at den holder, skal den stå det rigtige sted, være låst og kontrolleres igen efter hver opdatering.

Status 5 min. læsetidHærdning og konfiguration

Kort sagt: Sæt session.upload_progress.enabled=0 i php.ini, i PHP-FPM-poolen eller i Apache-serverkonfigurationen, aldrig via ini_set() eller .user.ini, og genstart derefter alle PHP-workers. Foranstaltningen bliver først varig, når værdien er låst mod genaktivering, gælder i hver driftsform og hver installeret PHP-version og kontrolleres igen efter opdateringer.

En lille indstilling med dobbelt virkning

Sjældent har en enkelt PHP-indstilling fået så megen opmærksomhed. Da php.net den 21. oktober 2026 offentliggjorde patcherne mod PHP2Shell, stod session.upload_progress.enabled=0 på listen over overgangsforanstaltninger. To dage senere fulgte henvisningen om CVE-2026-115560, og den anbefalede afhjælpning var den samme indstilling.

Mange administratorer har sat den hurtigt i de dage. Om den virker overalt, er et andet spørgsmål. Typiske huller er hurtigt opregnet: Værdien står kun i CLI-konfigurationen, en anden PHP-version blev glemt, eller et hostingpanel overskrev filen ved næste lagring. Dette indlæg viser, hvordan I gennemfører foranstaltningen, så den også gælder om tre måneder.

Vigtigt på forhånd: Frakoblingen erstatter ikke PHP-opdateringen. Ifølge fagrapporter lukker session.upload_progress.enabled=0 alene ikke begge PHP2Shell-sårbarheder. Hvad CVE-2026-115560 præcis angår, forklarer siden CVE-2026-115560: Henvisningen om session-upload-progress.

Hvad funktionen gør, og hvem der har brug for den

Session-upload-progress skriver under en filupload løbende fremdriften ind i sessionen, så en applikation kan vise en statuslinje. I PHP er funktionen som standard slået til. PHP-manualen peger selv på, at filnavne og feltnavne leveret af afsenderen derved havner ukontrolleret i sessionslageret, og anbefaler at slå funktionen fra, hvis applikationen ikke bruger den.

Om jeres applikation bruger den, finder I ud af med en rent læsende søgning i koden:

# Søger efter brug af fremdriftsfunktionen i applikationskoden
grep -rn --include="*.php" -e "upload_progress" -e "PHP_SESSION_UPLOAD_PROGRESS" /var/www/

Finder søgningen intet, kan I slå funktionen fra uden mærkbare følger. Er der hits, mister applikationen kun fremdriftsvisningen, ikke uploaden. Moderne formularer måler under alle omstændigheder oftest fremdriften i browseren.

Sæt session.upload_progress.enabled det rigtige sted

Indstillingen har ifølge PHP-manualen tilstanden INI_PERDIR. Det betyder: Den kan sættes i php.ini, i serverkonfigurationen, i .htaccess (kun mod_php) og i .user.ini (kun FPM og CGI), men ikke under kørslen. php.net udelukker udtrykkeligt .user.ini som sted for foranstaltningen. Tabellen nedenfor viser de fornuftige steder pr. driftsform.

Driftsform Anbefalet sted Låser mod overskrivning? Genstart derefter
PHP-FPM pool-fil med php_admin_flag ja hver FPM-tjeneste
PHP-FPM php.ini for FPM-SAPI'en nej, .user.ini kunne overskrive hver FPM-tjeneste
Apache med mod_php VirtualHost eller serverkonfiguration med php_admin_flag ja Apache fuldstændigt
php-cgi, LiteSpeed, FrankenPHP php.ini for den pågældende runtime kontrollér afhængigt af opbygningen alle processer i runtime
Docker-image egen fil i /usr/local/etc/php/conf.d/ ved bygningen ja, hvis ingen override er tilladt opret containeren påny

De to robuste varianter ser sådan ud:

; PHP-FPM, f.eks. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[session.upload_progress.enabled] = off
# Apache med mod_php, i VirtualHost eller serverdækkende
<IfModule php_module>
    php_admin_flag session.upload_progress.enabled off
</IfModule>

Desuden er posten i php.ini for hver web-SAPI umagen værd som grundværdi. Så gælder indstillingen også for nye pools, som nogen opretter senere. Hvorfor php_admin_flag gør forskellen, beskriver indlægget php_admin_value: Lås indstillinger mod overskrivning.

Kontrollér virkningen i webkonteksten

Kommandolinjen læser ofte en anden php.ini end webserveren. Et php -i beviser derfor lidt. Også php-fpm8.3 -i viser kun php.ini-værdierne, ikke posterne fra poolene. Pålidelig er kun en forespørgsel, der faktisk kører gennem poolen.

Sådan går I frem:

  1. Genstart alle PHP-tjenester, for eksempel systemctl restart php8.3-fpm eller Apache ved mod_php. Uden genstart kører den gamle værdi videre.
  2. Læg en kort kontrolfil med tilfældigt navn i webroden, som kun udskriver den aktuelle værdi.
  3. Kald filen én gang via det rigtige domæne, og notér resultatet.
  4. Slet filen med det samme igen, og gentag trinnet for hvert website og hver pool.
<?php
// Kontrolfil: læg den kun kort, slet den derefter med det samme
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";

Forventet er en tom værdi eller '0'. Står der '1', virker jeres indstilling ikke i denne pool. Efter en PHP-opdatering kontrollerer I desuden, om alle workers er genstartet, som beskrevet under Genstart PHP-FPM og alle workers.

Vigtigt

Lad aldrig kontrolfiler blive liggende. De afslører versioner og konfiguration og er et populært mål for automatiserede scanninger.

Så indstillingen bliver varigt

De fleste tilbagefald opstår ikke på grund af angribere, men på grund af driften. En ny pool kopieres fra en gammel skabelon, en pakkeopdatering lægger en ny php.ini, eller nogen omstiller PHP-versionen i hostingpanelet. Mod sådanne tilbagefald hjælper faste vaner.

  • Dæk alle versioner: På mange servere kører flere PHP-versioner parallelt. Hver har egne konfigurationsmapper og kræver posten.
  • Tilpas skabeloner: Pool-skabeloner, Ansible-roller, Dockerfiles og panelskabeloner indeholder værdien, så nye websites arver den automatisk.
  • Brug panelindstillinger: I hostingpaneler hører værdien hjemme i de tillægsdirektiver, som panelet har afsat til formålet, ellers overskriver næste ændring håndarbejdet.
  • Kontrollér efter opdateringer: Kontrollen fra det forrige afsnit hører med i tjeklisten for hver PHP-opdatering.
  • Dokumentér: Notér dato, server, pools og resultat. Det hjælper senere over for ledelse, forsikringsselskab eller revisorer.

Den, der slet ikke bruger .user.ini, kan slå indlæsningen af sådanne filer helt fra med user_ini.filename = i php.ini. Det berører dog alle indstillinger, som applikationer lægger dér. Test derfor dette skridt på forhånd, især ved CMS, der skriver egne .user.ini-filer.

De øvrige overgangsforanstaltninger fra php.net, f.eks. grænserne for post_max_size og hukommelsesgrænsen via cgroup, står samlet under Akutforanstaltninger, hvis I endnu ikke kan patche. Hvordan PHP grundlæggende ordner sine konfigurationsniveauer, forklarer php.ini forklaret.

Hvordan hjælper PHP SOS konkret?

  • Opgør beholdningen: Vi finder alle PHP-versioner, driftsformer og pools på jeres servere og udlæser de virksomme værdier i webkonteksten.
  • Sæt rent: Vi indfører indstillingen låst i pools og serverkonfiguration og genstarter alle workers kontrolleret.
  • Test funktionen: Upload-formularer og mediehåndtering kontrollerer vi efter omstillingen.
  • Forhindr tilbagefald: Skabeloner, deployments og panelindstillinger tilpasser vi og dokumenterer tilstanden inden for rammerne af serverhærdningen.

Ofte stillede spørgsmål

Hvorfor virker session.upload_progress.enabled=0 ikke via ini_set()?

Indstillingen hører ifølge PHP-manualen til tilstanden INI_PERDIR. Den kan derfor slet ikke ændres under kørslen med ini_set(). php.net nævner php.ini, FPM-poolen eller serverkonfigurationen som de rigtige steder og udelukker udtrykkeligt .user.ini.

Fungerer filuploads stadig efter frakoblingen?

Ja. Der slås kun den fremdriftsmeddelelse fra, som PHP skriver ind i sessionen under en upload. Selve uploaden kører videre. Berørt er kun applikationer, der bygger deres statuslinje netop på denne PHP-funktion.

Kan en applikation slå funktionen til igen?

Via en .htaccess-fil ved mod_php eller en .user.ini ved PHP-FPM er det principielt muligt, så længe værdien ikke er låst. Med php_admin_flag i poolen eller i Apache-konfigurationen forhindrer I det.

Skal jeg sætte værdien tilbage efter næste PHP-opdatering?

Nej, det er ikke nødvendigt. Funktionen bruges ikke af de fleste applikationer, og PHP-manualen råder selv til at slå den fra i sådanne tilfælde. Kontrollér efter hver opdatering blot, om værdien stadig gælder.

Kilder

Akut kontakt

Hver time tæller. Skriv til os nu.

Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.

Akut hjælp