PHP-haavoittuvuudet sulkivat suomalaispalveluja – korjaukset valmistuivat

Traficomin 23. lokakuuta 2026 julkaisema tilannekatsaus kertoo, että kriittiset PHP-haavoittuvuudet johtivat Suomessa varotoimisiin verkkopalvelukatkoihin, vaikka onnistunutta hyväksikäyttöä ei ollut havaittu; viraston tietoturva-asiantuntija Roni Kokkola kehotti päivittämään PHP:tä käyttävät järjestelmät ”mahdollisimman nopeasti”. Sulkeminen esti verkkopyyntöjen pääsyn pois käytöstä otettuihin palveluihin päivityksen ajaksi.

CSC:n 23. lokakuuta julkaisema päivitys kertoo, että lähes kaikki sen varotoimena sulkemat palvelut olivat jälleen käytettävissä ja palvelualustan tunnetut haavoittuvuudet oli korjattu. Viimeisenkin palvelun odotettiin avautuvan perjantain aikana, eikä suljetuissa palveluissa ollut havaittu tietomurtoon viittaavia merkkejä. Katkojen syynä ollut palvelinohjelmiston päivitys kuuluu palvelujen ylläpitäjille, ei niiden käyttäjille.

Korjaukset koskevat verkkopyyntöjä käsittelevää PHP:tä

PHP-projektin 21. lokakuuta julkaisema tietoturvatiedote nimeää haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 ja ilmoittaa korjaaviksi versioiksi PHP 8.5.12:n, 8.4.27:n, 8.3.36:n ja 8.2.35:n. Molemmat voivat mahdollistaa koodin suorittamisen palvelimella etäältä ilman kirjautumista. Luettelon versiot ovat eri PHP-julkaisusarjojen korjauksia, joten palvelimen ylläpitäjä valitsee käytössä olevaan sarjaan kuuluvan päivityksen.

Ensimmäisessä virheessä PHP:n muistin loppumiseen liittyvä häiriö voi keskeyttää verkkopyynnön käsittelyn, kun sisäiset tiedot ovat vielä keskeneräisiä. Seurauksena myöhempi siivous voi käsitellä virheellistä tilaa kelvollisena. Toisessa virheessä aiempaan pyyntöön kuulunutta sisäistä tilaa voi jäädä palvelinprosessiin sen jälkeen, kun tilan käyttämä muisti on vapautettu. Saman prosessin seuraava pyyntö voi silloin käyttää vanhentunutta tietoa ennen kuin normaali alustus ehtii korvata sen.

Riski koskee verkkopyyntöjä palvelevia PHP-asennuksia, esimerkiksi PHP-FPM:ää, Apachen mod_php-moduulia, php-cgi:tä, FrankenPHP:tä ja LiteSpeediä. Vakavin osoitettu riski liittyy mod_php-ympäristöön, jossa hyökkäystapa voi käynnistyä jo ennen verkkosovelluksen oman koodin suorittamista. Siksi pelkkä sovelluksen sisältöön tehty muutos ei poista palvelinohjelmiston virhettä. Korjauksen on oltava käytössä siinä PHP-ympäristössä, joka todella vastaanottaa ja käsittelee kävijöiden pyynnöt.

Kyse on palvelinpuolen virheistä. Käyttäjän selain saa verkkopalvelusta valmiin vastauksen, mutta PHP suorittaa taustalla pyyntöön liittyvää koodia ja käsittelee sen sisäistä tilaa. Siksi käyttäjän oman laitteen päivittäminen ei muuta palvelimen altistumista. Erityisesti vanhentuneen sisäisen tilan virhe liittyy siihen, että sama palvelinprosessi voi palvella peräkkäisiä pyyntöjä: ongelman paikka on yhteisessä käsittely-ympäristössä eikä yksittäisen kävijän istunnossa.

Miksi suomalaisia verkkopalveluja suljettiin?

Palvelun tilapäinen sulkeminen vähensi mahdollisuutta lähettää haavoittuvalle järjestelmälle verkkopyyntöjä ennen korjauksen käyttöönottoa. Se oli varotoimi tilanteessa, jossa virheiden vaikutus voi olla vakava ja verkkopalvelut ovat tavoitettavissa internetistä. Korjaavat ohjelmistoversiot tulivat saataville vasta sen jälkeen, kun viranomaiset olivat jo varoittaneet haavoittuvuuksista. Palvelukatko oli siis osa suojaamista, ei sellaisenaan merkki onnistuneesta hyökkäyksestä.

Varoituksen ja korjauksen välinen aika jätti ylläpitäjille vaikean käytännön valinnan. Avoimeen, mahdollisesti haavoittuvaan palveluun voi edelleen lähettää pyyntöjä, mutta suljettu palvelu ei palvele myöskään tavallisia asiakkaita. Kun ohjelmistokorjaus tuli saataville, palveluja voitiin palauttaa eri tahtiin sen mukaan, miten päivitys saatiin käyttöön kussakin ympäristössä. Kansallinen tieto siitä, ettei onnistunutta hyväksikäyttöä ollut havaittu, ei poistanut tarvetta korjata altista palvelinohjelmistoa.

Palvelun sulkeminen ja palauttaminen tapahtuivat palveluntarjoajittain. CSC:n suljettujen palvelujen palauduttua lähes kokonaan muiden organisaatioiden verkkopalvelut saattoivat silti olla eri vaiheessa päivitystä. Yksittäisen palvelun saatavuus määräytyy sen oman ylläpitäjän tekemän palautuksen perusteella. Yhden toimijan palvelujen avautumisesta ei voi päätellä, onko toisen verkkopalvelu jo käytettävissä.

Tietomurtoa koskevissa tiedoissa on kaksi eri tasoa: suljetuissa CSC-palveluissa ei ollut havaittu murtoon viittaavia merkkejä, ja valtakunnallisesti onnistunutta haavoittuvuuksien hyväksikäyttöä ei ollut havaittu. Ensimmäinen havainto koskee yhden palveluntarjoajan ympäristöä, jälkimmäinen Suomen siihenastista tilannekuvaa. Kumpikaan ei poista korjaamattoman verkkopalvelun riskiä eikä osoita, että kaikkien muiden organisaatioiden järjestelmien tila olisi samanlainen.

Päivitys kuuluu ylläpitäjälle, katko näkyy käyttäjälle

Ylläpitäjän keskeinen tehtävä on selvittää palvelun käyttämä PHP-versio ja asentaa siihen kuuluva tietoturvakorjaus. Linux-jakelun tai pitkäaikaistuen toimittajan paketti voi sisältää korjauksen myös silloin, kun näkyvä versionumero poikkeaa PHP-projektin uusista julkaisuista. Vanhoille, projektin tavallisen tuen ulkopuolisille julkaisusarjoille toimittajan korjaukset tai siirtyminen tuettuun sarjaan ovat olennaisia. Ratkaisevaa on itse korjauksen mukanaolo käytössä olevassa paketissa, ei pelkkä versionumeron ulkoasu.

Jos päivitystä ei voi asentaa heti, palvelun pääsyn rajoittaminen ja tiettyjen asetusten muuttaminen voivat pienentää altistusta rajatuissa hyökkäystavoissa. Tällaiset toimet eivät kuitenkaan kata kaikkia mahdollisia hyökkäysreittejä, joten ne eivät korvaa korjaavaa päivitystä. Palvelu kannattaa avata vasta, kun korjattu ohjelmisto on otettu käyttöön ja palvelun toiminta on varmistettu. Tämä selittää, miksi saatavilla oleva korjausversio ei automaattisesti tarkoita katkon välitöntä päättymistä kaikissa ympäristöissä.

Korjauksen asentamisen ja palvelun avaamisen välissä on vielä käytännön ero. Uusi paketti voi olla ladattu ylläpidon saataville, vaikka käynnissä oleva palvelinprosessi käyttäisi edelleen aiempaa versiota. Päivityksen jälkeen ylläpitäjä varmistaa, että oikea ympäristö käyttää korjattua koodia ja että verkkopalvelu vastaa normaalisti. Siksi ulospäin näkyvän katkon kesto ei kerro suoraan, kuinka nopeasti korjaustiedosto julkaistiin tai ladattiin.

Tavallinen käyttäjä ei voi päivittää palvelimen PHP:tä selaimessaan tai puhelimessaan. Pelkkä palvelukatko ei myöskään osoita, että käyttäjätunnus, salasana tai palveluun tallennetut tiedot olisivat vaarantuneet. Jos palvelu on edelleen poissa käytöstä, käyttäjän kannalta ratkaisevaa on kyseisen palvelun oma ilmoitus palautumisesta ja mahdollisista käyttäjiä koskevista toimista. CSC:n ilmoitushetkellä viimeisen suljetun palvelun palautuminen oli vielä kesken, joten juuri sen palvelukohtainen saatavuus jäi seuraavaksi käytännön kysymykseksi.

Lue myös:

• Kiteworks sammutti palvelut varoituksesta – haavoittuvuus löytyi
• Tesseract antaa agentin leikata videon – ensimmäinen versio vaati korjauksia
• Calendly vai Microsoft Bookings? Valmis 365-tilaus muuttaa hinnan