Lyhyesti: Väliaikainen ratkaisu PHP2Shell-haavoittuvuuteen voi pienentää riskiä, mutta ei korvaa päivitystä. php.net mainitsee siihen kiinteät muisti- ja latausrajat, session upload progressin poistamisen käytöstä ja PHP 8.5:ssä fatal_error_backtraces=0. Jos sekään ei onnistu lyhyellä varoitusajalla, BSI suosittelee ottamaan verkkopalvelimen tilapäisesti pois verkosta.
Mitä väliaikainen ratkaisu voi tehdä ja mitä ei
php.netin väliaikaisten toimenpiteiden on tarkoitus vaikeuttaa olosuhteita, joissa haavoittuvuuksia CVE-2026-109618 ja CVE-2026-109619 voi hyödyntää. Ne eivät nimenomaisesti ole täysi suoja. Haavoittuvuudet on korjattu vain versioissa PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 tai palveluntarjoajanne vahvistamassa backportissa.
Toimenpiteet ovat järkeviä, kun päivitys ei vielä onnistu konkreettisesta syystä: huoltoikkuna on vielä edessä, sovellus on testattava ensin tai käytössänne on PHP 8.1 tai vanhempi, jolle ei ole enää virallista päivitystä. Silloin ne ovat silta eivätkä päämäärä.
Suunnitelkaa siksi väliaikaisen ratkaisun kanssa samalla päivitys: kuka toteuttaa sen, missä huoltoikkunassa ja kuka tarkistaa jälkeenpäin, että kaikki workerit on käynnistetty uudelleen? Ylimeno ilman päättymispäivää uhkaa muuttua pysyväksi tilaksi.
Vaihtoehto 1: palvelin tilapäisesti pois verkosta
BSI on antanut varoitustason 3 (oranssi) ja suosittelee ottamaan haavoittuvat verkkopalvelimet tilapäisesti pois verkosta, jos päivitystä ei voi tehdä heti. Jotkin palveluntarjoajat ovat tehneet niin varotoimena; se ei tarkoita, että nämä sivustot olisi hakkeroitu.
Monelle yritykselle verkkokaupan tai portaalin katkos on kallis. Punninta voi olla paikallaan: pääsy vain VPN:n tai sallittujen IP-osoitteiden kautta, staattinen huoltosivu PHP-sovelluksen tilalla tai yksittäisten, tarpeettomien verkkosivustojen sammuttaminen palvelimelta. Mitä vähemmän PHP on tavoitettavissa ulkoa, sitä pienempi on hyökkäyspinta-ala.
Tärkeää on tehdä päätös tietoisesti ja kirjata se ylös: kuka päätti milloin pitää palvelin verkossa ja mitä suojatoimia käytettiin? Se auttaa myöhemmin suhteessa vakuutusyhtiöön, tietosuojaan ja johtoon.
php.netin väliaikaiset toimenpiteet
| Toimenpide | Arvo | Huomautus |
|---|---|---|
memory_limit |
-1, ei ylikirjoitettavissa |
aseta silloin muistiraja kontin tai cgroupin kautta |
post_max_size |
8M ilman latauksia, 32M latausten kanssa |
upload_max_filesize sen alle |
| Muistiraja | kontin/cgroupin kautta | ei RLIMIT_AS- tai RLIMIT_DATA-rajoilla |
session.upload_progress.enabled |
0 |
php.ini-tiedostossa, poolissa tai palvelinkonfiguraatiossa, ei ini_set()-funktiolla eikä .user.ini-tiedostolla |
fatal_error_backtraces |
0 |
vain PHP 8.5 |
Asetus session.upload_progress.enabled=0 on samalla ratkaisu 23. lokakuuta ilmoitettuun haavoittuvuuteen CVE-2026-115560.
Väliaikaisen ratkaisun oikea asettaminen PHP-haavoittuvuuteen
Ratkaisevaa on paikka. Arvot on asetettava niin, ettei sovellus voi ylikirjoittaa niitä. Polut ja palvelunimet vaihtelevat jakelun mukaan; esimerkit lähtevät PHP 8.3:sta.
PHP-FPM, poolissa (esim. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; vain PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache mod_php:n kanssa, palvelimen konfiguraatiossa tai VirtualHostissa:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Muistiraja cgroupin kautta, tässä systemd:llä FPM-palvelulle. Arvon sovitatte palvelimeenne:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Sen jälkeen käynnistäkää kaikki workerit uudelleen, muuten mikään näistä ei tehoa: systemctl restart php8.3-fpm tai mod_php:n kanssa Apache. Miten tarkistatte, ettei vanhoja prosesseja ole enää käynnissä, kerrotaan sivulla PHP-FPM ja kaikkien workerien uudelleenkäynnistys. Konfiguraation yleistä koventamista kuvaa sivu php.ini:n turvallinen konfigurointi.
Testatkaa lataukset ja suuret lomakkeet muutoksen jälkeen. Liian niukka post_max_size voi estää tilauksia, hakulomakkeita tai mediatiedostojen latauksia. Se on yksi syy olla lykkäämättä päivitystä pitkään.
Lisäsuojakerrokset
Web Application Firewall tai virtuaalinen korjaus voi auttaa lisäkerroksena. Cloudflare on ottanut käyttöön suojasääntöjä mutta varoittaa itse, etteivät pelkkiin pyyntötietoihin perustuvat säännöt riitä. WAF on siksi täydennys eikä korvike. Lisää aiheesta sivulla WAF ja virtuaalinen korjaus.
Turvatkaa lisäksi palvelinlokit 20. lokakuuta alkaen. Mediaraporttien mukaan ensimmäinen hyökkäysyritys havaittiin jo 17. lokakuuta; lokit ovat perusta, jos myöhemmin täytyy selvittää, tapahtuiko jotain ennen korjausta.
Miten PHP SOS auttaa konkreettisesti?
- Tilanteen selvitys: Tarkistamme, onko päivitys mahdollinen lyhyellä varoitusajalla vai tarvitaanko ylimeno, ja käymme kanssanne läpi vaihtoehdon ottaa osia pois verkosta.
- Toimenpiteiden asettaminen: Kirjaamme php.netin arvot oikeaan paikkaan, asetamme cgroup-rajan ja käynnistämme kaikki workerit uudelleen.
- Toiminnan testaus: Lomakkeet, lataukset ja tilausprosessit tarkistamme muutoksen jälkeen.
- Tie korjaukseen: PHP-korjauspalvelun kautta suunnittelemme päivityksen ja perumme ylimenoarvot sen jälkeen hallitusti siellä, missä ne haittaavat.
Usein kysytyt kysymykset
Suojaako väliaikainen ratkaisu täysin PHP2Shellilta?
Ei. php.net kutsuu toimenpiteitä nimenomaisesti ylimenoksi eikä täydeksi suojaksi. Ne pienentävät riskiä, kunnes päivitys on asennettu. BSI (Saksan liittovaltion tietoturvavirasto) suosittelee ottamaan korjaamattomat palvelimet tilapäisesti pois verkosta.
Voinko asettaa asetukset .htaccess- tai .user.ini-tiedostolla?
Asetuksen session.upload_progress.enabled osalta php.net sulkee ini_set()-funktion ja .user.ini-tiedoston nimenomaisesti pois. Myös memory_limit-arvon osalta pätee: arvo on asetettava niin, ettei sovellus voi ylikirjoittaa sitä. Se onnistuu php.ini-tiedostossa, FPM-poolissa php_admin_value-direktiivillä tai Apachen palvelinkonfiguraatiossa.
Riittääkö Web Application Firewall väliaikaiseksi ratkaisuksi?
Lisäkerroksena se voi auttaa. Cloudflare on ottanut käyttöön suojasääntöjä mutta huomauttaa itse, etteivät pelkkiin pyyntötietoihin perustuvat säännöt riitä. WAF ei korvaa päivitystä eikä palvelimen väliaikaisia toimenpiteitä.
Mitä teen, jos minulla on vain jaettu hosting?
Silloin php.ini ja uudelleenkäynnistys ovat hosting-yrityksen hallinnassa. Kysykää täsmällisesti, onko päivitys asennettu tai väliaikaiset toimenpiteet asetettu ja onko kaikki PHP-prosessit käynnistetty uudelleen.