# PHP pilvi- ja PaaS-palveluissa: kuka korjaa ajoympäristön?

> PHP-päivitys PaaS- ja pilvialustoilla: kuka korjaa PHP-ajoympäristön, miksi usein tarvitaan uusi build ja miten todistatte käytössä olevan version.

Lähde: https://phpsos.de/fi/blog/paas-php-laufzeit/  
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:** Pilvi- ja PaaS-toimittajilla korjausta ei tee automaattisesti toimittaja. Jos se hallinnoi PHP-ajoympäristöä, se päivittää sen, mutta usein vasta seuraavan deploymentin yhteydessä. Jos rakennatte kuvat tai buildit itse tai ylläpidätte alustaa itse, teidän on rakennettava ja otettava käyttöön uudelleen. Ratkaisevaa on aina ajoympäristö, jota verkkosivustonne juuri nyt palvelee.

## PHP-päivitys PaaS:ssä: kenelle ajoympäristö kuuluu?

Alustapalvelut, ammattikielellä PaaS (Platform as a Service), vapauttavat yritykset palvelimen ylläpidosta. Lataatte koodin, alusta rakentaa ja ylläpitää sen. PHP2Shellin kohdalla tästä syntyy tyypillinen epävarmuus: kenen vastuulla PHP:n päivitys oikeastaan on?

Vercel tiivistää PHP2Shell-tiedotteessaan asian: paikallisen kehitysympäristön, sovelluskoodin tai liitännäisten päivitys ei riitä. Ratkaisevaa on sen deploymentin PHP-ajoympäristö, joka todella vastaa pyyntöihin. Se, onko tämä ajoympäristö korjattu, riippuu siitä, kuka sen tarjoaa ja milloin se on viimeksi rakennettu.

## Neljä toimintamallia vertailussa

Toimittajien nimitykset vaihtelevat. Korjauskysymyksen kannalta useimmat tarjoukset voi sijoittaa johonkin näistä malleista:

| Malli | Kuka päivittää PHP:n? | Mitä Teidän on tehtävä |
|---|---|---|
| Toimittajan hallinnoima ajoympäristö | Toimittaja | Pyytäkää vahvistus, tarvittaessa uusi deployment, jotta uusi ajoympäristö tulee käyttöön |
| Build-pohjainen ajoympäristö (buildpack) | Toimittaja tarjoaa uuden version, Teidän buildinne lukitsee sen | Käynnistäkää uusi build, tarkistakaa versio build-lokista |
| Oma konttikuva | Te | Rakentakaa kuva korjatulla PHP:llä uudelleen ja ottakaa käyttöön |
| Itse ylläpidetty alusta | Te, alustalle ja sovelluksille | Korjatkaa alusta ja jokainen sovellus erikseen |

Monet yritykset käyttävät useita malleja samanaikaisesti, esimerkiksi hallinnoitua ajoympäristöä verkkosivustolle ja omia kontteja sisäisille työkaluille. Jokainen sovellus tarvitsee siksi oman vastauksensa.

Ansa piilee sanassa ”hallinnoitu”. Vaikka toimittaja huoltaa ajoympäristöä, jo käyttöön otettu sovellus toimii usein edelleen sillä tilalla, jolla se rakennettiin. Uusi versio tulee voimaan vasta seuraavan buildin tai deploymentin yhteydessä. Jotkin alustat pitävät lisäksi vanhempia deploymenteja tai esikatseluympäristöjä tavoitettavissa omilla osoitteillaan. Kysykää siksi, ei vain onko toimittaja korjannut, vaan myös mistä lähtien käynnissä olevat instanssinne käyttävät korjausta ja mitä vanhoille deploymenteille tapahtuu.

## Mitä Vercel ja Coolify sanovat PHP2Shellistä

Kaksi toimittajaa on julkistanut ohjeensa. Ne ovat opettavaisia, koska ne nimeävät selvästi omien suojatoimiensa rajat.

**Vercel** on oman tiedotteensa mukaan aktivoinut ennen julkistusta suojasääntöjä Web Application Firewallissaan (WAF), verkkopyyntöjen suodattimessa. Ne pätevät automaattisesti PHP-funktioihin Vercelissä ja pyyntöihin, jotka Vercel välittää ulkoisille PHP-palvelimille. Samalla Vercel vaatii päivittämään PHP-ajoympäristön välittömästi korjattuun versioon. Konttideploymentit tulee rakentaa uudelleen päivitetyllä PHP-peruskuvalla ja ottaa käyttöön. Pyyntöjä, jotka ohittavat Vercelin ja menevät suoraan ulkoiselle PHP-palvelimelle, WAF ei kata.

**Coolify**, itse ylläpidettävä alusta, oli oman tiedotteensa mukaan itse haavoittuva: kaikki version 4 haarat. Ensimmäisiksi korjatuiksi tiloiksi Coolify mainitsee 4.0.1, 4.1.3, 4.2.1, 4.3.24 ja 4.4.7 ja suosittelee versiota 4.4.7. Tärkeä on lisähuomautus: Coolify-päivitys ei päivitä PHP-sovelluksia, joita sen kautta ajatte. Niiden ajoympäristöt tai kuvat on päivitettävä erikseen ja rakennettava tai otettava käyttöön uudelleen. Tämä pätee Coolifyn mukaan myös Coolify Cloudin asiakkaille ja myös Cloudflaren takana, koska Cloudflaren säännöt tarkistavat vain Cloudflaren kautta kulkevaa liikennettä.

Mitä Cloudflaren säännöt saavat aikaan, sijoittaa asiayhteyteensä artikkeli [Cloudflaren suojasäännöt PHP2Shelliä vastaan](https://phpsos.de/fi/blog/cloudflare-waf-php2shell/).

## Näin tarkistatte käytössä olevan ajoympäristön

Seuraavat vaiheet toimivat toimittajasta riippumatta. Ne tähtäävät todisteeseen, eivät tuntemukseen.

1. **Luetteloikaa kaikki ympäristöt:** tuotanto, staging, esikatselu-deploymentit ja taustapalvelut kuten jonotyöläiset. Jokaisella ympäristöllä voi olla eri ajoympäristö.
2. **Lukekaa ajoympäristön versio ympäristökohtaisesti:** toimittajan konsolista, build-lokista tai projektin konfiguraatiotiedostosta.
3. **Tarkistakaa viimeisen deploymentin päivämäärä:** Jos se on ennen 21.10.2026, käytössä on suurella todennäköisyydellä yhä vanha ajoympäristö, ellei toimittaja nimenomaisesti vahvista muuta.
4. **Katsokaa käynnissä olevasta instanssista:** Jos alusta tarjoaa konsolin, seuraava komento näyttää instanssin version.
5. **Ottakaa mukaan ulkoiset PHP-palvelimet:** Palvelimet, joille alusta välittää pyyntöjä, tarvitsevat oman päivityksensä, eikä niiden pitäisi olla suoraan tavoitettavissa internetistä.

```bash
# Käynnissä olevan instanssin konsolissa (jos toimittaja tarjoaa)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
```

Odotettuja ovat 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai toimittajan vahvistama backport. Huomatkaa, ettei instanssin komentorivi aina käytä samaa ajoympäristöä kuin verkkoprosessi. Älkää luoko tarkistusta varten julkisesti tavoitettavaa phpinfo-tiedostoa. Miten versionumero ja backport-tila tulkitaan oikein, kuvaa [PHP-version ja korjaustilan tarkistus](https://phpsos.de/fi/php2shell/php-version-pruefen/).

> **Tärkeää:**
> Uusi deployment ei poista haittaohjelmaa, joka on ehtinyt aiemmin päätyä pysyviin tallennuspaikkoihin, kuten upload-volyymeihin tai tietokantaan. Nämä alueet tarkistatte erikseen.

## Kirjatkaa vastuu kirjallisesti

PHP2Shell osoittaa, kuinka epäselvä raja alustan ja asiakkaan välillä usein on. Kirjatkaa jokaisesta sovelluksesta ylös, kuka tarjoaa ajoympäristön, kuka rakentaa uudelleen tietoturvailmoitusten yhteydessä ja miten toimittaja ilmoittaa korjauksista. Siihen kuuluu myös se, kenellä on pääsy alustan konsoliin kiireessä ja kuka saa käynnistää uuden buildin toimistoaikojen ulkopuolella.

Omaan dokumentaatioonne riittää lyhyt taulukko sovellusta kohti: alusta, toimintamalli, PHP-haara, viimeisen buildin päivämäärä, vastuuhenkilö. Kun tämä luettelo on seuraavan ilmoituksen aikana käsillä, säästytte päiviltä, jotka monet tiimit käyttivät 21. lokakuuta jälkeen etsimiseen. Konttisovelluksissa siihen kuuluu myös se, kuka ylläpitää peruskuvaa; taustoja selittää [PHP konteissa](https://phpsos.de/fi/php/php-in-containern/).

Hallinnoiduille palvelimille, joilla ei ole PaaS-luonnetta, pätevät samankaltaiset kysymykset, jotka olemme koonneet sivulle [Hallinnoitu palvelin: vastuun selkeyttäminen](https://phpsos.de/fi/server/managed-server/).

## Miten PHP SOS auttaa konkreettisesti?

- **Yhdistäminen:** Sijoitamme jokaisen sovelluksenne johonkin toimintamalliin ja selvitämme, kuka tarjoaa PHP-ajoympäristön.
- **Todistaminen:** Tarkistamme ajoympäristön, build-päivämäärän ja deploymentin ympäristökohtaisesti ja dokumentoimme tuloksen.
- **Rakentaminen ja käyttöönotto uudelleen:** [PHP-päivityspalvelun](https://phpsos.de/fi/leistungen/php-patch-service/) kautta päivitämme kuvat ja buildit ja otamme ne käyttöön hallitusti.
- **Aukkojen sulkeminen:** Tarkistamme, ovatko ulkoiset PHP-palvelimet suoraan tavoitettavissa, ja rajaamme pääsyn.


## Usein kysytyt kysymykset

**Korjaako PaaS-toimittajani PHP:n automaattisesti?**  
Se riippuu mallista. Jos toimittaja hallinnoi ajoympäristöä, se päivittää sen, mutta usein vasta uusille deploymenteille. Jos rakennatte kuvat tai buildit itse, teidän on rakennettava ja otettava käyttöön uudelleen. Pyytäkää vahvistus sovelluksenne tilasta.

**Riittääkö alustatoimittajani WAF PHP2Shelliä vastaan?**  
Ei. Vercel ja Coolify kirjoittavat nimenomaisesti, etteivät suojasäännöt korvaa PHP-ajoympäristön päivitystä. Lisäksi ne vaikuttavat vain alustan kautta kulkevaan liikenteeseen.

**Pitääkö korjauksen jälkeen tehdä uusi deployment?**  
Usein kyllä. Vercel mainitsee konttideploymenteille rakentamisen uudelleen päivitetyllä PHP-peruskuvalla ja uuden deploymentin. Build-pohjaisilla alustoilla ajoympäristö lukitaan buildin yhteydessä; vasta uusi build ottaa korjauksen käyttöön.

**Käytän Coolifyta. Riittääkö Coolify-päivitys?**  
Ei. Coolifyn tietoturvatiedotteen mukaan päivitys päivittää vain Coolifyn itsensä. Sovellustenne PHP-ajoympäristöt tai konttikuvat on päivitettävä erikseen ja rakennettava tai otettava käyttöön uudelleen.

## Lähteet

- [Vercel: PHP2Shell Security Bulletin](https://vercel.com/kb/bulletin/php2shell-security-bulletin)
- [Coolify: PHP Security Advisory 2026](https://coolify.io/docs/knowledge-base/php-security-advisory-2026)
- [php.net: tietoturvailmoitukset](https://www.php.net/)