# PHP2Shellin jälkeen: miksi lisäilmoitukset ovat todennäköisiä

> PHP2Shellin jälkeen uudet PHP-ilmoitukset ovat todennäköisiä. Mistä sen tunnistaa, mitä lähteitä seurata ja miten tiiminne reagoi valmistautuneena.

Lähde: https://phpsos.de/fi/blog/weitere-php-meldungen/  
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:** PHP2Shellin jälkeen lisäilmoitukset PHP:stä ovat todennäköisiä, koska jo kaksi päivää päivityksen jälkeen tuli kolmas ilmoitus, täydellinen tietoturvailmoitus on vielä odotettavissa ja jakelut toimittavat pakettinsa porrastetusti. Joka nyt rakentaa kiinteän kulun seurannalle, arvioinnille, päivitykselle ja uudelleenkäynnistykselle, reagoi seuraavaan uuteen PHP-tietoturva-aukkoon tunneissa päivien sijaan.

## Päivitys ei ollut tarinan loppu

PHP-projekti sulki 21. lokakuuta 2026 kaksi kriittistä aukkoa, CVE-2026-109618 ja CVE-2026-109619, versioilla 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Monet vastuuhenkilöt rastittivat sen jälkeen asian. Kaksi päivää myöhemmin, 23. lokakuuta, tuli kuitenkin php.netiltä uusi ilmoitus CVE-2026-115560:sta.

Tämä kolmas ilmoitus koskee vain epätavallista session-konfiguraatiota. Se osoittaa kuitenkin kuvion, joka tunnetaan suurista tietoturvatapauksista: kun jokin komponentti yhtäkkiä joutuu valokeilaan, monet asiantuntijat katsovat samalla tarkemmin. Syntyykö siitä lisää aukkoja, ei tänään tiedä kukaan. Todennäköistä kuitenkin on, ettei uutistilanne laannu.

Teille ylläpitäjinä se tarkoittaa: varautukaa jatkoilmoituksiin sen sijaan, että jokainen yllättäisi. Tähänastisen tapahtumakulun tiivistää [PHP2Shellin kronologiamme](https://phpsos.de/fi/ratgeber/php2shell-chronologie/).

## Miksi lisäilmoitukset ovat todennäköisiä

Seuraava arvio perustuu julkisesti tunnettuihin tosiasioihin. Se ei ole yksittäisten aukkojen ennuste.

1. **Tietoturvailmoitus on vielä tulossa.** php.net käsittelee CVE-2026-115560:n säännöllisessä julkaisusyklissä ja on ilmoittanut julkaisevansa täydellisen ilmoituksen seuraavan julkaisun yhteydessä. Siihen asti korjaavana toimena pidetään asetusta `session.upload_progress.enabled=0`.
2. **Yksityiskohdat olivat julkisia varhain.** Useiden raporttien mukaan yksityiskohdat tulivat tietoon ennen embargon päättymistä. Raporttien mukaan watchTowr on omien tietojensa mukaan toistanut CVE-2026-109618:n. Tällainen työ johtaa usein jatkokysymyksiin viereisistä koodikohdista.
3. **Jakelut toimittavat porrastetusti.** Ubuntu varusti 21. lokakuuta ajantasaiset julkaisut ilmoituksella USN-8948-1 ja toimitti ilmoituksella USN-8948-2 lisäkorjaukset versioille 14.04–20.04 Ubuntu Pron kautta. Red Hat kirjoitti tiedotteessaan, että osa päivityksistä on saatavilla ja lisää on työn alla.
4. **Kehitysversio on alttiina.** php.netin mukaan myös PHP 8.6.0 RC4 sisältää korjaukset. Joka testaa esiversioita, joutuu päivittämään myös nämä ympäristöt.
5. **Vanhat versiot pysyvät auki.** PHP 8.1:lle ja vanhemmille on vain minimaaliset lähdekoodin backportit. Jokainen palveluntarjoaja, joka toimittaa tällaisia versioita, ilmoittaa tilansa itsenäisesti ja omina ajankohtinaan.

## Miten uusi PHP-tietoturva-aukko tavoittaa teidät

Ilmoitukset tulevat eri teitä ja eri luotettavuudella. Järjestys on lähes aina sama: ensin PHP-projekti, sitten jakelut ja hosting-yritykset, sen jälkeen viranomaiset ja media.

| Lähde | Mitä sieltä kuulette | Kuinka luotettava |
|---|---|---|
| php.net | alttiit haarat, korjatut versiot, väliaikaistoimet | ensisijainen lähde |
| Ubuntu, Debian, Red Hat | pakettitilat julkaisuittain, toimituksen ajankohta | ensisijainen lähde järjestelmällenne |
| Hosting-yritykset ja paneelitoimittajat | omien PHP-rakennelmien tila | sitova vain kirjallisena |
| BSI, CERT-Bund | tilannearvio, varoitustaso, suositukset | viranomaisarvio |
| Ammattilehdistö ja tietoturvayritykset | hyökkäyshavainnot, luvut, taustat | hyödyllinen, merkittävä raportiksi |

Tärkeä on ero ”korjaus on olemassa” ja ”järjestelmälläni on korjaus” välillä. Ensimmäinen väite on php.netissä. Toinen teidän on todistettava jokaisesta palvelimesta itse.

> **Vinkki:**
> Tilatkaa php.netin ja jakelunne ilmoitukset RSS:llä tai sähköpostilistalla ja ohjatkaa ne yhteiseen postilaatikkoon tai kanavaan, jota lukee useampi kuin yksi henkilö. Loma ja sairaus ovat yleisimmät syyt myöhästyneisiin päivityksiin.

## Mitä kannattaa valmistella ennen seuraavaa ilmoitusta

PHP2Shellin kokemus osoittaa, missä aikaa kuluu: palvelimien etsimiseen, vastuiden selvittämiseen ja unohtuneeseen uudelleenkäynnistykseen. Kaiken tämän voi hoitaa etukäteen.

- **Luettelo:** Lista kaikista palvelimista ja verkkosivustoista PHP-haaroineen, ajotapoineen (PHP-FPM, mod_php, LiteSpeed) ja pakettilähteineen. Ilman tätä listaa jokainen ilmoitus alkaa etsimisellä. Miten se onnistuu, kuvaa artikkeli [Kaikkien verkkosivustojen ja palvelimien luettelo](https://phpsos.de/fi/blog/inventar-websites-server/).
- **Vastuu:** Jokaisesta järjestelmästä on selvää, kuka päivittää, kuka käynnistää uudelleen ja kuka hyväksyy. Hosting-yritysten ja toimistojen kohdalla se kuuluu sopimukseen.
- **Arviointiraami:** Kolme kysymystä riittää ensimmäiseen arvioon. Onko haaramme alttiina? Käytämmekö alttiita toimintoa tai ajotapaa? Onko päivitys olemassa vai vain väliaikaistoimia?
- **Testitie:** Staging-ympäristö, jossa PHP-päivityksen voi tarkistaa lyhyessä ajassa.
- **Todiste:** Kiinteä muoto, johon kirjataan pakettitila, muutoslokin osuma ja uudelleenkäynnistyksen ajankohta.

Miten tällainen kulku toimii rutiinina palokunta-ajojen sijaan, kerrotaan kohdassa [Päivityshallinta prosessina](https://phpsos.de/fi/blog/patch-management-prozess/). Taustaa PHP-projektin tavasta käsitellä aukkoja tarjoaa sivu [Miten PHP-projekti käsittelee tietoturva-aukkoja](https://phpsos.de/fi/php/php-sicherheitsprozess/).

## Oma konfiguraatio varhaisvaroitusjärjestelmänä

Osa jatkoilmoituksista koskee vain tiettyjä asetuksia. CVE-2026-115560 on tästä esimerkki: php.net mainitsee edellytykseksi, että sovellus vaihtaa session-serialisoijan ajon aikana upload progressin ollessa aktiivinen. Sovellukset, jotka eivät koskaan tee niin, eivät php.netin mukaan ole alttiita.

Joka tuntee todellisen konfiguraationsa, voi arvioida tällaiset ilmoitukset nopeammin. Kirjatkaa siksi jokaisesta haarasta, mitkä arvot on asetettu palvelinpuolella ja mitkä sovellukset saavat ylikirjoittaa ne. Jo aktiivisten asetusten yksinkertainen vertailu auttaa:

```bash
# Komentorivin todelliset arvot (verkkokonfiguraatio voi poiketa)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"

# FPM-pooleissa asetetut arvot (polku vaihtelee jakelun mukaan)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
```

Komentorivi ei välttämättä näytä, mikä on voimassa verkkokontekstissa. Selvyyden tuovat pooli- tai VirtualHost-konfiguraatio ja, lyhytaikaisesti ja suojatusti, phpinfo-sivu.

Toinen etu: joka tietää, mitkä väliaikaisarvot ovat vielä asetettuina PHP2Shell-viikolta, voi tarkistaa ne tietoisesti seuraavan säännöllisen julkaisun jälkeen. Jotkut asetukset, kuten pois kytketty upload progress, voivat pysyä pysyvästi järkevinä. Toiset, kuten hyvin niukat latausrajat, kannattaa mukauttaa takaisin todelliseen tarpeeseen yhdessä osastojen kanssa.

## Miten PHP SOS auttaa konkreettisesti?

- Seuraamme php.netin, jakeluiden ja BSI:n ilmoituksia ja arvioimme uudet ilmoitukset konkreettisille järjestelmillenne.
- Laadimme kanssanne luettelon kaikista PHP-asennuksista ja määrittelemme vastuut palvelinkohtaisesti.
- [Tietoturvahuoltosopimuksen](https://phpsos.de/fi/leistungen/security-wartungsvertrag/) puitteissa asennamme päivitykset, käynnistämme kaikki prosessit uudelleen ja dokumentoimme tilan.
- Ilmoituksissa ilman päivitystä otamme käyttöön ylikirjoittamattomat väliaikaistoimet ja tarkistamme ne jälkikäteen.


## Usein kysytyt kysymykset

**Onko PHP2Shellin jälkeen jo uusi PHP-tietoturva-aukko?**  
php.net julkaisi 23. lokakuuta 2026 ilmoituksen CVE-2026-115560:sta. Sen mukaan koodin suoritus on mahdollinen vain epätavallisella session-konfiguraatiolla. Täydellisen ilmoituksen on määrä seurata seuraavan säännöllisen julkaisun yhteydessä.

**Pitääkö minun toimia heti jokaisen uuden ilmoituksen jälkeen?**  
Kaikki ilmoitukset eivät vaadi samaa kiirettä. Ratkaisevia ovat vakavuusaste, konfiguraationne alttius ja se, onko päivitys saatavilla. Kiinteä kulku auttaa arvioimaan sen minuuteissa päivien sijaan.

**Mistä kuulen uusista PHP-aukoista ensimmäisenä?**  
Ensisijaisia lähteitä ovat php.netin ilmoitukset ja jakelunne tietoturvaohjeet, esimerkiksi Ubuntu Security Notices, Debian Security Tracker tai Red Hat. BSI tiedottaa varoituksista. Mediaraportit ovat hyödyllisiä mutta usein myöhempiä ja epätarkempia.

**Miksi jakelut ilmoittavat joskus päiviä myöhemmin kuin php.net?**  
Jakeluiden on otettava korjaus omiin paketteihinsa, rakennettava ja testattava se. Vanhemmille julkaisuille se voi kestää pidempään tai tapahtua vain lisäpalveluilla. Siksi kannattaa seurata molempia lähteitä erikseen.

## Lähteet

- [php.net: ilmoitukset ja tietoturvaohjeet](https://www.php.net/)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [BSI](https://www.bsi.bund.de/)