WordPress PHP ievainojamība PHP2Shell: kas jādara vietnes īpašniekam

Īsi: WordPress PHP ievainojamība, par kuru šobrīd ziņo, nav WordPress, bet PHP serverī zem tā. Tāpēc WordPress atjauninājums PHP2Shell neaizver. Izšķirošs ir PHP ielāpa stāvoklis, visu PHP procesu pārstartēšana un tipisku slēptuvju, piemēram, wp-content/uploads un mu-plugins, pārbaude.

Kāpēc WordPress atjauninājums PHP2Shell nelabo

WordPress ir lietojumprogramma, kas uzrakstīta PHP. Ievainojamības CVE-2026-109618 un CVE-2026-109619 atrodas vienu līmeni zemāk, pašā PHP interpretatorā. Saskaņā ar PHP komandu tās ļauj izpildīt ļaunprātīgu kodu no attāluma bez pieteikšanās. Ar Apache un mod_php exploit tika demonstrēts, vēl pirms tiek izpildīts jebkāds WordPress kods.

Vietne ar aktuālu kodolu, aktuāliem spraudņiem un stiprām parolēm tāpēc tomēr var būt ievainojama, ja zem tās esošais PHP ir vecs. Savukārt ielāpots PHP nepierāda, ka iepriekš nekas nav noticis. Fonu skaidrojam rakstā Kas ir PHP2Shell?.

WordPress PHP ievainojamība: PHP versijas pārbaude

Informācijas panelī sadaļā Rīki > Vietnes veselība > Informācija blokā „Serveris” ir redzama PHP versija, ar kuru jūsu vietne patiešām darbojas. Tas ir ticamāk nekā php -v komandrindā, jo komandrinda bieži izmanto citu PHP instalāciju nekā tīmekļa serveris.

Ar redzamo numuru tomēr nepietiek. Labotās upstream versijas ir 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Tomēr daudzi hostinga sniedzēji labojumus ievieš kā backport; tad joprojām redzams vecāks numurs, lai gan ielāps ir uzlikts. Kā noskaidrot patieso stāvokli, lasiet rakstā PHP versijas un ielāpa stāvokļa pareiza pārbaude. Kuras PHP versijas atbalsta jūsu WordPress versija, pārbaudiet pēc sistēmas prasībām vietnē wordpress.org.

Kur ļaunprātīgs kods WordPress mēdz slēpties

Pēc veiksmīga uzbrukuma uzbrucēji parasti atstāj slēptu ieeju, lai varētu atgriezties arī pēc ielāpa. WordPress tam ir zināmas vietas:

• wp-content/uploads/: paredzēta attēliem un PDF failiem, nevis PHP failiem.
• wp-content/mu-plugins/: „Must-use” spraudņi ielādējas automātiski, un informācijas panelī tos nevar deaktivizēt.
• wp-config.php: satur datubāzes piekļuvi un drošības atslēgas; ievietota rinda šeit gandrīz nav pamanāma.
• .htaccess galvenajā direktorijā un apakšmapēs: novirzīšana tikai meklētājprogrammām vai neparastu failu paplašinājumu izpilde.
• Tēmas, īpaši functions.php, kā arī deaktivizēti, aizmirsti spraudņi.
• Datubāze: jauni administratori tabulā wp_users, svešs JavaScript tabulā wp_options vai ierakstos.

Droši pirmie pārbaudes soļi ar WP-CLI un sistēmas līdzekļiem:

# Salīdzināt core failus ar oficiālajām kontrolsummām
wp core verify-checksums
# Pārbaudīt spraudņus no wordpress.org direktorijas
wp plugin verify-checksums --all
# Uzskaitīt PHP failus augšupielāžu mapē
find wp-content/uploads -type f -name "*.php"
# Alle Administratoren anzeigen
wp user list --role=administrator

Atrasts fails ir iemesls rūpīgai izmeklēšanai, bet vēl nav pierādījums. Komerciālos spraudņus šādi pārbaudīt nevar. Plašāk par to lasiet pamācībā Slēpto ieeju (backdoor) atrašana WordPress.

Spraudņi, tēmas un administratoru piekļuves kā papildu risks

PHP2Shell neprasa ievainojamību spraudnī. Ikdienā spraudņi un tēmas tomēr paliek biežākā ieejas vieta WordPress vietnēs. Katrs spraudnis atnes savu kodu, savas augšupielādes funkcijas un savus atjaunināšanas ciklus. Neizmantotos spraudņus labāk dzēst, nevis tikai deaktivizēt, jo deaktivizēti faili turpina atrasties serverī.

Attiecībā uz wp-login.php un wp-admin ieteicams: maz administratoru, personiski konti, nevis kopīgas piekļuves, un divfaktoru autentifikācija. Ja XML-RPC nav vajadzīgs, to var bloķēt. Aizdomu gadījumā jāmaina visas paroles un drošības atslēgas failā wp-config.php. Failu redaktoru informācijas panelī izslēdz tur pat:

define( 'DISALLOW_FILE_EDIT', true );

Ko WordPress vietnes īpašniekam tagad vajadzētu darīt

1. Palūgt hostinga sniedzējam rakstiski apstiprināt PHP ielāpa stāvokli un visu PHP procesu pārstartēšanu.
2. Likt saglabāt servera žurnālus (logs) no 20.10.2026.
3. Veikt iepriekš minētās pārbaudes vai likt tās veikt.
4. Atjaunināt WordPress, spraudņus un tēmas. Tas ir pareizi, bet neaizstāj 1. soli.
5. Neatbilstību gadījumā vietni vienkārši nedarbināt tālāk, bet likt to attīrīt.

Platformas atjauninājums var aizvērt zināmas ievainojamības WordPress un spraudņos. Tas nevar salabot PHP un nevar noņemt ievadītus failus, kas nav kodola sastāvdaļa.

Kā PHP SOS palīdz konkrēti?

• Mēs kopā ar jums vai jūsu hostinga sniedzēju noskaidrojam jūsu WordPress vietnes faktisko PHP stāvokli, ieskaitot backport un pārstartēšanu.
• Mēs saglabājam žurnālus, failus un datubāzi, pirms kaut kas tiek mainīts.
• Mēs pārbaudām kodolu, spraudņus, uploads, mu-plugins, .htaccess un lietotāju kontus uz slēptām ieejām.
• Atrasto gadījumā ļaunprātīgas programmatūras noņemšana veic attīrīšanu, līdz incidents ir slēgts un dokumentēts; ja nekas netiek atrasts, mēs nostiprinām instalāciju PHP2Shell tūlītējās palīdzības ietvaros.

Biežāk uzdotie jautājumi

Avoti

• php.net: drošības paziņojumi
• PHP 8 ChangeLog
• WordPress.org
• BSI (Vācijas Federālais informācijas drošības birojs)