Kort gezegd: De officiële PHP-image op Docker Hub bestaat in veel tags die versie, variant (bijvoorbeeld cli, fpm, apache) en basissysteem combineren. Een tag is een verwijzing die na herbouwen naar nieuwe standen schuift; alleen de digest duidt precies één stand aan. Tegen PHP2Shell hebt u een image met PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 nodig, gecontroleerd met php -v, en een herbouw van uw eigen images daarop.
Waarom de tag alleen weinig verraadt
Veel teams schrijven in hun Dockerfile een regel zoals FROM php:8.3-fpm en vergeten die dan. Dat werkt zolang niemand vraagt welke PHP-versie er eigenlijk draait. Sinds PHP2Shell vraagt iedereen het.
Het antwoord staat niet in het Dockerfile. Een tag zoals 8.3-fpm wijst op het moment van ophalen naar de nieuwste stand van die tak. Werd de image vóór 21 oktober opgehaald en sindsdien niet vernieuwd, dan bevat ze een kwetsbare versie, hoewel de tag vandaag naar een verholpen stand wijst. Volgens de richtlijnen van de Docker Official Images worden de images actief opnieuw gebouwd, ook bij beveiligingscorrecties. Uw lokale stand wordt daar echter niet door geraakt.
Het volledige verloop van herbouw tot nieuw aangemaakte container beschrijft PHP in Docker-containers patchen. Hier gaat het om de voorvraag: welke image is de juiste, en hoe toont u haar stand aan?
PHP Docker-image-tags: zo zijn ze opgebouwd
De tags bestaan uit maximaal drie delen. Docker Hub toont voorbeelden zoals php:8.2-cli, php:8.2-fpm-alpine of php:8.4.27-zts-alpine3.24.
| Onderdeel | Voorbeeld | Betekenis |
|---|---|---|
| Versie-aanduiding | 8.4.27 of 8.4 |
volledige versie blijft bij deze stand, tak-aanduiding schuift mee met nieuwe patches |
| Variant | cli, fpm, apache, zts |
bedrijfsmodus van PHP in de container |
| Basissysteem | alpine3.24, bookworm, trixie |
onderliggende Alpine- of Debian-versie |
De varianten zijn voor PHP2Shell niet gelijkwaardig. fpm draait PHP-FPM, apache draait PHP als Apache-module, dus mod_php. Deze bedrijfsmodus schat het PHP-team het hoogst in, omdat daar een exploit is getoond voordat er überhaupt toepassingscode draait. Meer daarover onder Waarom mod_php bijzonder kwetsbaar is. De variant cli is bedoeld voor taken op de opdrachtregel.
Ook het basissysteem heeft gevolgen. Alpine-images zijn klein, maar gebruiken een andere C-bibliotheek dan Debian-images; sommige extensies of voorgecompileerde bibliotheken gedragen zich daar anders. Wissel het basissysteem daarom niet terloops met de beveiligingsupdate, maar blijf eerst bij wat uw toepassing kent.
Belangrijk voor het begrip: in de officiële image komt PHP niet uit de pakketten van de basisdistributie. Docker Hub beschrijft dat de PHP-bronnen in de image liggen en extensies via hulpscripts zoals docker-php-ext-install worden ingebouwd. Een pakketupdate van het basissysteem in uw eigen Dockerfile verandert daarom niets aan de PHP-versie. Maatgevend is alleen op welke stand van de officiële image u voortbouwt.
Tag of digest: wat verandert wanneer
Een digest is een controlesom over de inhoud van een image, geschreven als sha256: met een lange tekenreeks. Hij verandert met elke herbouw. Daardoor is hij geschikt als bewijs: wie de digest kent, weet precies welke stand draait.
In de praktijk bewijst een taakverdeling zich:
- In het Dockerfile de tak-tag gebruiken, bijvoorbeeld
php:8.4-fpm, zodat een herbouw automatisch de nieuwste patch van die tak krijgt. - Bij de uitrol de digest van de afgebouwde eigen image gebruiken, zodat duidelijk is wat er wordt geleverd.
- In de documentatie beide vastleggen: tag, digest en de met
php -vgecontroleerde versie.
Wie in plaats daarvan een volledige versietag zoals 8.3.35-fpm vastzet, krijgt nooit automatisch een patch. Dat kan gewild zijn, maar vereist een proces dat de tag bij elke beveiligingsmelding verhoogt.
PHP2Shell: een image vóór gebruik controleren
De volgende opdrachten halen een image op en lezen gegevens uit. Ze wijzigen geen draaiende containers.
# Actuele stand van de tak-tag ophalen
docker pull php:8.4-fpm
# Welke PHP-versie zit er in de image?
docker run --rm php:8.4-fpm php -v
# Digest van de opgehaalde image tonen
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Digest en platformen rechtstreeks in de registry opvragen
docker buildx imagetools inspect php:8.4-fpm
De opvraging met imagetools toont bij multiplatform-images een overkoepelende digest en daaronder per platform, bijvoorbeeld linux/amd64 of linux/arm64, een eigen digest. Documenteer de digest die uw servers werkelijk ophalen, en houd er rekening mee dat ontwikkelaarscomputers met een andere architectuur een andere platformdigest krijgen.
Toont php -v niet minstens de verholpen versie van de tak, dan is de image verouderd of komt ze uit een tussenopslag. Controleer dan of uw omgeving een registry-mirror gebruikt die oude standen uitlevert.
Voor PHP 8.1 en ouder levert het PHP-project geen officiële releases meer. Een officiële image van deze takken kan daarom geen reguliere verholpen versie bevatten. Tags die niet meer worden onderhouden, blijven volgens de Docker-richtlijnen opvraagbaar, maar worden niet meer bijgewerkt.
De image bevat volgens Docker Hub php.ini-development en php.ini-production en adviseert voor productie dringend de productieversie. Eigen instellingen plaatst u als bestand in $PHP_INI_DIR/conf.d/, ook de overbruggingswaarden van php.net.
Typische fouten bij de imagekeuze
- Variant uit gewoonte: De apache-variant wordt gekozen omdat ze eenvoudig start, hoewel fpm met een aparte webserver mogelijk was.
- Geen herbouw van de eigen images: De basisimage is actueel, de daaruit gebouwde applicatie-image niet.
- Meertrapsbuilds over het hoofd gezien: In een Dockerfile met meerdere
FROM-regels wordt er maar één aangepast. - Nevenimages vergeten: Workers, cron-containers en beheerhulpmiddelen gebruiken eigen tags.
- Alleen op
latestvertrouwen: De tag zegt niets over tak en variant en kan bij een nieuwe hoofdtak onverwacht springen.
Hoe u herbouwen automatiseert zodat een verouderde image niet eens lang draait, beschrijft CI/CD: PHP-images automatisch opnieuw bouwen. De basis over PHP in containers legt PHP in containers uit.
Hoe helpt PHP SOS concreet?
- Bestand controleren: Wij lezen uit welke tags, digests en PHP-versies in uw images en draaiende containers zitten.
- Variant beoordelen: Wij controleren of mod_php nodig is of dat fpm met een aparte webserver het risico verlaagt.
- Opnieuw bouwen en aantonen: Met de PHP-patchservice bouwen wij images opnieuw op verholpen basis en documenteren wij tag, digest en versie.
- Proces verankeren: Wij richten Dockerfiles en uitrol zo in dat de volgende patch plannbaar aankomt.
Veelgestelde vragen
Wat is het verschil tussen tag en digest?
Een tag zoals php:8.4-fpm is een naam die na elke herbouw naar een nieuwe stand kan wijzen. Een digest is een controlesom die precies één onveranderlijke stand aanduidt. Voor bewijzen en reproduceerbare uitrol is de digest de betrouwbaarder aanduiding.
Welke tag bevat de PHP2Shell-correctie?
Verholpen zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Een tag met het volledige versienummer toont de stand direct. Bij kortere tags zoals 8.4-fpm controleert u na het ophalen met php -v welke versie er werkelijk in zit.
Bestaat er een gepatchte officiële image voor PHP 8.1?
Het PHP-project levert voor 8.1 en ouder geen officiële releases meer. Een officiële image van deze takken kan daarom geen reguliere verholpen versie bevatten. Plan de overstap naar een ondersteunde tak.
Is de apache-variant riskanter dan fpm?
De apache-variant draait PHP als Apache-module, dus mod_php. Deze bedrijfsmodus schat het PHP-team bij PHP2Shell het hoogst in. Beide varianten hebben de update nodig; bij mod_php is haast extra geboden.