Na kratko: session.upload_progress.enabled=0 nastavite v php.ini, v poolu PHP-FPM ali v konfiguraciji strežnika Apache, nikoli prek ini_set() ali .user.ini, nato znova zaženite vse delavce PHP. Ukrep postane trajen šele, ko je vrednost zaklenjena pred ponovnim vklopom, velja v vsakem načinu delovanja in vsaki nameščeni različici PHP ter se po posodobitvah preverja.
Majhna nastavitev z dvojnim učinkom
Redko je ena sama nastavitev PHP dobila toliko pozornosti. Ko je php.net 21. oktobra 2026 objavil popravke proti PHP2Shell, je bil session.upload_progress.enabled=0 na seznamu prehodnih ukrepov. Dva dni pozneje je sledil napotek h CVE-2026-115560 in priporočeni ukrep je bil ista nastavitev.
Številni skrbniki so jo v teh dneh hitro nastavili. Ali deluje povsod, je drugo vprašanje. Tipične vrzeli so hitro naštete: vrednost je samo v konfiguraciji CLI, druga različica PHP je bila pozabljena ali pa je nadzorna plošča gostovanja datoteko ob naslednjem shranjevanju prepisala. Ta prispevek pokaže, kako ukrep izvedete tako, da velja še čez tri mesece.
Pomembno vnaprej: izklop ne nadomešča posodobitve PHP. Po strokovnih poročilih session.upload_progress.enabled=0 sam ne zapre obeh ranljivosti PHP2Shell. Kaj natanko zadeva CVE-2026-115560, pojasnjuje stran CVE-2026-115560: napotek o napredku nalaganja v seji.
Kaj funkcija počne in kdo jo potrebuje
Session-Upload-Progress med nalaganjem datoteke sproti zapisuje napredek v sejo, da lahko aplikacija prikaže indikator napredka. V PHP je funkcija privzeto vklopljena. Priročnik PHP sam opozarja, da pri tem imena datotek in polj, ki jih dostavi pošiljatelj, nepreverjena pristanejo v pomnilniku seje, in priporoča izklop funkcije, če je aplikacija ne uporablja.
Ali jo vaša aplikacija uporablja, ugotovite s povsem bralnim iskanjem po kodi:
# Poišče uporabe funkcije napredka v kodi aplikacije
grep -rn --include="*.php" -e "upload_progress" -e "PHP_SESSION_UPLOAD_PROGRESS" /var/www/
Če iskanje ničesar ne najde, lahko funkcijo izklopite brez občutnih posledic. Če so zadetki, aplikacija izgubi samo prikaz napredka, ne nalaganja. Sodobni obrazci napredek večinoma merijo že v brskalniku.
Nastavitev session.upload_progress.enabled na pravem mestu
Nastavitev ima po priročniku PHP način INI_PERDIR. To pomeni: nastavite jo lahko v php.ini, v konfiguraciji strežnika, v .htaccess (samo mod_php) in v .user.ini (samo FPM in CGI), ne pa med izvajanjem. php.net .user.ini kot mesto za ukrep izrecno izključuje. Naslednja tabela prikazuje smiselna mesta po načinu delovanja.
| Način delovanja | Priporočeno mesto | Zaklene pred prepisovanjem? | Nato znova zagnati |
|---|---|---|---|
| PHP-FPM | datoteka poola s php_admin_flag |
da | vsako storitev FPM |
| PHP-FPM | php.ini SAPI FPM | ne, .user.ini bi lahko prepisal |
vsako storitev FPM |
| Apache z mod_php | VirtualHost ali konfiguracija strežnika s php_admin_flag |
da | Apache v celoti |
| php-cgi, LiteSpeed, FrankenPHP | php.ini zadevnega izvajalnega okolja | preverite glede na zgradbo | vse procese izvajalnega okolja |
| Slika Docker | lastna datoteka v /usr/local/etc/php/conf.d/ ob gradnji |
da, če prepis ni dovoljen | vsebnik ustvarite znova |
Obe robustni različici sta videti takole:
; PHP-FPM, npr. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[session.upload_progress.enabled] = off
# Apache z mod_php, v VirtualHost ali za ves strežnik
<IfModule php_module>
php_admin_flag session.upload_progress.enabled off
</IfModule>
Dodatno se splača vnos v php.ini vsakega spletnega SAPI kot osnovna vrednost. Tako nastavitev velja tudi za nove poole, ki jih kdo ustvari pozneje. Zakaj php_admin_flag naredi razliko, opisuje prispevek php_admin_value: zaklepanje nastavitev pred prepisovanjem.
Preverjanje učinkovitosti v spletnem kontekstu
Ukazna vrstica pogosto bere drugo php.ini kot spletni strežnik. php -i zato malo dokazuje. Tudi php-fpm8.3 -i prikaže samo vrednosti iz php.ini, ne pa vnosov iz poolov. Zanesljiva je samo poizvedba, ki res teče prek poola.
Postopajte takole:
- Znova zaženite vse storitve PHP, na primer
systemctl restart php8.3-fpmali Apache pri mod_php. Brez ponovnega zagona stara vrednost teče naprej. - V spletni koren položite kratko preverjalno datoteko z naključnim imenom, ki izpiše samo trenutno vrednost.
- Datoteko enkrat pokličite prek prave domene in rezultat zabeležite.
- Datoteko takoj izbrišite in korak ponovite za vsako spletno stran in vsak pool.
<?php
// Preverjalna datoteka: položite samo za kratek čas, nato takoj izbrišite
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";
Pričakovana je prazna vrednost ali '0'. Če tam piše '1', vaša nastavitev v tem poolu ne deluje. Po posodobitvi PHP dodatno preverite, ali so vsi delavci znova zagnani, kot je opisano v Ponovni zagon PHP-FPM in vseh delavcev.
Preverjalnih datotek nikoli ne puščajte. Razkrivajo različice in konfiguracijo ter so priljubljena tarča samodejnih skeniranj.
Da nastavitev ostane trajno
Večina povratnih zdrsov ne nastane zaradi napadalcev, ampak zaradi delovanja. Nov pool se skopira iz stare predloge, posodobitev paketa ustvari novo php.ini ali pa nekdo v nadzorni plošči gostovanja preklopi različico PHP. Proti takim zdrsom pomagajo stalne navade.
- Pokrijte vse različice: na številnih strežnikih vzporedno teče več različic PHP. Vsaka ima lastne konfiguracijske mape in potrebuje vnos.
- Prilagodite predloge: predloge poolov, vloge Ansible, datoteke Dockerfile in predloge nadzorne plošče vsebujejo vrednost, da jo nove spletne strani samodejno podedujejo.
- Uporabljajte nastavitve nadzorne plošče: v nadzornih ploščah gostovanja vrednost sodi v dodatne direktive, ki jih nadzorna plošča predvideva, sicer naslednja sprememba prepiše ročno delo.
- Preverjajte po posodobitvah: preverjanje iz prejšnjega razdelka sodi v kontrolni seznam vsake posodobitve PHP.
- Dokumentirajte: zabeležite datum, strežnik, poole in rezultat. To pozneje pomaga nasproti vodstvu, zavarovalnici ali pregledovalcem.
Kdor .user.ini sploh ne uporablja, lahko branje takih datotek povsem izklopi z user_ini.filename = v php.ini. To pa zadeva vse nastavitve, ki jih aplikacije tam odlagajo. Ta korak zato vnaprej preizkusite, zlasti pri CMS, ki sami pišejo datoteke .user.ini.
Preostali prehodni ukrepi php.net, na primer meje za post_max_size in pomnilniška meja prek cgroup, so zbrani pod Takojšnji ukrepi, če popravka še ne morete namestiti. Kako PHP v osnovi ureja svoje konfiguracijske ravni, pojasnjuje Pojasnilo datoteke php.ini.
Kako PHP SOS pomaga konkretno?
- Popis stanja: ugotovimo vse različice PHP, načine delovanja in poole na vaših strežnikih ter v spletnem kontekstu preberemo veljavne vrednosti.
- Čista nastavitev: nastavitev zaklenjeno vnesemo v poole in konfiguracijo strežnika ter nadzorovano znova zaženemo vse delavce.
- Preizkus delovanja: obrazce za nalaganje in upravljanje medijev po prehodu preverimo.
- Preprečevanje zdrsov: predloge, namestitve in nastavitve nadzorne plošče prilagodimo ter stanje dokumentiramo v okviru utrjevanja strežnikov.
Pogosta vprašanja
Zakaj session.upload_progress.enabled=0 ne deluje prek ini_set()?
Nastavitev po priročniku PHP spada v način INI_PERDIR. Zato je med izvajanjem sploh ni mogoče spremeniti z ini_set(). php.net kot prava mesta navaja php.ini, pool FPM ali konfiguracijo strežnika in .user.ini izrecno izključuje.
Ali nalaganje datotek po izklopu še deluje?
Da. Izklopi se samo sporočanje napredka, ki ga PHP med nalaganjem zapisuje v sejo. Samo nalaganje teče naprej. Prizadete so samo aplikacije, ki svoj indikator napredka gradijo prav na tej funkciji PHP.
Ali lahko aplikacija funkcijo znova vklopi?
Prek datoteke .htaccess pri mod_php ali .user.ini pri PHP-FPM je to načeloma mogoče, dokler vrednost ni zaklenjena. S php_admin_flag v poolu ali v konfiguraciji Apache to preprečite.
Ali moram vrednost po naslednji posodobitvi PHP vrniti nazaj?
Ne, to ni potrebno. Večina aplikacij funkcije ne potrebuje, priročnik PHP pa sam svetuje, da jo v takih primerih izklopite. Po vsaki posodobitvi preverite samo, ali vrednost še velja.