Ranljivost PHP v WordPressu, PHP2Shell: kaj morajo storiti upravljavci

Na kratko: Ranljivost PHP v WordPressu, o kateri se zdaj poroča, ni v WordPressu, ampak v PHP na strežniku pod njim. Posodobitev WordPressa zato PHP2Shell ne odpravi. Odločilni so stanje popravkov PHP, ponovni zagon vseh procesov PHP in pregled tipičnih skrivališč, kot sta wp-content/uploads in mu-plugins.

Zakaj posodobitev WordPressa PHP2Shell ne odpravi

WordPress je aplikacija, napisana v PHP. Ranljivosti CVE-2026-109618 in CVE-2026-109619 ležita eno raven globlje, v samem interpreterju PHP. Po navedbah ekipe PHP omogočata izvajanje škodljive kode na daljavo brez prijave. Pri Apacheu z mod_php je bil exploit prikazan, še preden se sploh izvede koda WordPressa.

Spletna stran z aktualnim jedrom, aktualnimi vtičniki in močnimi gesli je zato kljub temu lahko ranljiva, če je PHP pod njo star. Obratno pa popravljen PHP ne dokazuje, da prej ni bilo nič narobe. Ozadje pojasnjujemo v prispevku Kaj je PHP2Shell?.

Ranljivost PHP v WordPressu: preverite različico PHP

V nadzorni plošči pod Orodja > Zdravje strani > Poročilo v razdelku »Strežnik« najdete različico PHP, s katero vaša spletna stran dejansko teče. To je zanesljivejše od php -v v ukazni vrstici, saj ukazna vrstica pogosto uporablja drugo namestitev PHP kot spletni strežnik.

Prikazana številka sama vseeno ne zadošča. Odpravljene različice izvorne kode so 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Številni ponudniki gostovanja pa popravke vgradijo kot backport; takrat ostane starejša številka, čeprav je popravljeno. Kako ugotovite pravo stanje, je opisano v prispevku Pravilno preverjanje različice PHP in stanja popravkov. Katere različice PHP podpira vaša različica WordPressa, preverite v sistemskih zahtevah na wordpress.org.

Kje se škodljiva koda rada skriva v WordPressu

Po uspešnem napadu napadalci praviloma odložijo stranska vrata, da se lahko vrnejo tudi po popravku. WordPress ima za to znana mesta:

• wp-content/uploads/: namenjena slikam in datotekam PDF, ne datotekam PHP.
• wp-content/mu-plugins/: vtičniki »Must-use« se naložijo samodejno in jih v nadzorni plošči ni mogoče deaktivirati.
• wp-config.php: vsebuje dostop do podatkovne zbirke in varnostne ključe; vstavljena vrstica tu komaj pade v oči.
• .htaccess v glavni mapi in podmapah: preusmeritve samo za iskalnike ali izvajanje nenavadnih končnic datotek.
• Teme, predvsem functions.php, ter deaktivirani, pozabljeni vtičniki.
• Podatkovna zbirka: novi skrbniki v wp_users, tuj JavaScript v wp_options ali v prispevkih.

Neškodljivi prvi pregledi z WP-CLI in vgrajenimi orodji:

# Datoteke jedra primerjaj z uradnimi kontrolnimi vsotami
wp core verify-checksums
# Preveri vtičnike iz imenika na wordpress.org
wp plugin verify-checksums --all
# Izpiši datoteke PHP v mapi za nalaganje
find wp-content/uploads -type f -name "*.php"
# Prikaži vse skrbnike
wp user list --role=administrator

Zadetek je razlog za natančno preiskavo, še ne dokaz. Komercialnih vtičnikov na ta način ni mogoče preveriti. Podrobneje se nadaljuje v vodniku Iskanje stranskih vrat v WordPressu.

Vtičniki, teme in skrbniški dostopi kot dodatno tveganje

PHP2Shell ne potrebuje ranljivosti v vtičniku. V vsakdanjem življenju pa vtičniki in teme ostajajo najpogostejša vstopna točka v spletne strani WordPress. Vsak vtičnik prinese lastno kodo, lastne funkcije nalaganja in lastne cikle posodobitev. Vtičnike, ki jih ne uporabljate, izbrišite, ne le deaktivirajte, saj deaktivirane datoteke ostanejo na strežniku.

Za wp-login.php in wp-admin velja: malo skrbnikov, osebni računi namesto skupnih dostopov in dvofaktorska prijava. Če XML-RPC ne potrebujete, ga je mogoče blokirati. Ob sumu je treba obnoviti vsa gesla in varnostne ključe v wp-config.php. Urejevalnik datotek v nadzorni plošči izklopite prav tako tam:

define( 'DISALLOW_FILE_EDIT', true );

Kaj naj kot upravljavec WordPressa zdaj storite

1. Pri ponudniku gostovanja si pisno potrdite stanje popravkov PHP in ponovni zagon vseh procesov PHP.
2. Poskrbite za hrambo dnevnikov strežnika od 20. 10. 2026.
3. Izvedite zgornje preglede ali jih dajte izvesti.
4. Posodobite WordPress, vtičnike in teme. To je prav, vendar ni nadomestilo za 1. korak.
5. Ob nepravilnostih spletne strani ne uporabljajte kar naprej, ampak jo dajte očistiti.

Posodobitev platforme lahko zapre znane ranljivosti v WordPressu in vtičnikih. Ne more pa popraviti PHP in ne odstraniti vnesenih datotek, ki ne spadajo v jedro.

Kako PHP SOS pomaga konkretno?

• Z vami ali vašim ponudnikom gostovanja razjasnimo dejansko stanje PHP vaše spletne strani WordPress, vključno z backporti in ponovnim zagonom.
• Dnevnike, datoteke in podatkovno zbirko zavarujemo, preden se karkoli spremeni.
• Jedro, vtičnike, nalaganja, mu-plugins, .htaccess in uporabniške račune pregledamo glede stranskih vrat.
• Ob najdbah čiščenje do zaključka in dokumentiranja incidenta prevzame naše odstranjevanje škodljive programske opreme; brez najdb namestitev utrdimo v okviru nujne pomoči PHP2Shell.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• PHP 8 ChangeLog
• WordPress.org
• BSI (nemški zvezni urad za informacijsko varnost)