Lyhyesti: PHP:n virtuaalinen korjaus kuroo umpeen ajan, kunnes todellinen päivitys on asennettu. Yhdistämme siihen Web Application Firewallin säännöt php.netin PHP2Shellistä julkaisemiin väliaikaisiin toimenpiteisiin ja sovimme samalla tien varsinaiseen korjaukseen. Täyttä suojaa se ei anna, mutta se pienentää riskiä siirtymäaikana.
Milloin PHP:n virtuaalinen korjaus on järkevä
PHP2Shellin osalta BSI (Saksan liittovaltion tietoturvavirasto) suosittelee välitöntä päivitystä ja, jos se ei onnistu, ottamaan verkkopalvelimet tilapäisesti pois verkosta. Monelle yritykselle kumpikaan ei ole heti mahdollista: verkkokaupan on pysyttävä tavoitettavissa, omakehitteinen sovellus tarvitsee testin ennen päivitystä tai palvelimella on PHP 8.1 tai vanhempi, jolle ei ole enää virallisia päivityksiä.
Näissä tapauksissa virtuaalinen korjaus on silta. Se ei korvaa päätöstä siitä, olisiko offline-tila asianmukaisempi. Tämän punninnan teette te, me toimitamme teknisen arvion.
Miksi pelkkä WAF ei riitä
Cloudflare ilmoitti havaituista hyökkäysyrityksistä ja on ottanut käyttöön suojasääntöjä, mutta varoittaa, etteivät pelkkiin pyyntötietoihin perustuvat säännöt riitä. Syy on haavoittuvuuksien luonteessa. Haavoittuvuudessa CVE-2026-109618 Out-of-Memory-tila voi keskeyttää PHP:n, kun pyyntötiedot on alustettu vain osittain. Haavoittuvuudessa CVE-2026-109619 sisäinen tila voi säilyä muistin vapauttamisen jälkeen ja myöhempi pyyntö samassa workerissa voi hyödyntää sitä. Tällaiset virheet riippuvat palvelimen tilasta, eivät vain yksittäisen pyynnön sisällöstä.
Siksi luotamme useisiin kerroksiin: WAF-säännöt ennen palvelinta, väliaikaiset toimenpiteet itse PHP:ssä ja palvelimen tehostettu tarkkailu. Jokainen kerros pysäyttää osan, mikään ei yksin riitä. Yhdessä ne antavat teille aikaa asentaa päivitys järjestelmällisesti.
php.netin mukaiset väliaikaiset toimenpiteet
php.net mainitsee useita asetuksia, jotka pienentävät riskiä, nimenomaisesti ilman täyttä suojaa. Tärkeää on, etteivät sovellukset voi ylikirjoittaa näitä arvoja. Esimerkki PHP-FPM-poolista, jossa on lataukset:
; PHP2Shellin väliaikaiset toimenpiteet (ei täyttä suojaa), sen jälkeen käynnistä kaikki workerit uudelleen
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; vain PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Ilman latauksia php.net suosittelee asetusta post_max_size = 8M. Koska memory_limit poistetaan, mukaan kuuluu muistiraja kontin tai cgroupin tasolla, ei RLIMIT_AS- tai RLIMIT_DATA-rajoilla. Asetus session.upload_progress.enabled=0 kuuluu php.ini-tiedostoon, FPM-pooliin tai palvelinkonfiguraatioon, ei ini_set()-funktioon eikä .user.ini-tiedostoon. Se on samalla ratkaisu haavoittuvuutta CVE-2026-115560 koskevaan ohjeeseen. Kaikki toimenpiteet yleiskatsauksena löytyvät sivulta Pikatoimet, jos ette voi vielä korjata.
Väliaikaiset toimenpiteet tehoavat vasta kaikkien PHP-workerien uudelleenkäynnistyksen jälkeen. Ja ne suojaavat vain tulevilta hyökkäyksiltä: ne eivät vastaa siihen, oliko joku päässyt sisään aiemmin.
Milloin offline-tila on parempi valinta
Virtuaalinen korjaus ei ole jokaisessa tilanteessa oikea vastaus. Joissakin tilanteissa neuvomme noudattamaan BSI:n ohjetta ja ottamaan verkkopalvelimen tilapäisesti pois verkosta, kunnes korjaus on tehty:
- palvelin toimii Apachella ja mod_php:llä, jossa PHP-tiimi arvioi riskin suurimmaksi ja jossa hyökkäys on esitetty ennen kuin sovelluskoodia ajetaan lainkaan
- palvelimella on erityisen suojattavia tietoja, esimerkiksi terveys-, asiakas- tai maksutietoja
- väliaikaisia toimenpiteitä ei voi asettaa pysyvästi palvelimen konfiguraatioon, esimerkiksi tietyissä jaetun hostingin paketeissa
- on jo merkkejä siitä, että palvelimeen on hyökätty
Tilapäinen offline-tila ei tarkoita, että verkkosivustonne olisi hakkeroitu. Jotkin palveluntarjoajat ovat ottaneet verkkosivustoja varotoimena pois verkosta. Lyhyt, asiallinen tiedotussivu kävijöille on silloin yleensä parempi ratkaisu kuin selittämätön katkos.
Miten PHP SOS auttaa konkreettisesti?
- Tilanteen tarkistus: Kokoamme PHP-versiot, ajotavat ja olemassa olevat suojakerrokset, kuten CDN:n, WAF:n tai käänteisen välityspalvelimen. Mod_php:n kohdalla huomautamme suuremmasta riskistä, jonka PHP-tiimi siinä näkee.
- Kerrosten rakentaminen: Aktivoimme tai täydennämme WAF-sääntöjä, asetamme väliaikaiset toimenpiteet pysyvästi palvelimen konfiguraatioon ja rajoitamme muistia kontin tai cgroupin kautta. Nginx-ympäristöissä noudatamme ohjetta Nginx PHP-FPM:n kanssa turvalliseksi.
- Uudelleenkäynnistys ja testi: Kaikki PHP-prosessit käynnistetään uudelleen, minkä jälkeen tarkistamme lataukset, lomakkeet, kirjautumisen ja kassan.
- Tarkkailu: Siirtymäaikana kiinnitämme erityistä huomiota workerien kaatumisiin, muistipiikkeihin ja epätavallisiin prosesseihin.
- Korjauksen suunnittelu: Sovimme, milloin ja miten varsinainen päivitys tulee, ja toteutamme sen PHP-korjauspalvelun kautta.
Mitä saatte, mitä tarvitsemme ja mitä emme lupaa
Saatte dokumentaation kaikista asetetuista säännöistä ja asetuksista perusteluineen, testitulokset sekä aikataulu- ja toimenpidesuunnitelman todellista korjausta varten. Tarvitsemme teiltä palvelin- tai paneelipääsyn, pääsyn CDN:ään tai WAF:iin, jos sellainen on, teknisen yhteyshenkilön ja tiedot sovellustenne lataustoiminnoista.
Emme lupaa, että virtuaalinen korjaus estää hyökkäyksen. Se pienentää riskiä rajatun ajan. PHP 8.1:n ja vanhempien kohdalla se ei ole pysyvä tila; silloin suunnitelmaan kuuluu siirtymä tuettuun versioon.
Usein kysytyt kysymykset
Mitä virtuaalinen korjaus on?
Virtuaalinen korjaus tarkoittaa tunnetun haavoittuvuuden suojaamista ennen sovellusta koodia itse muuttamatta. Se tehdään yleensä Web Application Firewallilla tai konfiguraatiomuutoksilla. Se on ylimenoratkaisu, ei päivityksen korvike.
Riittääkö CDN-palveluntarjoajani WAF PHP2Shelliä vastaan?
Yksinään ei yleensä. Cloudflare on ottanut käyttöön suojasääntöjä mutta varoittaa itse, etteivät pelkkiin pyyntötietoihin perustuvat säännöt riitä. WAF on lisäkerros väliaikaisten toimenpiteiden ja korjauksen rinnalla.
Kuinka kauan virtuaaliseen korjaukseen voi luottaa?
Mahdollisimman lyhyen aikaa. Sen on tarkoitus kuroa umpeen aika varsinaiseen päivitykseen asti, esimerkiksi kunnes huoltoikkuna vapautuu tai sovellus on testattu. PHP 8.1:n ja vanhempien kohdalla mukaan kuuluu siirtymäsuunnitelma.
Voivatko väliaikaiset toimenpiteet häiritä verkkosivustoani?
Kyllä, se on mahdollista. Pienemmät latausrajat voivat estää suurten tiedostojen lataukset, ja session upload progressin poistaminen käytöstä vaikuttaa latauksen edistymisnäyttöihin. Testaamme tärkeimmät toiminnot jokaisen muutoksen jälkeen.