Kort sagt: Den officiella PHP-imagen på Docker Hub finns i många taggar som kombinerar version, variant (till exempel cli, fpm, apache) och bassystem. En tagg är en pekare som flyttas till nya nivåer efter ombyggnader; bara digesten anger exakt en nivå. Mot PHP2Shell behöver ni en image med PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, kontrollerad med php -v, och en ombyggnad av era egna images på den.
Varför taggen ensam säger lite
Många team skriver en rad som FROM php:8.3-fpm i sin Dockerfile och glömmer den sedan. Det fungerar så länge ingen frågar vilken PHP-version som egentligen körs. Sedan PHP2Shell frågar alla.
Svaret står inte i Dockerfilen. En tagg som 8.3-fpm pekar vid hämtningstillfället på den senaste nivån i den grenen. Hämtades imagen före den 21 oktober och har inte förnyats sedan dess innehåller den en sårbar version, trots att taggen i dag pekar på en rättad nivå. Enligt riktlinjerna för Docker Official Images byggs imagerna aktivt om, även vid säkerhetsrättningar. Er lokala nivå påverkas dock inte av det.
Hela förloppet från ombyggnad till ny container beskrivs i Patcha PHP i Docker-containrar. Här handlar det om den inledande frågan: vilken image är rätt, och hur styrker ni dess nivå?
PHP Docker image-taggar: så är de uppbyggda
Taggarna består av upp till tre delar. Docker Hub visar exempel som php:8.2-cli, php:8.2-fpm-alpine eller php:8.4.27-zts-alpine3.24.
| Del | Exempel | Betydelse |
|---|---|---|
| Versionsuppgift | 8.4.27 eller 8.4 |
fullständig version stannar vid den nivån, grenuppgiften flyttas med nya patchar |
| Variant | cli, fpm, apache, zts |
PHP:s driftläge i containern |
| Bassystem | alpine3.24, bookworm, trixie |
underliggande Alpine- eller Debian-version |
Varianterna är inte likvärdiga för PHP2Shell. fpm kör PHP-FPM, apache kör PHP som Apache-modul, alltså mod_php. Det driftläget bedömer PHP-teamet som högst, eftersom en exploit har visats där innan någon applikationskod ens körs. Mer därom under Varför mod_php är särskilt utsatt. Varianten cli är avsedd för kommandoradsuppgifter.
Även bassystemet har följder. Alpine-images är små men använder ett annat C-bibliotek än Debian-images; vissa tillägg eller förkompilerade bibliotek beter sig annorlunda där. Byt därför inte bassystem i förbigående med säkerhetsuppdateringen, utan stanna först vid det som er applikation känner till.
Viktigt för förståelsen: i den officiella imagen kommer PHP inte från bassystemets distributionspaket. Docker Hub beskriver att PHP-källkoden ligger i imagen och att tillägg byggs in med hjälpskript som docker-php-ext-install. En paketuppdatering av bassystemet i den egna Dockerfilen ändrar därför ingenting i PHP-versionen. Avgörande är enbart på vilken nivå av den officiella imagen ni bygger.
Tagg eller digest: vad som ändras när
En digest är en kontrollsumma över en images innehåll, skriven som sha256: följt av en lång teckensträng. Den ändras vid varje ombyggnad. Därför lämpar den sig som bevis: den som känner till digesten vet exakt vilken nivå som körs.
I praktiken har en arbetsfördelning visat sig fungera:
- I Dockerfilen använder ni grentaggen, till exempel
php:8.4-fpm, så att en ombyggnad automatiskt får den senaste patchen i grenen. - I utrullningen använder ni digesten för den färdigbyggda egna imagen, så att det är entydigt vad som levereras.
- I dokumentationen noterar ni båda: tagg, digest och den version som kontrollerats med
php -v.
Den som i stället låser en fullständig versionstagg som 8.3.35-fpm får aldrig någon patch automatiskt. Det kan vara avsiktligt, men kräver en process som höjer taggen vid varje säkerhetsmeddelande.
PHP2Shell: kontrollera en image före användning
Kommandona nedan hämtar en image och läser ut information. De ändrar inga körande containrar.
# Hämta aktuell nivå för grentaggen
docker pull php:8.4-fpm
# Vilken PHP-version finns i imagen?
docker run --rm php:8.4-fpm php -v
# Visa digesten för den hämtade imagen
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Fråga digest och plattformar direkt i registret
docker buildx imagetools inspect php:8.4-fpm
Förfrågan med imagetools visar vid multiplattformsimages en överordnad digest och under den en egen per plattform, till exempel linux/amd64 eller linux/arm64. Dokumentera den digest som era servrar faktiskt hämtar, och observera att utvecklardatorer med annan arkitektur får en annan plattformsdigest.
Visar php -v inte åtminstone den rättade versionen i grenen är imagen föråldrad eller kommer från ett mellanlager. Kontrollera då om er miljö använder en registerspegel som levererar gamla nivåer.
För PHP 8.1 och äldre levererar PHP-projektet inga officiella releaser längre. En officiell image för dessa grenar kan därför inte innehålla en vanlig rättad version. Taggar som inte längre underhålls förblir enligt Dockers riktlinjer tillgängliga, men uppdateras inte längre.
Imagen levereras enligt Docker Hub med php.ini-development och php.ini-production och rekommenderar starkt produktionsvarianten för produktiv drift. Egna inställningar lägger ni som fil i $PHP_INI_DIR/conf.d/, även övergångsvärdena från php.net.
Typiska fel vid val av image
- Variant av gammal vana: apache-varianten väljs eftersom den startar enkelt, fast fpm med separat webbserver vore möjligt.
- Ingen ombyggnad av de egna imagerna: Basimagen är aktuell, applikationsimagen som byggts på den är det inte.
- Flerstegsbyggen förbisedda: I en Dockerfile med flera
FROM-rader justeras bara en. - Sidoimages glömda: Workers, cron-containrar och administrationsverktyg använder egna taggar.
- Förlita sig enbart på
latest: Taggen säger ingenting om gren och variant och kan oväntat hoppa vid en ny huvudgren.
Hur ni automatiserar ombyggnader så att en föråldrad image inte ens kör länge beskrivs i CI/CD: bygg om PHP-images automatiskt. Grunderna om PHP i containrar förklaras i PHP i containrar.
Hur hjälper PHP SOS konkret?
- Kontrollera beståndet: Vi läser ut vilka taggar, digests och PHP-versioner som finns i era images och körande containrar.
- Bedöma varianten: Vi kontrollerar om mod_php behövs eller om fpm med separat webbserver sänker risken.
- Bygga om och styrka: Med PHP-patchtjänsten bygger vi om images på rättad bas och dokumenterar tagg, digest och version.
- Förankra processen: Vi sätter upp Dockerfiler och utrullningar så att nästa patch kommer fram planerat.
Vanliga frågor
Vad är skillnaden mellan tagg och digest?
En tagg som php:8.4-fpm är ett namn som kan peka på en ny nivå efter varje ombyggnad. En digest är en kontrollsumma som anger exakt en oföränderlig nivå. För bevis och reproducerbara utrullningar är digesten den mer tillförlitliga uppgiften.
Vilken tagg innehåller PHP2Shell-rättningen?
Rättade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. En tagg med fullständigt versionsnummer visar nivån direkt. Vid kortare taggar som 8.4-fpm kontrollerar ni efter hämtningen med php -v vilken version som faktiskt ingår.
Finns det en patchad officiell image för PHP 8.1?
PHP-projektet levererar inga officiella releaser för 8.1 och äldre längre. En officiell image för dessa grenar kan därför inte innehålla en vanlig rättad version. Planera övergången till en gren som stöds.
Är apache-varianten riskablare än fpm?
apache-varianten kör PHP som Apache-modul, alltså mod_php. Det driftläget bedömer PHP-teamet som högst vid PHP2Shell. Båda varianterna behöver uppdateringen; vid mod_php är det särskilt brådskande.