Trumpai: WordPress PHP saugumo spraga, apie kurią dabar pranešama, slypi ne WordPress, o po juo esančiame serverio PHP. Todėl WordPress atnaujinimas PHP2Shell neuždaro. Svarbiausia yra PHP pataisų būsena, visų PHP procesų paleidimas iš naujo ir tipinių slėptuvių, tokių kaip wp-content/uploads ir mu-plugins, patikra.
Kodėl WordPress atnaujinimas PHP2Shell neišsprendžia
WordPress yra PHP kalba parašyta programa. Spragos CVE-2026-109618 ir CVE-2026-109619 yra vienu lygiu žemiau, pačiame PHP interpretatoriuje. PHP komandos teigimu, jos leidžia vykdyti kenkėjišką kodą nuotoliniu būdu be prisijungimo. Naudojant Apache su mod_php buvo parodytas išnaudojimas, kuris įvyksta dar prieš pasileidžiant bet kokiam WordPress kodui.
Todėl svetainė su naujausiu branduoliu, naujausiais įskiepiais ir stipriais slaptažodžiais vis tiek gali būti pažeidžiama, jei po ja esantis PHP senas. Ir atvirkščiai: pataisytas PHP neįrodo, kad anksčiau nieko neįvyko. Pagrindus paaiškiname puslapyje Kas yra PHP2Shell?.
| Lygmuo | Kas atnaujina | Ar uždaro PHP2Shell? |
|---|---|---|
| WordPress branduolys (Core) | Jūs arba jūsų agentūra | Ne |
| Įskiepiai ir temos | Jūs arba jūsų agentūra | Ne |
| PHP serveryje | Talpintojas arba serverio administratorius | Taip, kartu su visų PHP procesų paleidimu iš naujo |
WordPress PHP saugumo spraga: patikrinkite PHP versiją
Valdymo skydelyje skiltyje Įrankiai > Svetainės sveikata > Informacija, dalyje „Serveris“, rasite PHP versiją, su kuria jūsų svetainė iš tikrųjų veikia. Tai patikimiau nei php -v komandinėje eilutėje, nes komandinė eilutė dažnai naudoja kitą PHP diegimą nei žiniatinklio serveris.
Vien rodomo numerio vis tiek nepakanka. Ištaisytos oficialios (upstream) versijos yra 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. Tačiau daug talpintojų taisymus įdiegia kaip atgalinį perkėlimą (backport); tada lieka rodomas senesnis numeris, nors pataisa jau įdiegta. Kaip nustatyti tikrąją būseną, aprašyta puslapyje Kaip teisingai patikrinti PHP versiją ir pataisų būseną. Kurias PHP versijas palaiko jūsų WordPress versija, pagal sistemos reikalavimus patikrinkite wordpress.org.
Kur WordPress mėgsta slėptis kenkėjiškas kodas
Po sėkmingo išpuolio užpuolikai dažniausiai palieka užpakalines duris, kad grįžtų ir po pataisos. WordPress turi tam žinomų vietų:
- wp-content/uploads/: skirta paveikslėliams ir PDF, ne PHP failams.
- wp-content/mu-plugins/: „Must-use“ įskiepiai įkeliami automatiškai ir jų negalima išjungti valdymo skydelyje.
- wp-config.php: čia yra prieiga prie duomenų bazės ir saugumo raktai; įterpta eilutė čia vos pastebima.
- .htaccess pagrindiniame kataloge ir poaplankiuose: peradresavimai tik paieškos sistemoms arba neįprastų failų plėtinių vykdymas.
- Temos, ypač
functions.php, taip pat išjungti, pamiršti įskiepiai. - Duomenų bazė: nauji administratoriai lentelėje
wp_users, svetimas JavaScript lentelėjewp_optionsarba įrašuose.
Nepavojingos pirmosios patikros su WP-CLI ir standartinėmis priemonėmis:
# Palyginti Core failus su oficialiomis kontrolinėmis sumomis
wp core verify-checksums
# Patikrinti įskiepius iš wordpress.org katalogo
wp plugin verify-checksums --all
# Išvardyti PHP failus įkėlimų aplanke
find wp-content/uploads -type f -name "*.php"
# Parodyti visus administratorius
wp user list --role=administrator
Rastas atvejis yra priežastis atidžiai tirti, bet dar ne įrodymas. Komercinių įskiepių taip patikrinti negalima. Plačiau rašoma vadove Užpakalinių durų paieška WordPress.
Neskubėkite trinti įtartinų failų. Pirmiausia išsaugokite failus, duomenų bazę ir serverio žurnalus nuo 2026 m. spalio 20 d. Be šių pėdsakų vėliau neįmanoma išsiaiškinti, ar nutekėjo duomenų.
Įskiepiai, temos ir administratoriaus prieigos kaip papildoma rizika
PHP2Shell nereikalauja įskiepio spragos. Tačiau kasdienybėje įskiepiai ir temos išlieka dažniausiu įsilaužimo keliu į WordPress svetaines. Kiekvienas įskiepis atneša savo kodą, savo įkėlimo funkcijas ir savo atnaujinimų ciklus. Nenaudojamus įskiepius reikėtų ištrinti, o ne tik išjungti, nes išjungti failai tebėra serveryje.
Dėl wp-login.php ir wp-admin galioja: mažai administratorių, asmeninės paskyros vietoje bendrų prieigų ir dviejų veiksnių prisijungimas. Jei XML-RPC nereikalingas, jį galima užblokuoti. Kilus įtarimui reikėtų pakeisti visus slaptažodžius ir saugumo raktus faile wp-config.php. Failų redaktorių valdymo skydelyje išjungiate taip pat ten:
define( 'DISALLOW_FILE_EDIT', true );
Ką WordPress valdytojai turėtų daryti dabar
- Paprašyti talpintojo raštu patvirtinti PHP pataisų būseną ir visų PHP procesų paleidimą iš naujo.
- Paprašyti saugoti serverio žurnalus nuo 2026 m. spalio 20 d.
- Atlikti pirmiau aprašytas patikras arba jas užsakyti.
- Atnaujinti WordPress, įskiepius ir temas. Tai teisingas žingsnis, bet jis nepakeičia 1 žingsnio.
- Pastebėjus keistų dalykų svetainės nepaleisti tiesiog toliau veikti, o leisti ją išvalyti.
Platformos atnaujinimas gali uždaryti žinomas WordPress ir įskiepių spragas. Jis negali nei sutaisyti PHP, nei pašalinti įterptų failų, nepriklausančių branduoliui.
Kaip PHP SOS padeda konkrečiai?
- Kartu su jumis ar jūsų talpintoju išsiaiškiname tikrąją jūsų WordPress svetainės PHP būseną, įskaitant atgalinius perkėlimus (backport) ir paleidimą iš naujo.
- Prieš ką nors keisdami išsaugome žurnalus, failus ir duomenų bazę.
- Tikriname branduolį, įskiepius, uploads, mu-plugins,
.htaccessir naudotojų paskyras dėl užpakalinių durų. - Radus pėdsakų kenkėjiškų programų šalinimas atlieka išvalymą, kol incidentas užbaigiamas ir dokumentuojamas; radinių nėra, diegimą sustiprinimo priemonėmis apsaugome pagal PHP2Shell skubią pagalbą.
Dažni klausimai
Ar dėl PHP2Shell turiu atnaujinti WordPress?
Naujausias WordPress visada tinka, tačiau PHP2Shell jis neuždaro. Spraga yra serverio PHP interpretatoriuje. Todėl reikia PHP atnaujinimo arba jūsų talpintojo patvirtinto atgalinio pataisos perkėlimo (backport) ir visų PHP procesų paleidimo iš naujo.
Ar saugumo įskiepis apsaugo nuo PHP2Shell?
Tik labai ribotai. Pats įskiepis veikia kaip PHP kodas WordPress viduje. Naudojant mod_php buvo parodytas išnaudojimas, kuris įvyksta dar prieš pasileidžiant bet kokiam programos kodui; įskiepis tokio išpuolio gali net nepastebėti.
Kodėl WordPress vis dar rodo seną PHP versiją, nors talpintojas jau įdiegė pataisą?
Daug talpintojų ir Linux distribucijų taisymus įdiegia kaip atgalinį perkėlimą (backport) į esamą versiją. Versijos numeris tada nesikeičia. Paprašykite talpintojo raštu patvirtinti pataisų būseną.
Ar aplanke wp-content/uploads gali būti PHP failas?
Įprastai ne. Įkėlimų aplankas skirtas medijai. PHP failas jame yra aiškus perspėjamasis ženklas; prieš jį ištrinant, jį reikia išsaugoti ir leisti specialistams ištirti.