Kort sagt: Det officielle PHP-image på Docker Hub findes i mange tags, der kombinerer version, variant (f.eks. cli, fpm, apache) og basissystem. Et tag er en pegepind, der efter genopbygninger flytter sig til nye statusser; kun digestet betegner præcis én status. Mod PHP2Shell har I brug for et image med PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, kontrolleret med php -v, og en genopbygning af jeres egne images på det.
Hvorfor tagget alene afslører lidt
Mange teams skriver en linje som FROM php:8.3-fpm i deres Dockerfile og glemmer den så. Det fungerer, så længe ingen spørger, hvilken PHP-version der egentlig kører. Siden PHP2Shell spørger alle.
Svaret står ikke i Dockerfilen. Et tag som 8.3-fpm peger på hentningstidspunktet på den nyeste status for denne gren. Blev imaget hentet før den 21. oktober og siden ikke fornyet, indeholder det en sårbar version, selv om tagget i dag peger på en rettet status. Ifølge retningslinjerne for Docker Official Images bliver imagene aktivt bygget om, også ved sikkerhedsrettelser. Jeres lokale status berøres dog ikke af det.
Hele forløbet fra genopbygningen til den nyoprettede container beskriver Patch PHP i Docker-containere. Her handler det om det forudgående spørgsmål: Hvilket image er det rigtige, og hvordan dokumenterer I dets status?
PHP Docker-image-tags: Sådan er de opbygget
Tagsene er sammensat af op til tre dele. Docker Hub viser eksempler som php:8.2-cli, php:8.2-fpm-alpine eller php:8.4.27-zts-alpine3.24.
| Bestanddel | Eksempel | Betydning |
|---|---|---|
| Versionsangivelse | 8.4.27 eller 8.4 |
fuld version bliver ved denne status, grenangivelsen flytter sig med nye patches |
| Variant | cli, fpm, apache, zts |
PHP's driftsform i containeren |
| Basissystem | alpine3.24, bookworm, trixie |
den underliggende Alpine- eller Debian-version |
Varianterne er ikke ligeværdige ved PHP2Shell. fpm driver PHP-FPM, apache driver PHP som Apache-modul, altså mod_php. Denne driftsform vurderer PHP-teamet højest, fordi der dér er vist en exploit, før applikationskode overhovedet kører. Mere herom under Hvorfor mod_php er særligt udsat. Varianten cli er tænkt til kommandolinjeopgaver.
Også basissystemet har konsekvenser. Alpine-images er små, men bruger et andet C-bibliotek end Debian-images; nogle udvidelser eller prækompilerede biblioteker opfører sig dér anderledes. Skift derfor ikke basissystem i forbifarten med sikkerhedsopdateringen, men bliv først ved det, som jeres applikation kender.
Vigtigt at forstå: I det officielle image stammer PHP ikke fra basisdistributionens pakker. Docker Hub beskriver, at PHP-kilderne ligger i imaget, og at udvidelser bygges ind via hjælpescripts som docker-php-ext-install. En pakkeopdatering af basissystemet i jeres egen Dockerfile ændrer derfor intet ved PHP-versionen. Afgørende er alene, på hvilken status af det officielle image I bygger.
Tag eller digest: Hvad der ændrer sig hvornår
Et digest er en kontrolsum over indholdet af et image, skrevet som sha256: med en lang tegnfølge. Det ændrer sig med hver genopbygning. Derved egner det sig som bevis: Den, der kender digestet, ved præcis, hvilken status der kører.
I praksis har en arbejdsdeling vist sig at fungere:
- I Dockerfilen bruges gren-tagget, f.eks.
php:8.4-fpm, så en genopbygning automatisk får den nyeste patch i denne gren. - Ved udrulningen bruges digestet for det færdigbyggede egne image, så det er entydigt, hvad der leveres.
- I dokumentationen noteres begge dele: tag, digest og den version, der er kontrolleret med
php -v.
Den, der i stedet fastlåser et fuldt versionstag som 8.3.35-fpm, får aldrig automatisk en patch. Det kan være ønsket, men kræver en proces, der hæver tagget ved hver sikkerhedsmeddelelse.
PHP2Shell: Kontrollér et image før brug
Følgende kommandoer henter et image og læser oplysninger ud. De ændrer ingen kørende containere.
# Hent den aktuelle status for gren-tagget
docker pull php:8.4-fpm
# Hvilken PHP-version er der i imaget?
docker run --rm php:8.4-fpm php -v
# Vis digestet for det hentede image
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Forespørg digest og platforme direkte i registryet
docker buildx imagetools inspect php:8.4-fpm
Forespørgslen med imagetools viser ved multi-platform-images et overordnet digest og derunder et eget pr. platform, f.eks. linux/amd64 eller linux/arm64. Dokumentér det digest, som jeres servere faktisk henter, og vær opmærksom på, at udviklercomputere med en anden arkitektur får et andet platform-digest.
Viser php -v ikke mindst den rettede version af grenen, er imaget forældet eller kommer fra et mellemlager. Kontrollér så, om jeres miljø bruger et registry-spejl, der leverer gamle statusser.
Til PHP 8.1 og ældre leverer PHP-projektet ingen officielle releases længere. Et officielt image af disse grene kan derfor ikke indeholde en regulær rettet version. Tags, der ikke længere vedligeholdes, forbliver ifølge Docker-retningslinjerne tilgængelige, men opdateres ikke mere.
Imaget medbringer ifølge Docker Hub php.ini-development og php.ini-production og anbefaler indtrængende produktionsudgaven til produktiv drift. Egne indstillinger lægger I som fil i $PHP_INI_DIR/conf.d/, også overgangsværdierne fra php.net.
Typiske fejl ved valg af image
- Variant af vane: apache-varianten vælges, fordi den starter enkelt, selv om fpm med separat webserver var mulig.
- Ingen genopbygning af egne images: Basisimaget er aktuelt, det deraf byggede applikationsimage er det ikke.
- Flertrinsbuilds overset: I en Dockerfile med flere
FROM-linjer tilpasses kun én. - Biimages glemt: Workers, cron-containere og administrationsværktøjer bruger egne tags.
- Kun sat på
latest: Tagget siger intet om gren og variant og kan ved en ny hovedgren springe uventet.
Hvordan I automatiserer genopbygninger, så et forældet image slet ikke kører længe, beskriver CI/CD: Byg PHP-images automatisk om. Grundlaget for PHP i containere forklarer PHP i containere.
Hvordan hjælper PHP SOS konkret?
- Kontrollér bestanden: Vi læser ud, hvilke tags, digests og PHP-versioner der sidder i jeres images og kørende containere.
- Vurdér varianten: Vi kontrollerer, om mod_php er nødvendig, eller om fpm med separat webserver sænker risikoen.
- Byg om og dokumentér: Med PHP-patchservice bygger vi images om på rettet basis og dokumenterer tag, digest og version.
- Forankr processen: Vi indretter Dockerfiles og udrulninger, så den næste patch kan planlægges.
Ofte stillede spørgsmål
Hvad er forskellen på tag og digest?
Et tag som php:8.4-fpm er et navn, der efter hver genopbygning kan pege på en ny status. Et digest er en kontrolsum, der betegner præcis én uforanderlig status. Til dokumentation og reproducerbare udrulninger er digestet den mere pålidelige angivelse.
Hvilket tag indeholder PHP2Shell-rettelsen?
Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Et tag med fuldt versionsnummer viser statussen direkte. Ved kortere tags som 8.4-fpm kontrollerer I efter hentningen med php -v, hvilken version der faktisk er indeholdt.
Findes der et patchet officielt image til PHP 8.1?
PHP-projektet leverer ingen officielle releases til 8.1 og ældre. Et officielt image af disse grene kan derfor ikke indeholde en regulær rettet version. Planlæg skiftet til en understøttet gren.
Er apache-varianten mere risikabel end fpm?
apache-varianten driver PHP som Apache-modul, altså mod_php. Denne driftsform vurderer PHP-teamet højest ved PHP2Shell. Begge varianter kræver opdateringen; ved mod_php er hastværk særligt påkrævet.