Lyhyesti: Monet PHP2Shell-vinkit, jotka kiertävät juuri nyt foorumeilla ja sosiaalisessa mediassa, eivät suojaa tai jopa vahingoittavat: session-evästeen sisältävien pyyntöjen estäminen, virheilmoitusten piilottaminen, asetusten tekeminen .user.ini-tiedostolla tai pelkän CMS:n päivittäminen. php.net on yksiselitteinen: täydellisiä väliaikaistoimia ei ole, PHP-päivitys ja kaikkien prosessien uudelleenkäynnistys on ainoa turvallinen tie.
Miksi vääränlaiset vinkit ovat tässä tilanteessa vaarallisia
Kriittisen, paljon huomiota saavan aukon yhteydessä syntyy markkinat nopeille ratkaisuille. Neuvoja jaetaan, lyhennetään ja välitetään eteenpäin, usein alkuperäisen lähteen rajoituksitta. PHP2Shellin kohdalla lisäksi yksityiskohdat tulivat raporttien mukaan tietoon jo ennen virallista ajankohtaa ja tilanne oli ensimmäisinä päivinä sekava.
Väärä vinkki vahingoittaa kahdesti. Se jättää aukon auki ja luo tunteen, että jotain on tehty. Juuri tämä tunne saa varsinaisen päivityksen jäämään tekemättä. Jotkut neuvot lamauttavat lisäksi oman verkkosivuston.
Yhdeksän neuvoa faktantarkistuksessa
Seuraava taulukko tiivistää, mitä olemme viime päivinä usein lukeneet, ja asettaa väitteet ensisijaisten lähteiden lausuntoja vasten.
| Kiertävä vinkki | Miksi se ei kanna | Mikä pätee sen sijaan |
|---|---|---|
Estä kaikki pyynnöt, joissa on PHPSESSID |
Asiantuntijat torjuvat nimenomaisesti; lamauttaa kirjautumiset ja ostoskorit | Päivitä PHP |
session.upload_progress.enabled=0 riittää |
Ei asiantuntijaraporttien mukaan sulje molempia aukkoja | Järkevä väliaikaistoimi, päivitys pysyy pakollisena |
Aseta arvot ini_set()-funktiolla tai .user.ini-tiedostolla |
php.net neuvoo nimenomaisesti olemaan tekemättä niin | Palvelinpuolella php.ini-tiedostossa, FPM-poolissa tai palvelinkonfiguraatiossa |
| Piilota virheilmoitukset | php.netin mukaan error_reporting, display_errors tai @ eivät auta |
Päivitys; virhetulostetta ei silti saa näyttää julkisesti |
Rajoita muisti asetuksilla RLIMIT_AS tai RLIMIT_DATA |
php.net varoittaa, että juuri se voi laukaista haavoittuvan tilanteen | Raja kontin tai cgroupin kautta |
| Päivitä WordPress tai lisäosat | Aukko on PHP-tulkissa, ei CMS:ssä | Päivitä PHP-ajoympäristö |
| Cloudflare tai muu WAF riittää | Suoja vain palvelun kautta kulkevalle liikenteelle; suoraan tavoitettavat palvelimet jäävät auki | WAF lisäkerroksena, ei korvikkeena |
| Lataa palvelu uudelleen käynnistämisen sijaan | Red Hatin mukaan uudelleenlataus ei riitä, olemassa olevat workerit voivat säilyttää vanhan tilan | Käynnistä kaikki workerit kokonaan uudelleen |
| Päivitetty tarkoittaa puhdasta | Päivitys ei poista aiemmin sisään tuotua haittaohjelmaa | Tallenna lokit 20.10. alkaen ja tarkista jäljet |
Kolme yleisintä harhaluuloa tarkemmin
Evästekielto
Vinkki hylätä kaikki pyynnöt, joissa on session-eväste PHPSESSID, kuulostaa teknisesti päättäväiseltä. Asiantuntijat torjuvat sen nimenomaisesti. Käytännössä se rikkoo kaiken, mikä tarvitsee istunnon: asiakastilit, ostoskorit, ylläpitoalueet, väärennyssuojalla varustetut lomakkeet. Suojaa aukkoa vastaan se ei ole.
Se yksi asetus, joka ratkaisee kaiken
session.upload_progress.enabled=0 on php.netin suosituksissa ja CVE-2026-115560:n osalta mainittu korjaava toimi. Joissain artikkeleissa siitä tuli ”PHP2Shell kytketty pois”. Asiantuntijaraporttien mukaan tämä asetus yksin ei kuitenkaan sulje molempia aukkoja. Myös memory_limit=-1 poistaa php.netin mukaan vain ohjattavan laukaisijan; syvemmän tason muistivirhe voi yhä tavoittaa haavoittuvan polun. PHP 8.5:ssä fatal_error_backtraces=0 estää php.netin mukaan vain vahvistetun reitin backtracejen kautta.
Miten asetuksen silti tehdään oikein ja pysyvästi, kuvaa artikkeli session.upload_progress:n poistaminen käytöstä. Väliaikaistoimien täydellinen luettelo löytyy kohdasta Pikatoimet ilman päivitystä.
Suojakilpi edessä
Cloudflaren omien tietojen mukaan sillä on ollut 21. lokakuuta alkaen käytössä suojasäännöt, myös ilmaisen paketin asiakkaille. Cloudflare itse kuitenkin huomauttaa rajoista: suoja tehoaa vain liikenteeseen, joka kulkee Cloudflaren kautta. Jos alkuperäpalvelin on tavoitettavissa suoraan, suoja kierretään. Lisäksi Cloudflare tarkistaa myös palvelimen vastauksen, koska pelkkä pyyntö ei aina riitä. Miksi WAF ei korvaa päivitystä, selittää artikkeli WAF vai päivitys.
Vinkki, jossa on riski: latauspyyntöjen suodattaminen reunalla
Kaikki epämukavat neuvot eivät ole vääriä. Asiantuntijat ehdottavat väliaikaisena, epävirallisena toimena estämään multipart/form-data-pyynnöt todellisten latauspolkujen ulkopuolella välityspalvelimella tai WAF:ssa. Se voi pienentää hyökkäyspintaa, mutta rikkoo lomakkeet ja lataukset, jos sallittujen polkujen lista on puutteellinen.
Joka valitsee tämän tien, testatkoon sen ensin testiympäristössä, sopikoon siitä osastojen kanssa ja dokumentoikoon sen määräaikaisena toimena. Sekään ei korvaa päivitystä.
Monet WAF-ratkaisut tarjoavat siihen seurantatilan, jossa säännöt aluksi vain kirjaavat estämisen sijaan. Antakaa uuden säännön toimia näin muutaman päivän ja arvioikaa, mitkä oikeutetut pyynnöt vaikuttaisivat. Vasta sen jälkeen vaihtakaa estotilaan. Näin vältätte, että hakulomakkeet, asiakasportaalit tai kuvien lataus verkkokaupassa lakkaavat huomaamatta toimimasta.
Näin tarkistatte vinkin ennen toteuttamista
Neljä kysymystä erottaa käyttökelpoiset neuvot vaarallisista:
- Lähde: Onko suositus peräisin php.netistä, jakelustanne, BSI:ltä tai nimeltä mainitulta asiantuntijalta?
- Väite: Kuvataanko toimi väliaikaiseksi vai ratkaisuksi? PHP2Shellin kohdalla vain päivitys on ratkaisu.
- Sivuvaikutus: Mikä rikkoutuu, kun toimi tehoaa? Vinkki ilman viittausta sivuvaikutuksiin on puutteellinen.
- Toteutuspaikka: Asetetaanko asetus palvelinpuolella ja ylikirjoittamattomana, ja seuraako sitä kaikkien workerien uudelleenkäynnistys?
Kirjatkaa ylös, mitkä väliaikaistoimet olette ottaneet käyttöön ja milloin. Näin voitte myöhemmin tarkistaa ne kohdennetusti ja nähdä, onko oletettu suoja viivästyttänyt varsinaista päivitystä.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme toimet, jotka teillä on jo toteutettu, ja erotamme tehokkaat tehottomista.
- Asennamme PHP-päivityksen, käynnistämme kaikki prosessit uudelleen ja todistamme tilan.
- Missä päivitys ei vielä ole mahdollinen, otamme käyttöön php.netin mukaiset väliaikaistoimet palvelinpuolella ja dokumentoituina.
- WAF:lla ja virtuaalisella päivityksellä täydennämme suojaa reunalla korvaamatta päivitystä.
Usein kysytyt kysymykset
Suojaako PHPSESSID-pyyntöjen estäminen?
Ei. Asiantuntijat torjuvat tämän kiertävän vinkin nimenomaisesti. Se lamauttaa kirjautumiset, ostoskorit ja lomakkeet sulkematta tulkin aukkoa.
Riittääkö session.upload_progress.enabled=0 PHP2Shelliä vastaan?
Ei. Asetus on yksi useista väliaikaistoimista, eikä se asiantuntijaraporttien mukaan sulje molempia aukkoja. Se on järkevä mutta ei korvaa PHP-päivitystä.
Auttaako display_errors-asetuksen poistaminen käytöstä?
PHP2Shellin kohdalla ei. php.net huomauttaa, ettei diagnostiikan piilottaminen asetuksilla error_reporting, display_errors tai @-operaattorilla auta. Tuotannossa display_errors tulee silti olla pois muista syistä.
Mistä tunnistan vakavasti otettavan vinkin?
Vakavasti otettava vinkki mainitsee lähteensä, kuvaa rajansa ja nimeää väliaikaistoimet väliaikaisiksi. Joka lupaa, että yksittäinen asetus tekee päivityksestä tarpeettoman, on PHP2Shellin kohdalla väärässä.