WordPressin PHP-haavoittuvuus PHP2Shell: mitä ylläpitäjän on tehtävä

Lyhyesti: WordPressin PHP-haavoittuvuus, josta nyt raportoidaan, ei ole WordPressissä vaan sen alla olevassa palvelimen PHP:ssä. WordPress-päivitys ei siksi sulje PHP2Shelliä. Ratkaisevia ovat PHP:n korjaustila, kaikkien PHP-prosessien uudelleenkäynnistys ja tyypillisten piilopaikkojen, kuten wp-content/uploads ja mu-plugins, tarkistus.

Miksi WordPress-päivitys ei korjaa PHP2Shelliä

WordPress on PHP:llä kirjoitettu sovellus. Haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 ovat yhtä tasoa alempana, itse PHP-tulkissa. PHP-tiimin mukaan ne sallivat haittakoodin suorittamisen etänä ilman kirjautumista. Apachella ja mod_php:llä on esitetty hyökkäys ennen kuin WordPress-koodia ajetaan lainkaan.

Verkkosivusto, jonka ydin, liitännäiset ja salasanat ovat kunnossa, voi siis silti olla haavoittuva, jos sen alla oleva PHP on vanha. Toisaalta korjattu PHP ei todista, ettei mitään ole ehtinyt tapahtua aiemmin. Taustat selitämme sivulla Mikä PHP2Shell on?.

WordPressin PHP-haavoittuvuus: PHP-version tarkistus

Hallintapaneelin kohdassa Työkalut > Sivuston kunto > Tiedot on osio ”Palvelin”, josta näkyy PHP-versio, jolla sivustonne todella toimii. Se on luotettavampi tieto kuin komentorivin php -v, koska komentorivi käyttää usein eri PHP-asennusta kuin verkkopalvelin.

Näytetty numero ei silti yksin riitä. Korjatut upstream-versiot ovat 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Monet hosting-yritykset tuovat korjaukset kuitenkin backporttina; silloin näkyy yhä vanhempi numero, vaikka korjaus on tehty. Todellisen tilan selvittämisen ohjeet löytyvät sivulta PHP-version ja korjaustilan tarkistaminen oikein. Mitä PHP-versioita teidän WordPress-versionne tukee, tarkistatte wordpress.orgin järjestelmävaatimuksista.

Mihin haittakoodi WordPressissä mielellään piiloutuu

Onnistuneen hyökkäyksen jälkeen tekijät jättävät yleensä takaoven, jotta pääsevät takaisin korjauksen jälkeenkin. WordPressissä siihen on tunnettuja paikkoja:

• wp-content/uploads/: tarkoitettu kuville ja PDF-tiedostoille, ei PHP-tiedostoille.
• wp-content/mu-plugins/: ”Must-use”-liitännäiset latautuvat automaattisesti, eikä niitä voi poistaa käytöstä hallintapaneelista.
• wp-config.php: sisältää tietokantatunnukset ja turva-avaimet; yksi lisätty rivi jää tässä tuskin huomaamatta.
• .htaccess pääkansiossa ja alikansioissa: uudelleenohjaukset vain hakukoneille tai epätavallisten tiedostopäätteiden suorittaminen.
• Teemat, erityisesti functions.php, sekä käytöstä poistetut, unohtuneet liitännäiset.
• Tietokanta: uudet ylläpitäjät taulussa wp_users, vieras JavaScript taulussa wp_options tai artikkeleissa.

Vaarattomat ensitarkistukset WP-CLI:llä ja järjestelmän omilla työkaluilla:

# Verrataan ydintiedostoja virallisiin tarkistussummiin
wp core verify-checksums
# Tarkistetaan wordpress.orgin hakemistosta ladatut liitännäiset
wp plugin verify-checksums --all
# Listataan PHP-tiedostot uploads-kansiosta
find wp-content/uploads -type f -name "*.php"
# Näytetään kaikki ylläpitäjät
wp user list --role=administrator

Löydös on aihe tarkempaan tutkimukseen, ei vielä todiste. Kaupallisia liitännäisiä ei voi näin tarkistaa. Yksityiskohtaisemmin asiaa käsittelee opas Takaovien löytäminen WordPressistä.

Liitännäiset, teemat ja ylläpitäjien tunnukset lisäriskinä

PHP2Shell ei tarvitse liitännäisen haavoittuvuutta. Arjessa liitännäiset ja teemat ovat silti yleisin sisäänpääsyreitti WordPress-sivustoihin. Jokainen liitännäinen tuo mukanaan omaa koodia, omia latausominaisuuksia ja omat päivityssyklinsä. Käyttämättömät liitännäiset kannattaa poistaa eikä vain poistaa käytöstä, sillä käytöstä poistetut tiedostot ovat edelleen palvelimella.

Tiedostoille wp-login.php ja wp-admin pätee: vähän ylläpitäjiä, henkilökohtaiset tunnukset jaettujen sijaan ja kaksivaiheinen tunnistautuminen. Jos ette tarvitse XML-RPC:tä, sen voi estää. Epäilyn jälkeen kaikki salasanat ja wp-config.php:n turva-avaimet pitää uusia. Hallintapaneelin tiedostoeditorin voi poistaa käytöstä samassa tiedostossa:

define( 'DISALLOW_FILE_EDIT', true );

Mitä WordPressin ylläpitäjän kannattaa nyt tehdä

1. Pyytäkää palveluntarjoajalta kirjallinen vahvistus PHP:n korjaustilasta ja kaikkien PHP-prosessien uudelleenkäynnistyksestä.
2. Pyytäkää säilyttämään palvelimen lokit 20.10.2026 alkaen.
3. Tehkää yllä olevat tarkistukset tai teettäkää ne.
4. Päivittäkää WordPress, liitännäiset ja teemat. Se on oikein, mutta ei korvaa vaihetta 1.
5. Jos löytyy poikkeamia, sivustoa ei kannata vain pitää käynnissä sellaisenaan, vaan se on puhdistettava.

Alustapäivitys voi sulkea WordPressin ja liitännäisten tunnettuja aukkoja. Se ei voi korjata PHP:tä eikä poistaa sisään ujutettuja tiedostoja, jotka eivät kuulu ytimeen.

Miten PHP SOS auttaa konkreettisesti?

• Selvitämme teidän tai palveluntarjoajanne kanssa WordPress-sivustonne todellisen PHP-tilan, backportit ja uudelleenkäynnistys mukaan lukien.
• Varmuuskopioimme lokit, tiedostot ja tietokannan ennen kuin mitään muutetaan.
• Tarkistamme ytimen, liitännäiset, uploads-kansion, mu-pluginsit, .htaccess-tiedoston ja käyttäjätilit takaovien varalta.
• Löydösten yhteydessä haittaohjelman poisto hoitaa puhdistuksen, kunnes tapaus on päätetty ja dokumentoitu; jos löydöksiä ei ole, koventamme asennuksen PHP2Shell-pikaavun puitteissa.

Usein kysytyt kysymykset

Lähteet

• php.net: tietoturvatiedotteet
• PHP 8 ChangeLog
• WordPress.org
• BSI (Saksan liittovaltion tietoturvavirasto)