# PHP:n korjaus Docker-konteissa

> PHP Docker -imagen päivitys PHP2Shelliä vastaan: tarkista versio kontissa, rakenna image uudelleen, luo kontit uudelleen ja aseta ylimenoarvot oikein.

Lähde: https://phpsos.de/fi/php2shell/docker-container-patchen/  
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:** PHP Docker -imagen päivitys on PHP2Shellin osalta pakollinen, eikä se tapahdu itsestään. Teidän on rakennettava tai haettava image korjatulla PHP-versiolla, luotava jokainen kontti siitä uudelleen ja tarkistettava, että käynnissä olevassa kontissa toimii 8.5.12, 8.4.27, 8.3.36 tai 8.2.35. Kontin pelkkä uudelleenkäynnistys ei riitä.

## Miksi kontit eivät ole automaattisesti turvallisia

Docker-image on jäädytetty hetkikuva. Sen sisällä oleva PHP pysyy siinä tilassa, jossa se oli rakennettaessa, vaikka isännälle olisi jo pitkään asennettu päivityksiä. Isäntäjärjestelmän pakettipäivitys ei muuta kontin PHP:tä miksikään.

Lisäksi on tyypillisiä sudenkuoppia: kuukausia sitten rakennetut imaget, joihin ei ole sen jälkeen koskettu, pohjaimaget kiinteällä tagilla kuten `php:8.3.35-fpm`, paikalliset välimuistit, jotka käyttävät rakennettaessa vanhaa pohjaimagea uudelleen, ja kontit, jotka on käynnistetty uudelleen mutta ei koskaan luotu uudelleen. Haavoittuvia ovat kaikki konteissa yleiset ajotavat: PHP-FPM, Apache mod_php:n kanssa ja FrankenPHP.

Lisäksi on vastuukysymys. Monessa yrityksessä toimisto tai kehittäjä on rakentanut imagen kerran, mutta sitä ylläpitää sisäinen IT tai hosting-yritys. Silloin kukaan ei tunne olevansa vastuussa imagen PHP-tilasta. Selvittäkää siksi ensin, kuka imagen rakentaa, missä Dockerfile sijaitsee ja kuka saa viedä uusia imageja tuotantoon.

## PHP-version tarkistus kontissa

Tarkistakaa käynnissä oleva kontti, älkää vain Dockerfilea. Komennot ovat pelkästään lukevia.

```bash
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}"
docker exec <container> php -v
docker exec <container> php -i | grep -E "^PHP Version|Server API"
docker image inspect <image> --format "{{.Created}}"
```

Jos image käyttää jakelupaketteja virallisten PHP-buildien sijaan, tarkistakaa paketin tila kontissa. Pakettien nimet vaihtelevat pohjajakelun mukaan:

```bash
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
```

Jakelupaketeissa backport voi olla asennettuna, vaikka versionumero pysyy vanhana. Silloin ratkaisee paketin muutosloki. Viralliset PHP-imaget sen sijaan tuovat PHP:n yleensä itse käännettynä; niissä `php -v`:n versionumero on ratkaiseva arvo. Miten backportit tunnistetaan, kuvataan sivulla [PHP-version ja korjaustilan tarkistaminen oikein](https://phpsos.de/fi/php2shell/php-version-pruefen/).

## PHP Docker -imagen päivitys: uudelleenrakennus ja käyttöönotto

**Oma image PHP-imagen pohjalta:** hakekaa pohjaimage uudelleen ja rakentakaa ilman välimuistia.

```bash
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # tarkista versio ennen käyttöönottoa
```

**Docker Composella:** hakekaa tai rakentakaa imaget ja luokaa kontit uudelleen.

```bash
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
```

Tarkistakaa sen jälkeen uudelleen komennolla `docker exec <container> php -v`, toimiiko uusi versio. Jos kontilla on kiinteä versiotagi Dockerfilessa, esimerkiksi `FROM php:8.3.35-fpm`, tagi on nostettava. Haaran tagi kuten `php:8.3-fpm` saa uudet korjaustilat, mutta vain jos haette uudelleen.

Pitäkää edellinen image valmiina, kunnes uusi versio on testattu. Virheen sattuessa voitte näin palata takaisin ilman että sovellus on pitkään offline-tilassa. Vanha image sisältää kuitenkin jälleen haavoittuvan PHP:n; paluutie on siksi vain lyhyeksi ajaksi ja väliaikaisten toimenpiteiden kanssa perusteltavissa.

Kubernetesia käyttävä vie uuden imagen tuotantoon Deploymentin kautta. Yksityiskohdat löytyvät sivulta [PHP:n korjaus Kubernetesissa](https://phpsos.de/fi/server/kubernetes/). FrankenPHP-imageille pätee sama menettely; vihjeitä ajotavasta löydätte sivulta [FrankenPHP turvalliseksi](https://phpsos.de/fi/server/frankenphp/).

> **Tärkeää:**
> Älkää unohtako sivukontteja: cron- ja jonotyöntekijät, ylläpitotyökalut tai staging-ympäristöt käyttävät usein samaa PHP-imagea mutta toimivat omissa konteissaan. Jokainen niistä on luotava uudelleen.

## Ylimenotoimenpiteet kontissa

Jos päivitys ei vielä onnistu, php.netin väliaikaiset toimenpiteet pätevät myös kontissa. Ne eivät ole täysi suoja. Muistiraja kuuluu tässä kontille, sillä php.net suosittelee sitä kontin tai cgroupin kautta, ei `RLIMIT_AS`- tai `RLIMIT_DATA`-rajoilla:

```ini
; esim. tiedostona imagessa: /usr/local/etc/php/conf.d/zz-uebergang.ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0
```

```bash
docker run --memory=1g ...         # tai Composessa: deploy.resources.limits.memory
```

Arvon sovitatte sovellukseenne. Huolehtikaa, ettei sovellus voi itse ylikirjoittaa `memory_limit`-arvoa; PHP-FPM:ssä asetatte arvot sitä varten poolissa `php_admin_value`:lla. Uusi konfiguraatio tehoaa vasta, kun kontti on luotu tai käynnistetty uudelleen; uudelleenkäynnistyksen taustat kuvataan sivulla [PHP-FPM ja kaikkien workerien uudelleenkäynnistys](https://phpsos.de/fi/php2shell/php-fpm-neustart/).

## Jotta seuraavalla kerralla se sujuu nopeammin

- Rakentakaa imaget uudelleen säännöllisesti ja automaattisesti, ei vain koodimuutosten yhteydessä.
- Käyttäkää pohjaimageja haaratagilla ja versioikaa rakennettu tila päivämäärällä tai digestillä.
- Tarkistuttakaa imaget tunnettujen haavoittuvuuksien varalta ennen käyttöönottoa ja ajakaa kontit ilman root-oikeuksia.
- Pitäkää inventaariota siitä, mikä kontti käyttää mitäkin imagea.

## Miten PHP SOS auttaa konkreettisesti?

- **Nykytilan kartoitus:** Tarkistamme kaikki käynnissä olevat kontit, niiden imaget ja PHP-versiot, myös sivukontit ja stagingin.
- **Uudelleenrakennus ja käyttöönotto:** [PHP-korjauspalvelun](https://phpsos.de/fi/leistungen/php-patch-service/) kautta rakennamme imaget korjatulla versiolla ja luomme kontit uudelleen hallitusti.
- **Ylimenon suojaus,** kun päivitys riippuu sovelluksesta: php.netin arvot, muistiraja kontille.
- **Jatkuva valvonta:** [Tietoturvavalvonnalla](https://phpsos.de/fi/leistungen/security-monitoring/) pidämme imagetilat ja konttien poikkeavan käytöksen silmällä.


## Usein kysytyt kysymykset

**Riittääkö docker restart päivityksen jälkeen?**  
Ei. docker restart käynnistää kontin uudelleen samalla vanhalla imagella. Teidän on rakennettava tai haettava uusi image ja luotava kontti siitä uudelleen, esimerkiksi komennolla docker compose up -d --force-recreate.

**Sisältääkö virallinen PHP-image jo korjatun version?**  
Sen tarkistatte parhaiten suoraan: hakekaa image uudelleen ja ajakaa siinä php -v. Odotettavissa on 8.5.12, 8.4.27, 8.3.36 tai 8.2.35. Jos image näyttää vanhemman numeron, sitä ei ole vielä päivitetty tai se tulee välimuistista.

**Onko PHP kontissa vähemmän vaarassa kuin isännällä?**  
Haavoittuvuus tehoaa kontissa täsmälleen samoin. Hyvin rakennettu kontti voi rajoittaa murron seurauksia, esimerkiksi käyttäjällä ilman root-oikeuksia ja kirjoitussuojatulla tiedostojärjestelmällä. Korjausta se ei korvaa.

## Lähteet

- [php.net: tietoturvatiedotteet](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)