”Black October” oli nimitys lokakuussa 2026 kasautuneille kyberturvallisuustapahtumille ja haavoittuvuuksien julkistuksille — ei yhdelle koordinoidulle hyökkäykselle. Huomion keskipisteeksi nousi PHP2Shell: kaksi PHP:n kriittistä haavoittuvuutta, joiden avulla hyökkääjä saattoi suorittaa koodia haavoittuvalla palvelimella ilman kirjautumista. Haavoittuvuuksien löytämisessä käytettiin tiettävästi tekoälymalleja. Julkisuuteen ennenaikaisesti päätyneet tiedot ja raportit haavoittuvuuksien kokeilusta ennen korjausten julkaisua lisäsivät kiirettä.
3
27
45
Mitä PHP2Shell tarkoitti?
Haavoittuvuudet, CVE-2026-109618 ja CVE-2026-109619, koskivat PHP-asennuksia, jotka käsittelevät verkkopyyntöjä. Niitä saattoi olla käytössä esimerkiksi PHP-FPM:n tai Apachen mod_php:n kanssa.
1 Kummankin haavoittuvuuden CVSS v4.0 -vakavuuspisteet olivat 9,2, ja niiden avulla hyökkääjä saattoi suorittaa etänä koodia ilman käyttäjätiliä.
18
Tutkijat käyttivät raporttien mukaan tekoälymalleja haavoittuvuuksien löytämiseen.
45 Tämä ei kuitenkaan tarkoita, että tekoäly olisi itsenäisesti tehnyt hyökkäykset. Keskeinen riski liittyi haavoittuvaan PHP-ohjelmistoon ja sitä vastaan lähetettyihin tarkoituksella muotoiltuihin pyyntöihin.
Tietovuoto, kokeilut ja kiireelliset korjaukset
SecurityWeekin ja VulnCheckin mukaan haavoittuvuuksien tiedot vuotivat verkkoon 20. lokakuuta ennen suunniteltua julkistusta.
27
38 Amazon Threat Intelligence kertoi havainneensa epäillyn hyväksikäyttöyrityksen hunajapurkkiverkossaan 17. lokakuuta — neljä päivää ennen PHP:n korjausten julkaisua.
27 Epäilty yritys kertoo haavoittuvuuden kokeilusta, ei siitä, että jokin todellinen järjestelmä olisi varmasti murrettu.
PHP julkaisi tietoturvapäivitykset 21. lokakuuta 2026. Korjatut versiot olivat PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35.
18 Yhdysvaltain kyberturvallisuusvirasto CISA kehotti organisaatioita asentamaan päivitykset viipymättä ja lisäsi molemmat haavoittuvuudet tunnettujen aktiivisesti hyödynnettyjen haavoittuvuuksien luetteloonsa 26. lokakuuta.
1
Hyväksikäyttö oli vakava riski — mutta yritykset eivät ole sama asia kuin murrot
VulnCheck kertoi kehittäneensä toimivan hyväksikäyttömenetelmän haavoittuvuudelle CVE-2026-109618. Menetelmä yhdisti varmistetun muistivuodon etäkoodin suorittamiseen PHP 8.4.26 -versiossa x86-64-järjestelmällä, vaikka ASLR-muistisuojaus oli käytössä ja display_errors=off.
43 Havainto osoittaa, ettei muistisuojauksia pidä pitää päivitysten korvikkeena. Se koski kuitenkin VulnCheckin kuvaamaa kokoonpanoa, eikä osoita kaikkien PHP-järjestelmien olleen yhtä helposti haavoitettavissa.
Raporteissa kuvattiin myös hyökkäysketju, jossa PHP2Shell yhdistettiin Linux-ytimen Fragnesia-haavoittuvuuteen juuripääsyn saamiseksi palomuureihin valtiolliseen toimintaan liittyvässä ympäristössä.
21 Erillisessä uutisoinnissa kerrottiin kohdennetuista hyökkäyksistä internetiin avoimia PAN-OS-hallintaliittymiä vastaan.
25 Nämä havainnot kertovat todellisesta riskistä, mutta eivät yksin osoita, että PHP-asennuksia olisi murrettu laajamittaisesti.
Ero on tärkeä: haavoittuvuuden kokeileminen tai järjestelmien skannaaminen ei vielä tarkoita onnistunutta murtoa. Lokakuun 23. päivänä julkaistussa tietoturvatiedotteessa kerrottiin, ettei tuolloin ollut tiedossa vahvistettuja laajamittaisia PHP2Shell-murtoja. VulnCheck oli silti osoittanut haavoittuvuuden toimivan tietyssä kokoonpanossa.
33
43
Mitä organisaatioiden kannattaa tehdä?
- Päivitä haavoittuvat PHP-asennukset. Asenna käytössä olevaan PHP-haaraan julkaistu korjausversio tai sitä uudempi soveltuva tietoturvapäivitys. CISA kehotti päivittämään välittömästi.
1
18
- Etsi PHP myös julkisten verkkosivujen ulkopuolelta. CISA:n varoitus koskee verkkopyyntöjä käsitteleviä PHP-asennuksia erilaisissa palvelin- ja sovellusympäristöissä.
1 Tarkista myös laitteet ja hallintaliittymät, joihin PHP voi olla sisäänrakennettuna.
- Käsittele päivittämättömiä, internetiin avoimia järjestelmiä kiireellisinä. Jos päivitystä ei voida asentaa heti, selvitä, voiko pääsyä rajata tai palvelun eristää korjauksen ajaksi.
- Selvitä, onko järjestelmään jo yritetty päästä. Koska kokeiluista raportoitiin ennen korjausten julkaisua, päivitys ei yksin todista, ettei järjestelmää olisi aiemmin vaarannettu.
27
PHP2Shellin käytännön opetus on selvä: kun kriittinen haavoittuvuus koskee laajasti käytettyä palvelinohjelmistoa, on tärkeää sekä tietää, missä ohjelmistoa ajetaan, että reagoida nopeasti.