PHP:n kriittiset haavoittuvuudet – päivitä nyt (CVE-2026-109618 ja CVE-2026-109619)

PHP-projekti ilmoitti 20. lokakuuta kahdesta kriittisestä haavoittuvuudesta ja turvapäivityksestä. Korjaukset julkaistiin 21. lokakuuta kello 13.30 UTC. Molemmat haavoittuvuudet mahdollistavat todentamattoman etäkoodin suorittamisen CVSS-arvolla 9,2, ja julkista proof-of-concept-koodia kiertää jo.

Tätä haavoittuvuutta ei aikatauluteta seuraavaan huoltokatkoon. Se korjataan tänään.

Lyhyesti

• Päivitä versioon PHP 8.5.12, 8.4.27, 8.3.36 tai 8.2.35.
• Kaikki verkkopyyntöjä käsittelevä PHP on haavoittuva – PHP-FPM, mod_php, php-cgi, FrankenPHP ja LiteSpeed.
• Yksi todentamaton pyyntö voi riittää, ja se voi osua ennen kuin sovelluskoodinne edes suoritetaan.
• PoC-koodi on julkinen. Odota laajamittaista skannausta tunneissa, ei viikoissa.
• Jos ette voi päivittää heti: eristä internetiin näkyvät palvelut, kunnes korjaus on paikallaan ja varmennettu.

Mitä tapahtui

PHP-projekti ilmoitti 20. lokakuuta, että turvapäivitys on tulossa. Seuraavana päivänä, 21. lokakuuta kello 13.30 UTC, korjaukset julkaistiin neljässä versiossa samanaikaisesti: 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. CERT-EU antoi turvavaroituksen samana päivänä ja kehotti organisaatioita päivittämään välittömästi.

Nopea korjaus on hyvä asia. Se, että tekninen kuvaus tuli samalla julkiseksi, tarkoittaa, että aika kohdasta "korjaus saatavilla" kohtaan "hyökkääjät yrittävät" mitataan tunneissa.

Mitä haavoittuvuudet todella tekevät

CVE-2026-109618 – muistin korruptio muistirajalla

PHP pysäyttää memory_limit-rajan ylittävän pyynnön keskeyttämällä sen longjmp()-kutsulla. Keskeytys voi siksi tapahtua kesken sisäisen operaation, kun pyynnön data on vain osittain alustettu – esimerkiksi lomakkeen tiedostolatauksen jäsentämisen aikana.

Pyynnön siivous voi tämän jälkeen käsitellä virheellistä dataa kelvollisena ja vapauttaa muistia, jota ei koskaan alustettu. Muistissa voi yhä olla hyökkääjän hallitsemaa dataa aiemmista varauksista. Tuloksena on muistin korruptio, joka voi johtaa koodin suorittamiseen.

CVE-2026-109619 – jäljelle jäävä globaali tila

Yhteen pyyntöön kuuluva sisäinen tila voi säilyä sen jälkeen, kun sen muisti on vapautettu – esimerkiksi vakavan virheen jälkeen. Myöhempi pyyntö, jonka sama työprosessi käsittelee, voi käyttää jäljelle jäänyttä tilaa ennen kuin normaali alustus on ehtinyt palauttaa sen.

Kumpikaan haavoittuvuus ei siis edellytä, että sovelluksessanne on bugi. Ne ovat PHP:n omassa pyyntöjen käsittelyssä.

Demonstroitu exploit osoittaa, että yksi todentamaton pyyntö voi laukaista hyökkäyksen ennen kuin mitään sovelluskoodia suoritetaan.

Keitä haavoittuvuus koskee

Kaikkia verkkoliikennettä palvelevia PHP-asennuksia. PHP-tiimi pitää mod_php:tä altteimpana kokoonpanona.

• PHP 8.5 ennen versiota 8.5.12
• PHP 8.4 ennen versiota 8.4.27
• PHP 8.3 ennen versiota 8.3.36
• PHP 8.2 ennen versiota 8.2.35
• Elinkaarensa päässä olevat haarat (PHP 8.1 ja vanhemmat), jotka eivät enää saa säännöllisiä päivityksiä

Lisäksi: monet kaupalliset ja avoimen lähdekoodin tuotteet käyttävät PHP:tä taustalla. Ne voivat olla haavoittuvia, vaikka ette itse ylläpitäisi PHP-asennusta. NCSC-NL on julkaissut luettelon kolmannen osapuolen ohjelmista, joihin PHP on upotettu.

Yleisin virhe, jonka näemme: lasketaan vain ne palvelimet, jotka on itse asennettu. Älkää unohtako kontteja, CI-kuvia, laitteita, sisäisiä työkaluja ja toimittajien ylläpitämiä palveluita.

Tarkista tilanne – viisi minuuttia ympäristöä kohden

1. Aja php -v jokaisella isännällä ja jokaisessa kontissa. Ei vain yhdessä.
2. Kartoita ajonaikaiset ympäristöt: PHP-FPM-poolit, Apache ja mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Rakenna konttikuvat uudelleen – peruskuva ratkaisee, ei käynnissä oleva instanssi.
4. Kysy toimittajilta, jotka ylläpitävät PHP:stä riippuvia tuotteita teille: mikä versio teillä on käytössä ja milloin päivitys tulee?
5. Etsi elinkaarensa päässä olevat haarat. PHP 8.1 ja vanemmat eivät saa säännöllisiä korjauksia.

Korjaa

Jakelun paketit. Linux-jakelut ja LTS-toimittajat saivat korjaukset etukäteen. Päivitä paketinhallinnan kautta ja käynnistä työprosessit uudelleen.

Kontit. Päivitä peruskuva ja rakenna uudelleen. Vanhan kuvan uudelleenkäynnistys ei ratkaise mitään.

Itse käännetty. Päivitä versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35.

Elinkaarensa päässä olevat versiot. PHP-tiimi on julkaissut minimaaliset backportit versioille 7.4, 8.0 ja 8.1 niille, jotka kääntävät lähdekoodista tai joilla ei ole LTS-toimittajaa. Jos teillä on LTS-toimittaja: ottakaa häneen yhteyttä ensin.

rpms.remirepo.net: tämä vapaaehtoisvoimin ylläpidetty repositorio ei saa päivityksiä julkaisupäivänä. PHP-tiimi kehottaa käyttäjiä siirtymään jakelun paketteihin tai kääntämään lähdekoodista.

Käynnistä PHP-FPM ja muut työprosessit uudelleen päivityksen jälkeen. Uusi binääri ilman uudelleenkäynnistystä on yhä vanha prosessi.

Jos ette voi päivittää tänään

Alla olevat toimenpiteet vähentävät altistumista tietyille hyökkäyspoluille. Ne eivät tee asennuksesta turvallista. Vain päivitys sulkee haavoittuvuuden.

CVE-2026-109618 vastaan:

• Aseta memory_limit=-1 tavalla, jota sovellus ei voi ylikirjoittaa, esimerkiksi php_admin_value FPM-poolissa tai Apache-konfiguraatiossa. Varmista, ettei mikään pool, hakemisto tai sovellusasetus palauta rajaa.
• Aseta matala post_max_size: 8M sovelluksille ilman tiedostolatauksia, 32M kun latauksia tarvitaan. Pidä upload_max_filesize pienempänä kuin post_max_size.
• Aseta verkkopalvelimelle tai välityspalvelimelle rajat puretun pyynnön koolle, kenttien määrälle, multipart-osien määrälle, otsakkeiden määrälle ja sisäkkäisyyden syvyydelle. Rajojen on katettava myös pyynnöt, joissa ei ole käyttökelpoista Content-Length-otsaketta.
• Käytä kontin tai cgroupin muistirajaa saatavuusrajana, mieluiten käytännöllä, joka tappaa vain kärsineen työprosessin. Älä käytä RLIMIT_AS- tai RLIMIT_DATA-rajaa – ne voivat laukaista haavoittuvan varauspolun.

CVE-2026-109619 vastaan:

• Aseta session.upload_progress.enabled=0 ja käynnistä jokainen työprosessi uudelleen. Aseta se php.ini-tiedostoon, FPM-pooliin tai palvelinkonfiguraatioon niin, että se on voimassa ennen pyynnön jäsentämistä. Älä luota ini_set()-kutsuun tai FPM:n .user.ini-tiedostoon.
• PHP 8.5:ssä: aseta fatal_error_backtraces=0 ja käynnistä jokainen työprosessi uudelleen.
• Poista virheelliset tai vanhentuneet pyyntökohtaiset asetukset, jotka tuottavat diagnostiikkaa ennen alustusta. Diagnostiikan piilottaminen error_reporting-, display_errors- tai @-keinolla ei auta.
• Korjaa vakavat virheet ja suoritusaikarajat, joihin hyökkääjä voi päästä – callbackeissa, latauksissa, tuonneissa ja siivouksessa.

Miksi ei kannata odottaa

Kolme asiaa erottaa tämän tapahtuman tavallisesta päivityksestä:

1. Todennusta ei tarvita. Ei ole kirjautumista, jonka taakse piiloutua.
2. Hyökkäys tapahtuu ennen koodianne. Sovelluslogiikka, WAF-säännöt ja käyttöoikeusmalli eivät ole tässä suojamuuri.
3. PoC on jo julki. Se, mikä yleensä vie viikkoja, on jo jonkun muun tekemä.

Päivityksen ja uudelleenkäynnistyksen hinta tänään on mitätön murron hintaan verrattuna. Tämä koskee erityisesti teitä, joita NIS2 koskee: merkittävä poikkeama on ilmoitettava 24 tunnin kuluessa.

Päivityksen jälkeen – kolme asiaa

1. Varmenna jokaisella solmulla. Versio – ei vain paketinhallinnan OK.
2. Lue lokit taaksepäin. Multipart-POST-pyynnöt, odottamattomat 500-vastaukset, kaatuneet työprosessit ja liikenne tuntemattomista lähteistä viime päiviltä.
3. Pienimmästäkin epäilystä: käynnistä poikkeamamenettely. Eristä, turvaa lokit, arvioi ilmoitusvelvollisuus.

Lähteet

• CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: https://www.php.net/
• GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, luettelo tuotteista, joihin PHP on upotettu: https://github.com/NCSC-NL/php2shell

---

Tällaiset haavoittuvuudet ovat itsessään perustelu jatkuvalle turvallisuudelle: päivitykset, varmennus ja valvonta, jotka ovat käynnissä koko ajan – ei vuosittainen katsaus. Lue lisää siitä, mitä jatkuva turvallisuus tarkoittaa käytännössä.