PHP:n korjaus Docker-konteissa

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.

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:

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.

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

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

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.

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. FrankenPHP-imageille pätee sama menettely; vihjeitä ajotavasta löydätte sivulta FrankenPHP turvalliseksi.

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:

; 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

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.

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 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 pidämme imagetilat ja konttien poikkeavan käytöksen silmällä.

Usein kysytyt kysymykset

Lähteet

• php.net: tietoturvatiedotteet
• PHP 8 ChangeLog
• OWASP Cheat Sheets