Trumpai: WordPress užpakalines duris greičiausiai rasite palyginę branduolį ir įskiepius per WP-CLI su oficialiomis kontrolinėmis sumomis, o po to tikslingai peržiūrėję mu-plugins, įkėlimus, wp-config.php, administratoriaus paskyras ir duomenų bazę. Svarbu po PHP2Shell: WordPress atnaujinimas PHP pažeidžiamumo neuždaro ir esamų užpakalinių durų nepašalina.
Kodėl WordPress operatoriams dabar verta pažiūrėti atidžiau
Su PHP2Shell 2026 m. spalį paaiškėjo du kritiniai pačio PHP pažeidžiamumai, CVE-2026-109618 ir CVE-2026-109619. Jie leidžia vykdyti kenkėjišką kodą be prisijungimo, nepriklausomai nuo to, kaip gerai prižiūrima jūsų WordPress instaliacija. Pataisos prieinamos nuo 2026-10-21, tačiau pasak žiniasklaidos pranešimų, pirmasis atakos bandymas buvo pastebėtas jau spalio 17 d.
Kas tuo laikotarpiu buvo pažeidžiamas, turėtų ieškoti pėdsakų. WordPress yra tipinis taikinys, nes daug instaliacijų sukurta panašiai, o užpuolikai žino slėptuves. Ką operatoriai apskritai turi daryti dėl PHP2Shell, aprašyta puslapyje WordPress ir PHP2Shell.
Toliau pateiktas patikras atlikite pageidautina kopijoje arba po atsarginės kopijos sukūrimo. Komandos tik skaito ir nieko nekeičia.
Kaip užpakalines duris pastebėti kasdienybėje
Užpakalinės durys sukurtos taip, kad liktų nepastebimos. Vis dėlto yra požymių, kuriuos pastebės ir be techninių žinių. Tai peradresavimai į svetimas svetaines, kurie pasireiškia tik lankytojams iš Google paieškos arba tik mobiliuosiuose įrenginiuose. Taip pat įtartini nauji puslapiai su vaistų, lošimų ar prekių ženklų kopijų reklama, kurie rodomi paieškos indekse, bet ne WordPress administravimo srityje.
Kiti požymiai yra Google ar naršyklės įspėjimai, klientų skundai dėl šlamšto laiškų iš jūsų domeno, staiga smarkiai išaugęs skaičiavimo laiko naudojimas pas hostingo teikėją arba administratoriai, kurių niekas komandoje nepažįsta. Nė vienas iš šių ženklų pats savaime užpakalinių durų neįrodo. Jei pasirodo keli kartu, toliau nurodytų patikrų neatidėliokite.
Ir atvirkščiai: jei nieko iš to nepastebima, tai nereiškia, kad instaliacija švari. Būtent užpakalinės durys, įrengtos tik vėlesnei prieigai, išorėje dažnai nesukelia jokio poveikio.
WordPress užpakalinių durų paieška: branduolio ir įskiepių patikra
WP-CLI gali palyginti WordPress branduolio ir oficialiame kataloge esančių įskiepių failus su paskelbtomis kontrolinėmis sumomis. Kiekvienas neatitikimas yra konkreti patikros užduotis.
cd /var/www/meine-seite
# Branduolio failai pagal oficialias kontrolines sumas
wp core verify-checksums
# Įskiepiai iš oficialaus katalogo
wp plugin verify-checksums --all
# Įdiegtos versijos ir būsena
wp plugin list
wp theme list
Komercinių įskiepių ir temų taip patikrinti neįmanoma. Joms padeda tik palyginimas su ką tik parsisiųstu originaliu teikėjo paketu. Nežinomi įskiepiai, kurių niekas komandoje neįdiegė, visada įtartini, net jei atrodo išjungti.
Tipinės slėptuvės failų sistemoje
Kai kurios vietos kompromituotose WordPress instaliacijose kartojasi nuolat:
wp-content/mu-plugins/: įkeliamas automatiškai ir nerodomas įprastame įskiepių sąraše.wp-content/uploads/: ten turi būti paveikslėliai ir dokumentai, o ne PHP failai.wp-config.php: papildomosincludearrequireeilutės pradžioje arba pabaigoje..htaccessir.user.inižiniatinklio kataloge ir poaplankiuose: netikėti peradresavimai arba automatiškai iš anksto įkeliami failai.- Failai pagrindiniame kataloge, kurių pavadinimai primena WordPress branduolio failus, bet jiems nepriklauso.
# PHP failai įkėlimų aplanke
find wp-content/uploads -type f -name "*.php*"
# Must-Use įskiepių turinys
ls -la wp-content/mu-plugins/
# Visi .htaccess ir .user.ini failai su pakeitimo data
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Neseniai pakeisti PHP failai
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Bendrus užmaskuoto kodo paieškos šablonus aprašo vadovas Webshell aptikimas ir šalinimas.
Naudotojų, duomenų bazės ir suplanuotų užduočių patikra
Daug užpakalinių durų išvis nėra failų sistemoje. Užpuolikams dažnai pakanka papildomos administratoriaus paskyros, kad vėliau sugrįžtų.
# Visi administratoriai su registracijos data
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Geplante Aufgaben in WordPress
wp cron event list
# Svetainės adresas (manipuliacijos sukelia peradresavimus)
wp option get siteurl
wp option get home
# Įrašai su įterptais skriptais
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Patikrinkite ir nustatymus su neįprastai dideliu turiniu bei valdiklius su svetimu kodu. Radiniai automatiškai nereiškia atakos, nes sekimo kodai ar įterpti žemėlapiai taip pat naudoja skriptus. Lemia tai, ar kas nors komandoje to turinio nepažįsta.
Radę užpakalines duris, pakeiskite visus slaptažodžius ir saugumo raktus wp-config.php. Kitaip užpuolikų esami prisijungimai lieka galioti.
Užpakalinių durų uždarymas ir pasikartojimo prevencija
Radus užpakalines duris, perinstaliavimas dažniausiai saugesnis nei atskirų failų taisymas. Pasiteisinusi tokia eilė:
- Išsaugokite pėdsakus: žurnalus, įtartinus failus ir duomenų bazės eksportą su data.
- PHP atnaujinkite iki ištaisytos būsenos ir iš naujo paleiskite visus PHP procesus.
- WordPress branduolį, įskiepius ir temas įdiekite iš naujo iš originalių šaltinių.
- Įkėlimus ir duomenų bazę perimkite patikrintus, svetimas paskyras ištrinkite, pakeiskite visas prieigas.
- PHP vykdymą įkėlimų aplanke uždrauskite serverio lygiu.
Nginx tam pakanka bloko serverio konfigūracijoje:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
Apache serveryje to paties pasieksite taisykle serverio konfigūracijoje įkėlimų aplankui. .htaccess pačiame įkėlimų aplanke yra silpnesnė, nes užpuolikas su rašymo teisėmis gali ją vėl pakeisti.
Po išvalymo numatykite kelias savaites atidesnės stebėsenos. Nauji administratoriai, nauji PHP failai ir wp-config.php pakeitimai šiuo laikotarpiu turėtų būti pastebėti iš karto, pavyzdžiui, reguliaria WP-CLI patikra arba failų stebėsena serveryje.
Kaip po to nustatyti failų teises, kad WordPress galėtų rašyti tik ten, kur būtina, rodo vadovas Failų teisės žiniatinklio serveryje.
Kaip PHP SOS padeda konkrečiai?
- Instaliacijos būseną išsaugome, prieš ką nors keisdami.
- Tikriname branduolį, įskiepius, temas, duomenų bazę, paskyras ir serverio konfigūraciją dėl užpakalinių durų.
- WordPress įdiegiame iš naujo iš švarių šaltinių ir perimame tik patikrintą turinį.
- Sutvirtiname serverį ir instaliaciją bei dokumentuojame, kas rasta ir pašalinta.
Išvalymo eigą aprašo paslauga Kenkėjiškų programų ir webshell šalinimas.
Dažni klausimai
Ar WordPress atnaujinimas uždaro PHP2Shell pažeidžiamumą?
Ne. PHP2Shell glūdi PHP interpretatoriuje, o ne WordPress. WordPress, temų ar įskiepių atnaujinimas to nekeičia; lemia serverio PHP versija ir visų PHP procesų paleidimas iš naujo.
Ar saugumo įskiepis randa visas užpakalines duris?
Nepatikimai. Įskiepis veikia pačioje kompromituotoje instaliacijoje ir pats gali būti pakeistas. Papildykite jį patikromis iš išorės, pavyzdžiui, WP-CLI kontrolinėmis sumomis ir palyginimu su švariais originaliais failais.
Kas yra mu-plugins ir kodėl jie įtartini?
Must-Use įskiepiai aplanke wp-content/mu-plugins įkeliami automatiškai ir nerodomi įprastame įskiepių sąraše. Užpuolikai tuo mielai naudojasi, nes operatoriai šį aplanką peržiūri retai.
Ar užpakalinės durys gali būti ir duomenų bazėje?
Taip. Kenkėjiškas kodas ar peradresavimai dažnai talpinami nustatymuose, įrašuose ar valdikliuose. Be to, užpuolikai dažnai susikuria savo administratoriaus paskyras, kurias rasite naudotojų lentelėje.