Lühidalt: Kes soovib PHP turvaaugu PHP2Shell täna veel suletuks saada, vajab nelja asja: õiget uuendust, kõigi PHP protsesside taaskäivitust, kontrolli juba sisse toodud kahjuliku koodi suhtes ja tõendit. Kas see puudutab teid? Helistage. Me aitame. Võtame selle kaugteel üle, esimesest sõnumist alates.
Ärge praegu midagi kustutage ega installige uuesti. Ka paikamisel kehtib: kõigepealt kindlustada, siis muuta. Kui midagi on juba sisse pääsenud, vajame failide ja logide seisu. Teatage hädaolukorrast, selgitame koos teiega järjekorra.
Miks turvaauk ei saa oodata
Kaks turvaauku CVE-2026-109618 ja CVE-2026-109619 asuvad PHP-s endas ja võimaldavad kahjulikku koodi kaugelt käivitada ilma sisselogimiseta. BSI (Saksamaa föderaalne infoturbeamet) on kuulutanud välja hoiatustaseme 3 (oranž) ja soovitab kohest uuendust. Kui see kohe ei õnnestu, tuleks veebiserverid ajutiselt võrgust eemaldada. Meediaaruannete järgi täheldati esimesi rünnakukatseid juba enne paikade avaldamist 21.10.2026. Cloudflare on rünnakukatseid täheldanud ja võtnud kasutusele kaitsereeglid, kuid hoiatab, et reeglitest üksnes päringuandmete põhjal ei piisa.
Oluline haldajatele: CMS-i uuendus PHP turvaauku ei sulge. Aruannete järgi ei plaani ka WordPress.org selle vastu uuendust, sest turvaauk asub interpretaatoris. Suletud saab see ainult PHP tasandil, see tähendab selles, mida teie server tegelikult käivitab.
Mida teha kohe
- Teadke sihtversiooni. Parandatud on PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. PHP 8.2 toetus lõpeb 31.12.2026, arvestage sellega.
- Kaardistage kõik süsteemid. Ka testserverid, konteineri kujutised ja vanad süsteemid, mis on internetist kättesaadavad.
- Selgitage välja vastutus. Majutuspakettide ja hallatavate serverite (Managed Server) puhul paigaldab uuenduse pakkuja. Küsige kirjalikult versiooni ja taaskäivituse kohta.
- Säilitage logid. Alates 20.10.2026, nagu soovitab erialaajakirjandus.
- Leppige kokku aken. Taaskäivitus katkestab lühidalt käimasolevad päringud. Määrake ajapunkt, mil keegi saab otsuseid teha.
- Ärge oodake, kui on lahti. Kui kohe paika panna ei saa, kaaluge meiega eraldamist või üleminekumeetmeid.
Kuidas PHP SOS konkreetselt aitab?
- Olukorra kaardistamine: Kaardistame süsteemid, PHP versioonid, töörežiimid, majutajad ja kättesaadavuse ning määrame järjekorra: kõigepealt kõige enam avatud süsteemid.
- Kindlustamine ja sulgemine: Kindlustame hetkeseisu, paigaldame uuenduse või viime majutuse tõendatult paigatud seisu ning käivitame kõik protsessid uuesti. Konteinerite puhul ehitame kujutise uuesti ja võtame kasutusele.
- Kontroll ja puhastamine: Kuna paik ei eemalda kahjulikku koodi, kontrollime varasema sissemurdmise märke ja puhastame vajaduse korral.
- Karastamine ja aruandlus: Saate kirjaliku tõendi iga süsteemi kohta ja soovitused, et järgmine uuendus läheks kiiremini. Teenuse sisu kirjeldab PHP paigateenus.
Uuendus, taaskäivitus, tõend: mis loeb
Kõige sagedasem viga on uuendus ilma taaskäivituseta. Kuni vanad protsessid töötavad mälus, jääb haavatav kood aktiivseks, kuigi failid on uued. Juhend on lehel PHP-FPM-i ja kõigi töötajate taaskäivitamine. Teine viga on uskuda näitu: distributsioonid ja majutajad pakuvad sageli tagasiporte, siis jääb versiooninumber samaks. Usaldusväärne on paketi muudatuslogi CVE-numbritega, Debiani perekonnas käsuga apt-get changelog <paket>.
Lisaks kehtib PHP käsiraamatu järgi alates turvaväljalasetest uus direktiiv memory_hard_limit_percent. Kui PHP versioon seda ei tunne, on see mõjutatud. Test on lühike:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
See tuleb käivitada iga versiooni ja töörežiimi jaoks, sest käsurida võib kasutada teist PHP versiooni kui veebiserver. Lõpuks fikseerime tulemuse, et saaksite seda näidata oma majutajale, kindlustajale või tellijale.
Kui uuendus kohe ei õnnestu
On põhjuseid, miks uuendus täna ei ole võimalik: vana rakendus, mis uuemates PHP versioonides ei tööta, majutaja ilma loata, konteineri kujutis kindlas torujuhtmes. Neil juhtudel nimetab php.net üleminekumeetmeid, mis ei ole selgesõnaliselt täielik kaitse: memory_limit=-1 seada nii, et rakendused ei saa seda üle kirjutada, piirata post_max_size, session.upload_progress.enabled=0 ja PHP 8.5-l fatal_error_backtraces=0, igal juhul koos taaskäivitusega. Lisaks tulevad servas olevad kaitsereeglid, mis uuendust ei asenda. Levinud nõu blokeerida kõik päringud, milles on PHPSESSID, lükkavad erialaautorid selgesõnaliselt tagasi.
Millised meetmed teie süsteemile sobivad ja mida need võivad rikkuda, arutame enne läbi. Rohkem lehel Kiirmeetmed, kui te veel paika panna ei saa ja teemas WAF ja virtuaalne paikamine. PHP 8.1 ja vanemate jaoks kehtib eraldi olukord, mida kirjeldab PHP 8.1 ja vanemad: mis nüüd kehtib.
Mida peaksite meile saatma
- Serverite ja majutajate loetelu, kui olemas
php -vväljund iga süsteemi kohta ja märge töörežiimi kohta- Märge, kas kasutusel on konteiner, Plesk, cPanel või hallatav pakkumine (Managed)
- soovitud ajaaken ja kontaktisik taaskäivituste jaoks
- Viited kõrvalekalletele alates 17.10.2026
Miks PHP SOS
Töötame Saksamaal tehtud (Made in Germany) lahendustega ja oleme koos oma küberspetsialistide partnervõrgustikuga spetsialiseerunud IT-turvalisusele üle 25 aasta. Teil on üks kontaktisik, kes saadab uuendust, kontrollib taaskäivitust ja esitab tõendi. Töötame kaugteel, ilma kohale sõitmata, ja dokumenteerime iga sammu. Me ei luba imesid: paik sulgeb turvaauku, kuid ei tõenda, et varem midagi ei juhtunud, ja seda me teile ka ütleme.
Kas see puudutab teid? Helistage. Me aitame.
Ärge jätke turvaauku kauem lahti. Helistage või kirjutage WhatsAppis. Võtame töö üle esimesest sõnumist ja jääme juurde, kuni juhtum on lõpetatud ja dokumenteeritud. Teatage nüüd hädaolukorrast.
Korduma kippuvad küsimused
Kas ma saan PHP turvaauku ise sulgeda või vajan abi?
Uuendus on administraatorile tehtav, kuid veaohtlik: see peab kehtima versioonile, mis tegelikult sisu edastab, ja kõik protsessid tuleb uuesti käivitada. Kes haldab mitut serverit, konteineri kujutist või erijoontega majutajat, säästab toega aega ja vigu.
Kas PHP tuleb pärast uuendust uuesti käivitada?
Jah. Uutest failidest üksi ei piisa, kuni vanad PHP protsessid töötavad mälus. Kõik töötajad ehk protsessid tuleb uuesti käivitada, mod_php puhul veebiserver.
Mida teha, kui minu PHP versioonile uuendust veel pole?
PHP 8.1 ja vanemate jaoks PHP projekt ametlikke uuendusi enam ei anna. Siis on vaja pakkuja tõendatult paigatud tagasiportimist, üleminekut hooldatud versioonile või üleminekumeetmeid, mis aga täielikku kaitset ei paku.
Kas piisab session.upload_progress.enabled seadmisest väärtusele 0?
Ei. Erialaaruannete järgi ei sulge see säte üksi mõlemat turvaauku, PHP uuendus jääb kohustuslikuks. Seadke see ainult php.ini-s, FPM-poolis või serveri seadistuses, mitte ini_set() ega .user.ini kaudu.
Kuidas ma tean, et turvaauk on pärast seda tõesti suletud?
Töötava süsteemi tõendi abil: versioon või paketi muudatuslogi, test uue direktiivi memory_hard_limit_percent suhtes ja kinnitus, et kõik protsessid on pärast uuendust uuesti käivitatud.