Lyhyesti: MediaWikin tietoturva alkaa PHP2Shellin jälkeen palvelimen PHP:stä, sillä aukko on siellä eikä wikissä. Sisäisiin wikeihin ei usein kosketa vuosiin, ja ne toimivat vanhoilla PHP-versioilla. Tarkistakaa tila sivulta Special:Version, korjatkaa ja käynnistäkää uudelleen ja kontrolloikaa sen jälkeen LocalSettings.php, images ja käyttöliittymän ylläpitäjät.
Miksi sisäiset wikit ovat houkutteleva kohde
MediaWiki toimii monissa yrityksissä, viranomaisissa ja tutkimuslaitoksissa sisäisenä käsikirjana. Siellä on toimintatapoja, yhteyshenkilöitä, verkkokaavioita, palvelinten ohjeita ja joskus jopa tunnuksia, jotka eivät sinne kuulu. Hyökkääjälle tällainen wiki on yrityksen kartta.
PHP-tiimin mukaan PHP-haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 sallivat haittakoodin suorittamisen etänä ilman kirjautumista. Wiki, jonka piti olla ”vain sisäinen” mutta joka on tavoitettavissa internetistä, on siten suoraan haavoittuva. Ja koska wikit ovat harvoin IT:n huomion kohteena, ne toimivat usein vanhoilla palvelimilla, usein yhä PHP:llä Apache-moduulina, PHP-tiimin mukaan suurimman riskin ajotavalla.
MediaWikin tietoturva: PHP-version ja korjaustilan tarkistus
Sivu Special:Version näyttää MediaWikin, PHP:n ja tietokannan version sekä kaikki asennetut laajennukset ja skinit. (Sivun nimi toimii suomenkielisessä wikissä myös aliaksella Toiminnot:Versio.) Korjatut upstream-versiot ovat 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Monet wiki-palvelimet toimivat backportteja käyttävillä Linux-jakeluilla; näytetty numero pysyy silloin samana, vaikka korjaus on tehty.
Jos wiki toimii PHP 8.1:llä tai vanhemmalla, PHP-projekti ei enää julkaise virallisia päivityksiä, vain vähäisiä lähdekoodin backporteja versioille 7.4, 8.0 ja 8.1. Mitä silloin pätee, tiivistää sivu PHP 8.1 ja vanhemmat. Mitä PHP-versioita teidän MediaWiki-versionne tukee, tarkistatte järjestelmävaatimuksista osoitteessa mediawiki.org. PHP-vaihto voi edellyttää MediaWiki-päivitystä.
Huoltoskriptit ja job runnerit toimivat komentorivi-PHP:llä. Myös tämän version on oltava korjattu. Jos job-jono toimii pysyvänä palveluna, sen on käynnistyttävä päivityksen jälkeen uudelleen samoin kuin verkkopalvelimen tai PHP-FPM:n. mod_php:n tapauksessa tämä tarkoittaa itse Apachen uudelleenkäynnistystä, sillä PHP on siellä verkkopalvelimen prosessissa.
Selvittäkää lisäksi, kenen wiki on. Sisäiset wikit on usein pystyttänyt jokin osasto, ja ne toimivat tavallisen palvelinylläpidon ulkopuolella. Ilman selvää vastuuta PHP-päivitys jää niissä pisimpään tekemättä.
MediaWikin hakemistot ja tiedostot
| Paikka | Sisältö | Tarkistuskohde |
|---|---|---|
LocalSettings.php |
Tietokantatunnukset, $wgSecretKey, $wgUpgradeKey, oikeudet, latausasetukset |
sisään ujutettu koodi, avaimet uusittava epäilyn jälkeen |
images/ |
ladatut tiedostot ja esikatselukuvat | ei PHP-tiedostoja, ei PHP:n suoritusta |
extensions/, skins/ |
Laajennukset ja ulkoasut | tuntemattomat tai muutetut tiedostot |
cache/ |
Välimuisti | tyhjennettävä puhdistuksen jälkeen |
maintenance/ |
Komentorivin huoltoskriptit | ei käytettäväksi verkon kautta |
Latauskansion ei pitäisi suorittaa skriptejä verkkopalvelimen tasolla. Apachella se onnistuu PHP:n ajotavasta riippumatta näin:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Vaaraton ensitarkistus:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Tarkistakaa sivujen MediaWiki:Common.js ja MediaWiki:Common.css versiohistoria. Muutokset siellä vaikuttavat jokaiseen wikin kävijään, ja ne ovat tyypillinen paikka sisään ujutetulle koodille.
Oikeudet, ryhmät ja laajennukset
MediaWikissä käyttäjäryhmät ratkaisevat tietoturvan. Tarkistakaa sivuilta Special:ListUsers ja Special:UserRights, ketkä kuuluvat ryhmiin ylläpitäjät, byrokraatit ja käyttöliittymän ylläpitäjät (interface-admin). Käyttöliittymän ylläpitäjät voivat muuttaa koko wikin JavaScriptiä; tämän ryhmän pitäisi olla hyvin pieni.
Sisäisessä wikissä lukeminen ilman kirjautumista pitäisi olla kytketty pois ja uusien tilien rekisteröinti estetty. Sallikaa lataukset vain tiedostotyypeille, joita todella tarvitaan. Laajennukset tuovat mukanaan omaa PHP-koodia; ylläpitämättömät laajennukset hidastavat lisäksi jokaista päivitystä. Palvelimen tiedosto-oikeuksiin suuntaa antaa opas Tiedosto-oikeudet verkkopalvelimella.
Mihin MediaWiki-päivitys pystyy ja mihin ei
MediaWiki-päivitys korvaa ytimen ja sulkee sen tunnetut virheet. Se ei korjaa PHP:tä, ei käynnistä PHP-prosesseja uudelleen, ei muuta tiedostoa LocalSettings.php eikä poista tiedostoja hakemistosta images/, muutoksia sivulla MediaWiki:Common.js eikä ylimääräisiä ryhmän jäseniä. Se ei myöskään todista, ettei kukaan ole lukenut mukana ennen korjausta.
Nopean yleiskuvan antavat lisäksi lokit sivulla Special:Log. Uudet käyttäjätilit, ryhmäoikeuksien muutokset ja käyttöliittymäsivujen muokkaukset 17.10.2026 alkaen on merkitty sinne ajankohtineen.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme wiki-palvelimenne PHP-version, ajotavan ja backport-tilan ja varmennamme uudelleenkäynnistyksen.
- Varmuuskopioimme lokit 20.10.2026 alkaen, tietokannan ja tiedostot.
- Tarkistamme
LocalSettings.php:n, lataukset, laajennukset, ryhmäoikeudet ja käyttöliittymäsivujen versiohistorian. - PHP2Shell-pikaavun puitteissa arvioimme kanssanne, onko wikin pysyttävä julkisesti tavoitettavana.
Usein kysytyt kysymykset
Koskeeko PHP2Shell MediaWikiä?
MediaWikissä itsessään ei ole uutta aukkoa, mutta se toimii PHP:llä. Jos palvelimen PHP ei ole korjattu, hyökkääjä voi PHP-tiimin mukaan suorittaa koodia ilman kirjautumista. MediaWiki-päivitys ei sulje aukkoa.
Mistä näen wikini PHP-version?
Sivulla Special:Version MediaWiki luettelee asennetut ohjelmistot, myös PHP-version. Onko backport asennettu, ei näy siitä; sen vahvistaa palvelimen ylläpitäjä.
Miksi MediaWiki:Common.js on riski?
Tämän sivun sisältö toimitetaan JavaScriptinä kaikille wikin kävijöille. Se, joka voi muuttaa sitä, voi suorittaa koodia jokaisen käyttäjän selaimessa. Siksi käyttöliittymän ylläpitäjien ryhmän pitäisi olla hyvin pieni.
Riittääkö, että wiki tehdään vain sisäisesti tavoitettavaksi?
Wiki vain yrityksen verkossa tai VPN:n kautta pienentää riskiä selvästi, koska hyökkääjät internetistä eivät tavoita sitä suoraan. Korjaus on silti tehtävä, sillä hyökkäys voi tulla myös sisäverkosta.