# CVE-2026-109619: RCE vanhentuneen globaalin tilan kautta

> CVE-2026-109619 ymmärrettävästi: miksi pyyntöjen välinen sisäinen tila on vaarallinen, mitkä PHP-versiot on korjattu ja miten suojaudutte.

Lähde: https://phpsos.de/fi/php2shell/cve-2026-109619/  
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:** CVE-2026-109619 on toinen PHP2Shellin takana olevista haavoittuvuuksista. Pyyntöön kuuluva sisäinen tila voi säilyä muistin vapauttamisen jälkeen; myöhempi pyyntö samassa workerissa voi hyödyntää sitä ennen kuin se nollataan. Seurauksena on koodin suorittaminen ilman kirjautumista. Apu: päivitys versioon PHP 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 ja kaikkien workerien uudelleenkäynnistys.

## Mikä on CVE-2026-109619?

CVE-2026-109619:n (GitHub-tunniste GHSA-6wmf-4rv5-p3rp) CVSS v4.0 -pistemäärä on 9.2. Yhdessä haavoittuvuuden [CVE-2026-109618](https://phpsos.de/fi/php2shell/cve-2026-109618/) kanssa se muodostaa PHP2Shellin. Molemmat haavoittuvuudet ovat itse PHP:ssä eivätkä sovelluksessa.

Vaikutus on sama kuin sisarhaavoittuvuudella: hyökkääjä voi suorittaa koodia palvelimella etänä, ilman salasanaa ja ilman käyttäjätiliä. Syy on kuitenkin toinen.

## Miksi vanhentunut tila workerissa on vaarallinen

PHP-verkkopalvelin ei käynnistä uutta prosessia jokaiselle pyynnölle. PHP-FPM:ssä, Apachessa mod_php:n kanssa, LiteSpeedissä tai FrankenPHP:ssä yksi worker käsittelee peräkkäin monta pyyntöä. Kahden pyynnön välillä PHP nollaa sisäisen tilansa, jotta mikään ei siirry pyynnöstä A pyyntöön B.

Haavoittuvuudessa CVE-2026-109619 tämä nollaus ei onnistu täydellisesti. php.netin mukaan pyyntöön kuuluva sisäinen tila voi säilyä muistin vapauttamisen jälkeen. Myöhempi pyyntö samassa workerissa voi hyödyntää tätä vanhentunutta tilaa ennen kuin se nollataan. Yksinkertaistaen: jotain käytetään edelleen, vaikka se ei oikeastaan ole enää kelvollista.

Käytön kannalta tämä on huomionarvoista. Workerien uudelleenkäyttö on tarkoituksellista, koska se tekee verkkopalvelimista nopeita: workerin ei tarvitse käynnistyä uudelleen jokaiselle pyynnölle, ladata laajennuksia ja varata muistia. Haavoittuvuus osuu siis ominaisuuteen, joka on käytännössä jokaisessa tuotannossa olevassa PHP-asennuksessa. php.net ei mainitse konfiguraatiota, joka välttäisi ongelman kokonaan; siksi tie kulkee päivityksen kautta.

Hyödyntämisen yksityiskohtia emme julkaise. Ylläpitäjille ratkaisevaa on: jokaista ajotapaa, jossa workerit palvelevat useita pyyntöjä, on tarkkailtava, ja juuri nämä ovat yleiset ajotavat.

## Kaksi PHP2Shell-haavoittuvuutta vertailussa

| Ominaisuus | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub-tunniste | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Arvio | CVSS v4.0 9.2 | CVSS v4.0 9.2 |
| Laukaisija | Out-of-Memory pyyntötietojen alustuksen aikana | Sisäinen tila säilyy vapauttamisen jälkeen |
| Vaikutus | Koodin suorittaminen ilman kirjautumista | Koodin suorittaminen ilman kirjautumista |
| Korjattu versioissa | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

Haavoittuvia ovat PHP-FPM, Apache mod_php:n kanssa, php-cgi, FrankenPHP ja LiteSpeed. Suurimman riskin PHP-tiimi näkee mod_php:ssä; miksi, selitämme sivulla [Miksi mod_php kantaa suurimman riskin](https://phpsos.de/fi/php2shell/mod-php-risiko/).

## CVE-2026-109619:n sulkeminen: päivitys, sitten kaikkien workerien uudelleenkäynnistys

Juuri tässä haavoittuvuudessa uudelleenkäynnistys on ratkaiseva. Niin kauan kuin vanhat workerit toimivat muistissa, palvelin jatkaa virheellisellä koodilla, vaikka uudet tiedostot olisivat jo pitkään levyllä.

Tarkistakaa versio ja paketin tila. Pakettien nimet vaihtelevat jakelun ja hosting-yrityksen käyttöliittymän mukaan:

```bash
php -v
php-fpm8.3 -v                  # FPM-binäärillä voi olla eri versio kuin CLI:llä
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL-perhe
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
```

Sen jälkeen kaikki kyseiset palvelut käynnistetään uudelleen:

```bash
sudo systemctl restart php8.3-fpm     # jokaiselle asennetulle PHP-versiolle
sudo systemctl restart apache2        # mod_php:n kanssa; RHEL:ssä palvelun nimi on httpd
```

Jos jakelunne tai hosting-yrityksenne asentaa backportin, näytetty versionumero voi pysyä samana. Silloin ratkaisevia ovat paketin muutosloki ja palveluntarjoajan kirjallinen vahvistus. Vaihe vaiheelta -tarkistuksen löydätte sivulta [PHP-FPM ja kaikkien workerien uudelleenkäynnistys](https://phpsos.de/fi/php2shell/php-fpm-neustart/).

> **Vinkki:**
> Kirjatkaa ylös uudelleenkäynnistyksen päivämäärä ja kellonaika. Myöhemmässä arvioinnissa siitä, tapahtuiko hyökkäys ennen vai jälkeen korjauksen, tämä ajankohta on tärkein vertailukohta.

## Mitä korjauksen jälkeen on vielä tehtävä

Korjaus ei todista, ettei aiemmin ole tapahtunut mitään. Mediaraporttien mukaan ensimmäinen hyökkäysyritys havaittiin 17. lokakuuta, neljä päivää ennen korjauksia. Säilyttäkää palvelinlokit 20. lokakuuta alkaen, kuten ammattilehdistö suosittelee, ja tarkistakaa palvelimen poikkeamat. Vihjeitä löytyy sivulta [Onko minuun jo murtauduttu?](https://phpsos.de/fi/php2shell/bin-ich-gehackt-anzeichen/).

Ajatelkaa samalla ulottuvuutta: onnistuneessa koodin suorittamisessa hyökkääjällä on PHP-prosessin oikeudet. Hän voi lukea sen, minkä sovellus saa lukea, esimerkiksi asetustiedostot tietokantatunnuksineen tai API-avaimineen. Jos poikkeama vahvistuu, nämä tunnukset kuuluu uusia puhdistuksen jälkeen.

## Miten PHP SOS auttaa konkreettisesti?

[PHP-korjauspalvelulla](https://phpsos.de/fi/leistungen/php-patch-service/) toteutamme korjauksen jäljitettävästi:

- **Kartoitus:** Mitä PHP-versioita ja ajotapoja millä palvelimella on käytössä ja mikä pakettilähde ne toimittaa?
- **Korjaus:** Päivitys oikeasta lähteestä tai php.netin mukaiset väliaikaiset toimenpiteet, jos päivitys on vielä esteenä.
- **Uudelleenkäynnistyksen tarkistus:** Tarkistamme prosessi prosessilta, että käynnissä on enää vain korjattu versio.
- **Dokumentointi:** Versiot, pakettitilat ja uudelleenkäynnistysajankohdat, jotta voitte todistaa tilan.


## Usein kysytyt kysymykset

**Mikä erottaa CVE-2026-109619:n haavoittuvuudesta CVE-2026-109618?**  
CVE-2026-109618 syntyy, kun Out-of-Memory-tila keskeyttää pyynnön kesken alustuksen. CVE-2026-109619 koskee tilaa, joka jää workeriin pyynnön päätyttyä. Molemmat johtavat koodin suorittamiseen ilman kirjautumista, ja ne on korjattu samoissa PHP-versioissa.

**Auttaako PHP-FPM-workerien useammin tehty uudelleenkäynnistys?**  
Päivityksen korvikkeeksi se ei kelpaa. php.net ei mainitse tiheämpiä worker-uudelleenkäynnistyksiä väliaikaisena toimenpiteenä. Workerit on kuitenkin käynnistettävä uudelleen päivityksen jälkeen, jotta korjattu versio ylipäätään toimii.

**Olenko suojattu CVE-2026-109619:ltä CMS-päivityksellä?**  
Et. Haavoittuvuus on PHP:ssä eikä WordPressissä, Shopwaressa, TYPO3:ssa tai muussa järjestelmässä. Sen sulkee vain PHP-päivitys tai palveluntarjoajan vahvistama backport.

**Onko CVE-2026-109619:n kautta tehdystä hyökkäyksestä tunnettuja jälkiä?**  
Vahvistettuja Indicators of Compromise -tunnisteita ei ole toistaiseksi julkaistu. Havaitseminen perustuu käyttäytymisanalyysiin, esimerkiksi uusiin PHP-tiedostoihin, epätavallisiin lähteviin yhteyksiin tai tuntemattomiin cron-tehtäviin.

## Lähteet

- [php.net: tietoturvatiedotteet](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Saksan liittovaltion tietoturvavirasto](https://www.bsi.bund.de/)