PHP2Shell (CVE-2026-109618 ja CVE-2026-109619): mitä PHP:tä käyttävien yritysten pitää tehdä nyt

Teknikko työskentelee kannettavan tietokoneen kanssa palvelinräkin äärellä

PHP-projekti julkaisi 21. lokakuuta 2026 versiot 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Ne korjaavat kaksi haavoittuvuutta, jotka ”voivat mahdollistaa koodin etäsuorituksen ilman tunnistautumista”. Selkokielellä: kuka tahansa, joka pystyy lähettämään HTTP-pyynnön verkkosivustollesi, saattaa pystyä ajamaan omaa koodiaan palvelimellasi. Salasanaa ei tarvita, ja joissakin kokoonpanoissa hyökkäys toimii ennen kuin sovelluksesi on suorittanut riviäkään. Haavoittuvuuspari on saanut nimen PHP2Shell, ja PHP antaa kummallekin vakavuusarvon 9,2 (CVSS 4.0, asteikolla, jonka maksimi on 10).

Tämä opas on niille, joiden on toimittava: PHP-verkkosivustojen ja verkkokauppojen omistajille, IT-päälliköille ja kaikille, joiden PHP-järjestelmiä ylläpitää toimittaja. Se on kirjoitettu 22. lokakuuta 2026, julkaisua seuraavana päivänä, PHP-projektin omien tiedotteiden, kansallisten kyberturvallisuusviranomaisten ohjeiden ja toimittajien julkaisemien lukujen pohjalta. Missä lähteet ovat eri mieltä, kerromme sen.

Lyhyesti

Päivitä itse PHP ja käynnistä se sitten uudelleen. WordPressin, Drupalin, Laravelin tai lisäosan päivittäminen ei korjaa tätä. Vika on PHP:ssä, sovelluksesi alla.
PHP:n mukaan vaikutuspiirissä on jokainen PHP-asennus, joka palvelee verkkopyyntöjä: PHP-FPM, Apache ja mod_php, php-cgi, FrankenPHP ja LiteSpeed. Suurimpana riskinä PHP pitää Apachea, jossa on mod_php.
Lähes puolet PHP-sivustoista käyttää haaraa, jolle PHP-projekti ei enää julkaise versioita (oma tulkintamme W3Techsin tiedoista, ks. alla). Niille ei ole asennettavaksi virallista pakettia.
Asetukset ja palomuurit tuovat aikaa, eivät turvaa. PHP listaa väliaikaisia toimenpiteitä ja sanoo, että ne ”eivät tee asennuksesta turvallista”.
Jos et voi paikata tänään, Yhdysvaltain, Britannian ja EU:n viranomaiset neuvovat samoin: ota järjestelmä pois internetistä, kunnes voit.

Tapahtumat aikajärjestyksessä

19. elokuuta 2026. Wizin tutkijat löytävät julkaisunsa mukaan ensimmäisen haavoittuvuuksista ja ilmoittavat niistä PHP:n tietoturvatiimille 24. elokuuta. PHP:n tiedotteissa kiitetään myös useiden muiden yritysten tutkijoita.
20. lokakuuta. CVE-numerot vuotavat verkkoon kaksi päivää ennen suunniteltua julkistusta. PHP aikaistaa julkaisuaan päivällä, 21. lokakuuta klo 14:00 UTC:hen, ja kehottaa kaikkia valmistautumaan.
21. lokakuuta klo 03:02 UTC. Cloudflare ottaa palomuurisäännöt käyttöön kaikille asiakkailleen, joilla on sen verkkosovelluspalomuuri (WAF) käytössä, ilmaispaketti mukaan lukien. Myöhemmin se kertoo ”havainneensa asiakkaisiimme kohdistuvaa hyökkäysliikennettä” ja nähneensä hyökkääjien ”muuntelevan hyökkäyksen hyötykuormaa yrittäessään ohittaa suojauksemme”.
21. lokakuuta noin klo 14:00 UTC. PHP julkaisee korjaukset ja tiedotteensa. Samana päivänä Yhdysvaltain CISA, Britannian NCSC, CERT-EU sekä Euroopan komission, ENISAn, CERT-EU:n, Europolin ja EU:n kansallisten CSIRT-yksiköiden yhteinen julkilausuma kehottavat organisaatioita paikkaamaan välittömästi.

Kuinka vakava tilanne on?

Kolme asiaa erottaa tämän tavallisesta kuukausittaisesta päivityksestä.

Hyökkääjä ei tarvitse muuta kuin pyynnön. Kirjautumista ei tarvita, eikä kenenkään tarvitse klikata linkkiä. PHP:n tiedote kuvaa osoitettua hyökkäystä Apachea ja mod_php:tä vastaan, ”jossa tunnistautumaton pyyntö voi käynnistää hyökkäyksen ennen kuin mitään sovelluskoodia suoritetaan”. Wiz osoitti hyökkäyksiä ajantasaisia WordPress-, Drupal- ja Joomla-asennuksia vastaan ja huomauttaa, että ”jopa yksinkertainen ’Hello World’ -sovellus voi olla haavoittuva, jos se toimii haavoittuvuuden koskemalla PHP-versiolla”. Näin ajettu koodi saa verkkopalvelimen käyttäjätilin oikeudet, ja useimmilla sivustoilla tuo tili pystyy lukemaan sovelluksen asetukset: tietokannan salasanan, API-avaimet sekä sähköposti- ja maksupalveluiden tunnukset. Toisen haavoittuvuuden, CVE-2026-109619:n, osalta PHP vahvistaa lisäksi muistin paljastumisen: palvelimen muistista vuotaa tietoja ulos myös ilman täyttä koodin suoritusta.

Asennuskanta on valtava. W3Techsin mukaan PHP:tä käyttää 69,3 % niistä verkkosivustoista, joiden palvelinpuolen kieli tiedetään (luvut 22. lokakuuta 2026). Palo Alto Networksin Unit 42 laskee omien internet-skannaustensa perusteella yli 22,6 miljoonaa internetiin näkyvää instanssia, jotka ovat mahdollisesti haavoittuvia, ja kertoo, että ainakin yhden eurooppalaisen maan hallitus otti verkkosivustonsa varotoimena pois verkosta.

Hyökkäyskoodien kehitys etenee nopeasti. CERT-EU kertoo, että ensimmäiset proof of concept -koodit ”ovat alkaneet levitä”. Tietoturvayhtiö watchTowr sanoo hunajapurkkiensa havainneen hyödyntämistä 21. lokakuuta lähtien. Cloudflare raportoi hyökkäysliikennettä. Ja Wiz kertoo tutkijoidensa käyttäneen tekoälymalleja koko työn ajan, joten yksi tutkija teki viikossa sen, mikä ”olisi vienyt maailmanluokan tiimiltä kuukausia”. Hyökkääjillä, jotka sovittavat hyökkäyskoodia juuri sinun PHP-versioosi, on samat työkalut.

Reiluuden nimissä myös toinen puoli: kun CISA julkaisi varoituksensa 21. lokakuuta, se ei ollut havainnut hyödyntämistä, eikä kumpikaan haavoittuvuus ollut vielä sen Known Exploited Vulnerabilities -luettelossa (tunnetusti hyödynnettyjen haavoittuvuuksien luettelo). Red Hat luokittelee ongelman tasolle ”Important” eikä kriittiseksi, koska tavallisessa Red Hat Enterprise Linux -palvelimessa PHP:tä ajetaan PHP-FPM:llä, jossa hyödyntäminen on vaikeampaa. Vaikeampi ei ole mahdoton: PHP vahvistaa, että yksi toisen haavoittuvuuden hyökkäysreiteistä toimii myös PHP-FPM:ssä. Mikään tästä ei muuta sitä, mitä sinun pitää tehdä. Se muuttaa vain sitä, kuinka paljon varoitusaikaa saat.

Mikä versio sinulla on? Luvut

W3Techs julkaisee myös tiedot siitä, mitä PHP-versioita verkkosivustot käyttävät, ja laskee mukaan ne sivustot, jotka paljastavat versionsa. Kun sen kaksi 22. lokakuuta 2026 päivättyä taulukkoa yhdistetään:

PHP-haara	Osuus PHP-sivustoista	Korjaus PHP-projektilta
8.3, 8.4, 8.5	noin 34 %	Kyllä: 8.3.36, 8.4.27, 8.5.12
8.2	noin 18 %	Kyllä: 8.2.35. Mutta 8.2:n oma elinkaari päättyy 31. joulukuuta 2026
8.0, 8.1	noin 14 %	Ei julkaisua. 8.0 ja 8.1: vain backport-korjaus lähdekoodina
7.x	26,9 %	Ei julkaisua. 7.4: vain backport-korjaus lähdekoodina; 7.3 ja vanhemmat: ei mitään
5.x ja vanhemmat	7,8 %	Ei mitään

Noin 48 % PHP-sivustoista käyttää siis haaraa, jolle PHP-projekti ei julkaise korjattua versiota, ja toiset 18 % saavat korjauksensa nyt mutta menettävät tuen kymmenen viikon kuluttua.

Kaksi varausta. W3Techs näkee vain sivustot, jotka näyttävät versionsa. Lisäksi Linux-jakelu on voinut paikata vanhan haaran itse: Ubuntu on tehnyt niin, kuten alempana näet. Pelkkä versionumero ei kerro, oletko suojassa. Sen kertoo toimittajasi paketin versio.

Vaihe 1: etsi kaikki käyttämäsi PHP-asennukset

Et voi paikata sitä, mitä et ole listannut, ja PHP osaa piiloutua. Britannian NCSC pyytää organisaatioita etsimään jokaisen PHP-järjestelmän, internetiin näkyvät ensin, ja lisää: ”älkää rajatko kartoitusta vanhentuneisiin PHP-versioihin”. EU:n yhteinen julkilausuma varoittaa, että jotkin tuotteet ”voivat olla alttiita näille haavoittuvuuksille, vaikka ne eivät näyttäisi käyttävän PHP:tä suoraan”.

Mistä etsiä:

Verkkosivustot ja verkkokaupat: WordPress ja WooCommerce, Drupal, Joomla, Magento ja Adobe Commerce, Shopware, PrestaShop, TYPO3 sekä kaikki, mikä on rakennettu Laravelin tai Symfonyn päälle.
Unohdetut järjestelmät: kampanjoiden mikrosivustot, vanha kieliversio, internetistä tavoitettavat esituotanto- ja testipalvelimet, webmail tai helpdesk, jonka joku asensi vuosia sitten.
Kontit: jokainen php-pohjakuvasta rakennettu konttikuva sisältää oman PHP:nsä. Isäntäkoneen päivittäminen ei auta sitä lainkaan.
Hosting-hallintapaneelit: cPanel, Plesk ja vastaavat paneelit tuovat mukanaan omat PHP-käännöksensä järjestelmän oman PHP:n rinnalle. Jokainen paneelissa käyttöön otettu versio on päivitettävä erikseen.
Tuotteet, joiden sisällä on PHP: appliance-laitteet, valvontatyökalut, CRM-järjestelmät, helpdeskit ja toimittajien hallintakäyttöliittymät. Alankomaiden NCSC ylläpitää julkista listaa tällaisista tuotteista ja niiden tilasta toimittaja kerrallaan.
Toimittajat: hosting-yrityksesi, digitoimistosi ja mikä tahansa palvelu, jonka tiedät pyörivän PHP:n päällä. Kysy niiltä kirjallisesti, mitkä PHP-versiot järjestelmissäsi ovat käytössä ja milloin ne paikataan.

Kirjaa jokaisesta ylös PHP-versio, miten PHP:tä ajetaan (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, kontti), onko se tavoitettavissa internetistä ja kuka pystyy paikkaamaan sen.

Vaihe 2: paikkaa oikeassa järjestyksessä

Aloita kaikesta, mikä on tavoitettavissa internetistä, ja niiden joukossa Apachen mod_php-kokoonpanoista.

Tuetut haarat (8.2:sta 8.5:een). Päivitä versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai jakelusi pakettiin, joka sisältää korjauksen. PHP:n mukaan Linux-jakelut saivat korjaukset etukäteen. Tähän mennessä vahvistettu:

Ubuntu: korjatut paketit jokaiseen julkaisuun 14.04:stä 26.10:een. Versioissa 22.04 ja uudemmissa ne tulevat tavallisten päivitysten mukana; versioissa 20.04 ja vanhemmissa ne vaativat Ubuntu Pro -tilauksen, joka on maksuton enintään viidelle koneelle (Canonicalin tiedote).
Debian: php8.4 8.4.27 Debian 13:lle (DSA-6574-1) ja php8.2 8.2.35 Debian 12:lle (DLA-4848-1).
Red Hat Enterprise Linux: Red Hatin tietoturvatiedote RHSB-2026-013 listaa paketit julkaisuittain.
Remi-repositorio, jota käytetään laajalti uudempien PHP-versioiden asentamiseen Red Hat -perheen järjestelmiin: CERT-EU totesi 21. lokakuuta, ettei sille ollut julkaisupäivänä paketteja, ja neuvoi siirtymään jakelun paketteihin tai kääntämään lähdekoodista. Tarkista, onko se ehtinyt mukaan, ennen kuin luotat siihen.

PHP 7.4, 8.0 tai 8.1. PHP-projekti ei julkaise näille versioita. Sen tietoturvatiimi teki kolmelle haaralle minimaaliset backport-korjaukset lähdekoodiin, joista on apua, jos käännät PHP:n itse. Muuten korjauksen on tultava toimittajaltasi (esimerkiksi Ubuntu Pro kattaa PHP 7.4:n Ubuntu 20.04:ssä) tai siirtymällä uudempaan PHP-versioon. CISA:n neuvo kaikille, joilla on käytössä 8.1 tai vanhempi ja jotka eivät voi päivittää, on suorasukainen: ota järjestelmä pois verkosta, kunnes se on paikattu tai päivitetty uudempaan versioon.

PHP 7.3 tai vanhempi. PHP-projektilta ei tule mitään. Ellei jokin toimittaja yhä paikkaa käyttämääsi käännöstä, vaihtoehdot ovat siirtyminen uudempaan versioon tai järjestelmän ottaminen pois verkosta.

Käynnistä uudelleen päivityksen jälkeen. Paketin asentaminen ei korvaa jo käynnissä olevaa PHP:tä. Ubuntun tiedote sanoo sen suoraan: sovellus ”täytyisi todennäköisesti käynnistää uudelleen”. Käynnistä PHP-FPM, Apache, LiteSpeed tai kontti uudelleen jokaisella palvelimella. Tarkista sitten versio, jota verkkopalvelin todella käyttää, äläkä vain komentorivillä ajettua php -v -komentoa, joka voi kertoa eri käännöksestä.

Kontit: rakenna konttikuvat uudelleen paikatusta pohjakuvasta ja ota ne uudelleen käyttöön. Paikattu isäntäkone, jossa pyörii vanha konttikuva, on yhä altis.

Ylläpidetty hosting: kysy palveluntarjoajaltasi päivämäärä ja versio ja tarkista sitten itse.

Vaihe 3: jos et voi paikata tänään

PHP:n tiedote listaa väliaikaisia toimenpiteitä ja esittelee ne varoituksen kera: ne ”vähentävät altistumista tietyille hyökkäysreiteille mutta eivät tee asennuksesta turvallista”. Lyhyesti sille, joka ylläpitää palvelimiasi:

CVE-2026-109618:n osalta: aseta memory_limit=-1 niin, ettei sovellus voi ohittaa asetusta (esimerkiksi php_admin_value-direktiivillä PHP-FPM-poolissa tai Apachen asetuksissa); aseta matala post_max_size (PHP ehdottaa arvoa 8M ilman tiedostolatauksia ja 32M niiden kanssa); rajoita pyynnön kokoa, kenttien määrää ja multipart-osien määrää verkkopalvelimessa tai välityspalvelimessa; ja käytä kontin tai cgroupin muistirajaa, älä koskaan RLIMIT_AS-rajaa tai RLIMIT_DATA-rajaa.
CVE-2026-109619:n osalta: aseta session.upload_progress.enabled=0 php.ini-tiedostossa tai palvelimen asetuksissa (ei ini_set()-funktiolla eikä .user.ini-tiedostolla) ja käynnistä jokainen worker-prosessi uudelleen. PHP 8.5:ssä aseta lisäksi fatal_error_backtraces=0.

Kaksi varoitusta. Istuntoasetus, joka levisi laajalti 20. lokakuuta, sulkee hyökkäysreittejä vain toisen haavoittuvuuden osalta, kuten eräs PHP:n tietoturvatiimin jäsen huomautti; ensimmäistä vastaan se ei auta lainkaan. Lisäksi memory_limit=-1 poistaa PHP:n oman muistikaton, joten yksittäinen raskas pyyntö voi nyt kuluttaa palvelimen muistin loppuun. Yhdistä se kontin tai cgroupin muistirajaan.

Verkkosovelluspalomuuri auttaa, vähän. Cloudflaren säännöt ovat oletuksena päällä kaikissa paketeissa, joihin sen WAF kuuluu, myös ilmaisessa, ja Palo Alto Networks sekä muut toimittajat ovat julkaisseet omia suojauksiaan. Cloudflare kehottaa silti asiakkaitaan paikkaamaan PHP:n ”WAF-suojauksista huolimatta”, ja se näki hyökkääjien muuttavan hyötykuormiaan livahtaakseen sen sääntöjen ohi. WAF suojaa myös vain sen kautta kulkevaa liikennettä. Jos palvelimesi vastaa omasta IP-osoitteestaan, hyökkääjä voi kiertää sen.

Jos mitään tästä ei saa tehtyä nopeasti, CISA, CERT-EU, NCSC ja EU:n yhteinen julkilausuma osoittavat kaikki samaan suuntaan: ota järjestelmä pois julkisesta internetistä, kunnes se on korjattu. Päivän huoltosivu maksaa vähemmän kuin uudelleen rakennettu palvelin.

Vaihe 4: tarkista, onko järjestelmiisi jo murtauduttu

Ikkuna avautui 20. lokakuuta, kun vuoto alkoi, ja hyökkäysliikennettä raportoitiin seuraavana aamuna. Jos järjestelmä oli tuona aikana tavoitettavissa ja paikkaamaton, paikkaus sulkee oven mutta ei kerro, ehtikö joku sisään ensin. NCSC pyytää kaikkia, jotka eivät pystyneet paikkaamaan heti, etsimään merkkejä tietomurrosta ja takaovista.

Mitä etsiä, julkaistujen ohjeiden ja tavanomaisen poikkeamienkäsittelyn käytäntöjen pohjalta:

PHP-prosesseja, jotka tekevät jotain, mitä PHP ei koskaan tee, kuten käynnistävät komentotulkin tai lataavat työkaluja (CISA).
Epätavallisia multipart-pyyntöjä, joita seuraa muistirajavirheitä tai toistuvia HTTP 500 -vastauksia, PHP:n worker-prosesseja, jotka käynnistyvät uudelleen ilman selvää syytä, sekä epätavallisen suuria tai virheellisiä PHPSESSID-evästeitä vastauksissa (Wiz).
Uusia tai muuttuneita PHP-tiedostoja latauskansioissa, välimuistikansioissa tai verkkopalvelimen juurihakemistossa, uusia ylläpitäjätilejä sisällönhallintajärjestelmässäsi ja ajastettuja tehtäviä, joita kukaan ei ole luonut.

Puhtaat lokit eivät ole todiste. PHP:n tiedote toisesta haavoittuvuudesta varoittaa juuri siitä, ja Wiz huomauttaa, että sovelluslokeissa voi olla vain vähän kontekstia.

Jos löydät jotain, käsittele sitä tietoturvapoikkeamana, älä paikkaustyönä. Eristä palvelin, säilytä todisteet, ota mukaan tietoturvapoikkeamien käsittelyyn erikoistunut palveluntarjoaja ja vaihda jokainen salaisuus, jonka verkkopalvelin pystyi lukemaan: tietokantojen salasanat, API-avaimet, maksu- ja sähköpostitunnukset, allekirjoitusavaimet. Koska toinen haavoittuvuus voi paljastaa muistin sisältöä, harkitse arkaluonteisimpien salaisuuksien vaihtamista jokaisella palvelimella, joka oli päiviä altistuneena ja paikkaamattomana, vaikka merkkejä tunkeutumisesta ei olisi.

Vaihe 5: mistä sinun on ehkä ilmoitettava

Haavoittuvuus ei sellaisenaan ole ilmoitettava poikkeama. Hyödynnetty haavoittuvuus voi olla.

NIS2: jos organisaatiosi kuuluu direktiivin piiriin ja tietomurto on merkittävä poikkeama, ennakkovaroitus kansalliselle CSIRT-yksikölle on tehtävä 24 tunnin kuluessa. Katso NIS2-oppaamme.
GDPR: jos henkilötietoihin on päästy käsiksi, valvontaviranomaiselle on ilmoitettava 72 tunnin kuluessa siitä, kun tietoturvaloukkaus on tullut tietoosi, ellei loukkauksesta todennäköisesti aiheudu riskiä ihmisille. Katso GDPR-oppaamme.
Cyber Resilience Act: jos myyt ohjelmistoa tai laitetta, jonka sisällä on PHP, olet sen valmistaja CRA:n tarkoittamassa mielessä. Valmistajien on 11. syyskuuta 2026 alkaen pitänyt ilmoittaa tuotteidensa aktiivisesti hyödynnetyistä haavoittuvuuksista CRA:n yhden ilmoitusalustan kautta, kuten EU:n yhteinen julkilausuma muistuttaa. Katso CRA-oppaamme.
Asiakkaasi: jos hostaat tai ylläpidät PHP:tä asiakkaillesi, he kysyvät. Lyhyt kirjallinen selvitys (mitä käytät, milloin se paikattiin, mitä tarkistit) riittää useimmille heistä, ja se on sama selvitys, jonka auditoija tai kybervakuuttaja haluaa nähdä.

Hätätilanteen jälkeen: mitä kannattaa muuttaa

Useimmilla hyvin ylläpidetyillä palvelimilla PHP2Shell paikataan muutamassa päivässä. Se, mitä haavoittuvuus paljasti ympäristöstäsi, pitää paikkansa sen jälkeenkin.

Tiedä, kuinka kauan paikkaaminen sinulta kestää. Tiedotteesta siihen, että jokainen palvelin on käynnistetty uudelleen: tunteja, päiviä vai viikkoja? Jos rehellinen vastaus on ”meidän pitäisi kysyä digitoimistolta”, korjaa se ennen seuraavaa kertaa. Kun tutkijat sanovat tekoälyn lyhentäneen heidän hyökkäyskoodityönsä kuukausista viikkoon, oleta, että hyökkääjätkin pystyvät etenemään samaa tahtia.
Säilytä juuri kokoamasi luettelo. Se oli reagoinnin vaikein osa, ja se vanhenee sillä hetkellä, kun kukaan ei vastaa siitä.
Luovu PHP-versioista, joiden elinkaari on päättynyt. Sivusto, joka toimi 7.4:llä tai 8.1:llä, tarvitsi tällä kertaa toimittajan tai lähdekoodiin tehdyn backport-korjauksen; ensi kerralla ei välttämättä ole kumpaakaan. PHP 8.2:n elinkaari päättyy 31. joulukuuta 2026, joten 8.1:stä luopuvan sivuston kannattaa siirtyä suoraan 8.3:een tai uudempaan. PHP:n vaihtaminen tarkoittaa usein myös sovelluksen päivittämistä: artikkelimme Drupalin, Umbracon ja Kenticon elinkaaren lopusta näyttää, mitä se tarkoittaa yhden sisällönhallintajärjestelmän kohdalla.
Suosi PHP-FPM:ää mod_php:n sijaan, kun voit. Se oli tällä kertaa pienemmän riskin kokoonpano.
Pidä latauksen edistymisen seuranta pois päältä, jos et käytä sitä. PHP:n tiedote ehdottaa, että session.upload_progress.enabled pidetään pois päältä paikkaamisen jälkeenkin, jos sovellus ei tarvitse sitä.
Kirjaa paikkausajat sopimuksiisi. Kysy hosting-palveluntarjoajaltasi ja digitoimistoltasi, kuinka nopeasti ne asentavat kriittiset PHP-korjaukset, ja pyydä vastaus kirjallisena.

Tarkistuslista tälle viikolle

Listaa jokainen PHP-asennus, myös kontit, hallintapaneelit, toimittajien tuotteet ja esituotantopalvelimet.
Paikkaa internetiin näkyvät järjestelmät ensin, alkaen Apachen mod_php:stä.
Käynnistä jokainen PHP-prosessi uudelleen ja tarkista versio, jonka verkkopalvelin ilmoittaa.
Rakenna konttikuvat uudelleen ja ota ne uudelleen käyttöön.
Jos et voi paikata tänään, ota käyttöön PHP:n väliaikaiset asetukset, ohjaa liikenne WAF:n kautta tai ota järjestelmä pois verkosta.
Pyydä toimittajilta ja hosting-palveluntarjoajilta kirjallisesti niiden PHP-versio ja paikkauspäivä.
Käy läpi lokit ja tiedostomuutokset kaikista järjestelmistä, jotka ovat olleet altistuneina ja paikkaamattomina 20. lokakuuta lähtien.
Päätä, koskeeko sinua ilmoitusvelvollisuus (NIS2, GDPR, CRA).
Suunnittele siirtyminen pois PHP 8.1:stä ja vanhemmista sekä pois 8.2:sta ennen 31. joulukuuta.

Missä voimme auttaa

Useimmilta yrityksiltä ei puutu halua paikata. Niiltä puuttuu selkeä kuva siitä, mitä niillä on käytössä, tai ihmiset, jotka tekevät työn tällä viikolla. Sen osan me otamme hoitaaksemme:

Kartoitus ja paikkaus päivissä. Etsimme PHP-asennuksesi palvelimilta, konteista, hosting-paneeleista ja toimittajiltasi, paikkaamme ne, käynnistämme uudelleen ja varmistamme tuloksen sekä jätämme sinulle kirjallisen selvityksen siitä, mitä tehtiin ja milloin. Sama selvitys on myös vastauksesi asiakkaille ja auditoijille.
Pois vanhasta PHP:stä. Sovellukset, jotka ovat jumissa PHP 7.x:ssä, 8.0:ssa tai 8.1:ssä, koska koodi ei toimi millään uudemmalla: siirrämme ne tuettuun versioon vanhojen järjestelmien ylläpitopalvelussamme.
Koventaminen ja paikkausrutiini, jotta seuraava tiedote on aikataulutettu työ eikä hätätilanne.

Jos löydät merkkejä murrosta, ota ensin yhteyttä tietoturvapoikkeamien käsittelyyn erikoistuneeseen palveluntarjoajaan. Me voimme hoitaa uudelleenrakentamisen ja versiopäivityksen sen rinnalla.

Kirjoita osoitteeseen office@c9group.dev ja kerro, mitä sinulla on käytössä, niin vastaamme, mitä tekisimme ensimmäiseksi.

Lähteet

Tarkistettu 22. lokakuuta 2026. Tilanne kehittyy yhä: erityisesti hyödyntämistilanne ja toimittajien paketit ovat voineet muuttua sen jälkeen.

PHP-projekti

Viranomaiset

Tutkijat, toimittajat ja tilastot