# PHP2Shell viidessä minuutissa: tiivistelmä johdolle

> PHP2Shell viidessä minuutissa: tilanne, liiketoimintariski, viisi kysymystä IT:llenne ja päätökset, jotka johdon kannattaa tehdä tänään.

Lähde: https://phpsos.de/fi/blog/php2shell-briefing-geschaeftsfuehrung/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** PHP-tietoturva-aukko PHP2Shell koostuu kahdesta kriittisestä virheestä PHP:ssä, joka on useimpien verkkosivustojen ja verkkokauppojen perusta. Hyökkääjät voivat sen kautta suorittaa haittakoodia verkkopalvelimilla ilman salasanaa. BSI (Saksan liittovaltion tietoturvavirasto) varoittaa oranssilla tasolla ja neuvoo: päivittäkää heti, muuten ottakaa alttiit palvelimet väliaikaisesti pois verkosta. Johdolle se tarkoittaa tänään: selvittäkää vastuu, vaatikaa päivitys ja todiste, päättäkää sulkemisesta ja dokumentoikaa kaikki.

## Tilanne kolmessa lauseessa

PHP-projekti julkaisi 21. lokakuuta 2026 päivitykset kahteen kriittiseen tietoturva-aukkoon, jotka tunnetaan nimellä PHP2Shell. Koskee PHP:tä itseään, ei tiettyä tuotetta, eli mahdollisesti jokaista verkkosivustoa, verkkokauppaa ja portaalia, joka toimii PHP:llä. BSI on julistanut varoitustason 3 / oranssi, tietoturvayritykset raportoivat hyökkäysyrityksistä, ja vahvistettuja onnistuneita hyökkäyksiä laajasti ei BSI:n mukaan aluksi ollut tiedossa.

Viranomaiset, kuten BKA (Saksan liittovaltion rikospoliisi) ja useat kaupungit, ovat mediaraporttien mukaan sulkeneet verkkosivustojaan varotoimena. Se oli varovaisuutta, ei merkki hyökkäyksestä.

## Mitä PHP-tietoturva-aukko tarkoittaa johdolle ja yritykselle

Kysymys ei ole siitä, käytättekö PHP:tä. Lähes jokainen yritys käyttää sitä jossakin: verkkosivusto, verkkokauppa, rekrytointiportaali, asiakasalue, intranet, tikettijärjestelmä, toimiston mikrosivusto. Kysymys on siitä, ovatko nämä järjestelmät ajan tasalla ja kuka niistä vastaa.

Jos hyökkäys onnistuu, hyökkääjä voi pahimmassa tapauksessa ottaa palvelimen haltuunsa. Mahdollisia seurauksia ovat tietovuoto, manipuloitu sisältö, uudelleenohjaukset petossivuille, verkkokaupan seisokki tai palvelimen väärinkäyttö uusiin hyökkäyksiin. Jos henkilötietoja voi olla mukana, tulevat ilmoitusvelvollisuudet; GDPR:n 33 artiklan määräaika on yleensä 72 tuntia. Yksityiskohdat löytyvät kohdasta [GDPR-ilmoitusvelvollisuus](https://phpsos.de/fi/compliance/dsgvo-meldepflicht-72-stunden/). Tämä ei ole oikeudellista neuvontaa.

Mitä kustannuksia hätätilanteessa tyypillisesti syntyy, arvioi artikkeli [Murron kustannuserät](https://phpsos.de/fi/blog/kostenposten-eines-hacks/).

### Missä PHP jää yrityksissä usein huomaamatta

Pääverkkosivuston useimmat pitävät silmällä. Pikemminkin huomaamatta jäävät reunajärjestelmät: ulkoisen toimittajan rekrytointiportaali, aiemman kampanjan laskeutumissivu, jälleenmyyjien kumppanialue, tuen tikettijärjestelmä, oman palvelimen tiedostopilvi tai verkkolevyn verkkokäyttöliittymä. Myös toimistojen testijärjestelmät ovat usein julkisesti tavoitettavissa ja toimivat samalla palvelimella kuin oikea verkkosivusto.

Johdolle opetus on yksinkertainen: kysymys IT:lle ei ole ”Onko verkkosivustomme päivitetty?” vaan ”Onko kaikki PHP:tä käyttävät järjestelmämme päivitetty, myös palveluntarjoajien?”. Ero näiden kahden kysymyksen välillä on usein juuri se kohta, jossa hyökkäys onnistuu.

### Mitä tilanne ei ole

Yhtä tärkeää on arvio alaspäin. PHP2Shell ei ole syy hätiköintiin, joka häiritsee toimintaa enemmän kuin tarpeen. Joka on päivittänyt todistettavasti, käynnistänyt kaikki PHP-prosessit uudelleen eikä löydä tarkistuksessa poikkeavaa, voi palata normaaliin toimintaan. Väliaikainen sulkeminen on vaihtoehto selvittämättömissä tapauksissa, ei velvoite kaikille.

## Viisi kysymystä IT:llenne tai palveluntarjoajalle

Nämä kysymykset voitte esittää tänään. Vastausten tulee tulla kirjallisina.

1. **Mitkä järjestelmistämme toimivat PHP:llä?** Lista osoitteineen, käyttötarkoituksineen ja ylläpitäjineen.
2. **Onko jokainen järjestelmä päivitetty?** Korjattu versio 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai palveluntarjoajan vahvistama backport.
3. **Onko kaikki PHP-prosessit käynnistetty uudelleen?** Ilman uudelleenkäynnistystä päivitys ei vaikuta.
4. **Entä järjestelmät, joissa on PHP 8.1 tai vanhempi?** Niille ei ole virallisia päivityksiä. Mikä on suunnitelma?
5. **Onko tarkistettu, onko ennen päivitystä tapahtunut jotain?** Lokit tallennettu 20. lokakuuta alkaen, jälkiä etsitty?

Jos verkkosivustonne on hosting-yrityksellä, muodollinen pyyntö auttaa. Mallin tarjoaa opas [Hosting-yrityksen PHP-päivitysvahvistuksen pyytäminen](https://phpsos.de/fi/ratgeber/hoster-patch-status-erfragen/).

## Päätökset, jotka tulisi tehdä tänään

| Päätös | Vaihtoehdot | Perusta |
|---|---|---|
| Kuka johtaa? | yksi vastuuhenkilö sisäisesti, ulkoinen kumppani | vastuun on oltava yksiselitteinen |
| Päivittämättömät järjestelmät | päivitys heti, väliaikaistoimet, väliaikainen sulkeminen | BSI:n suositus, tietotilanne, liikevaihtovaikutus |
| Jälkien tarkistus | sisäisesti, ulkoisesti, vain poikkeamien yhteydessä | palvelimen tietojen suojaustarve |
| Viestintä | tiedotus sisäisesti, asiakkaiden valmistelu, odotus | tilanne tarkistuksen jälkeen |
| Vanhat järjestelmät | migraation suunnittelu, eristäminen, sulkeminen | PHP 8.1 ja vanhemmat ilman virallisia päivityksiä |

> **Tärkeää:**
> Kirjatkaa ylös, kuka päätti mitä ja milloin ja millä tietopohjalla. Lyhyt, päivätty muistiinpano riittää. Se on jälkikäteen vakuuttajia, asiakkaita tai valvontaviranomaisia kohtaan usein arvokkaampi kuin mikään jälkeenpäin annettu selitys.

Miksi tämä dokumentointi on johdolle tärkeää, selittää sivu [Johdon vastuu IT-tietoturva-aukoista](https://phpsos.de/fi/compliance/geschaeftsfuehrer-haftung/). Tämä on yleistä tietoa eikä oikeudellista neuvontaa.

## Mitä ette saa uskoa

Kolme väitettä johtajat kuulevat tällä hetkellä usein, ja kaikki kolme ovat vääriä:

- **”Olemme päivittäneet WordPressin, joten olemme turvassa.”** Aukko on PHP:ssä, ei CMS:ssä. CMS-päivitys ei sulje sitä.
- **”Olemme liian pieniä, kukaan ei hyökkää meihin.”** Hyökkäykset ovat automaattisia. Etsitään haavoittuvia palvelimia, ei tunnettuja nimiä.
- **”Päivitys on asennettu, joten asia on hoidettu.”** Päivitys ei poista haittaohjelmaa, joka on tuotu sisään aiemmin, eikä todista, ettei mitään ole tapahtunut.

## Miten PHP SOS auttaa konkreettisesti?

- **Tilannekuva johdolle:** Laadimme lyhyen yleiskatsauksen PHP-järjestelmistänne tilan ja suosituksen kera järjestelmittäin.
- **Toteutus:** Päivitämme, käynnistämme uudelleen tai otamme käyttöön väliaikaistoimet, missä päivitys ei vielä ole mahdollinen.
- **Tarkistus:** Tallennamme lokit ja tarkistamme hyökkäyksen jäljet.
- **Todiste:** Saatte dokumentaation, jota voitte käyttää sisäisesti ja kolmansia osapuolia kohtaan.

Toimintatavan kuvaa [PHP2Shell-pikaapu](https://phpsos.de/fi/leistungen/php2shell-soforthilfe/).

## Yhteenveto

PHP2Shell on tekninen aukko, jossa on johtamistehtävä. Tekniikan hoitavat asiantuntijat. Johto huolehtii siitä, että joku vastaa, että viisi kysymystä saavat vastauksen ja että päätökset tehdään tietoisesti ja dokumentoidaan. Se mahtuu yhteen aamupäivään, jos aloitatte tänään.


## Usein kysytyt kysymykset

**Onko johdon itse huolehdittava PHP2Shellistä?**  
Ei tekniseen toteutukseen, mutta ohjaukseen kyllä. Johdon tulee varmistaa, että vastuut ovat selvät, BSI:n suositus toteutetaan ja päätökset, kuten väliaikainen sulkeminen, tehdään tietoisesti ja dokumentoidaan.

**Miten selitän aukon yhdellä lauseella?**  
PHP:ssä, ohjelmistossa, jolla useimmat verkkosivustot ja verkkokaupat toimivat, on kaksi kriittistä virhettä, joiden kautta ulkopuoliset voivat käynnistää ohjelmia palvelimella ilman salasanaa; päivitys on saatavilla ja se on asennettava.

**Mitä tekemättä jättäminen maksaa?**  
Sitä ei voi yleisesti arvioida. Onnistuneen hyökkäyksen mahdollisia seurauksia ovat seisokit, tietovuoto, ilmoitusvelvollisuudet, puhdistuksen ja forensiikan työ sekä asiakkaiden luottamuksen menetys. Päivitys tarkistuksineen on yleensä selvästi vähemmän työlästä.

**Riittääkö, että hosting-yritys huolehtii asiasta?**  
Jaetussa verkkohotellissa päivityksen asentaa yleensä hosting-yritys. Pyytäkää vahvistus kirjallisena, myös PHP-prosessien uudelleenkäynnistyksestä. Vahvistus ei vastaa siihen, onko ennen päivitystä tapahtunut jotain; siihen tarvitaan verkkosivuston tarkistus.

## Lähteet

- [BSI: Saksan liittovaltion tietoturvavirasto](https://www.bsi.bund.de/)
- [php.net: tietoturvatiedotteet](https://www.php.net/)
- [GDPR art. 33: ilmoitus valvontaviranomaiselle](https://dsgvo-gesetz.de/art-33-dsgvo/)