Em resumo: A imagem oficial do PHP no Docker Hub existe em muitas tags que combinam versão, variante (por exemplo cli, fpm, apache) e sistema base. Uma tag é um apontador que passa para novos estados após reconstruções; só o digest designa exatamente um estado. Contra o PHP2Shell precisa de uma imagem com PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, verificada com php -v, e de uma reconstrução das suas próprias imagens sobre ela.
Porque é que só a tag revela pouco
Muitas equipas escrevem no seu Dockerfile uma linha como FROM php:8.3-fpm e esquecem-na. Isso funciona enquanto ninguém perguntar que versão do PHP está realmente a correr. Desde o PHP2Shell, todos perguntam.
A resposta não está no Dockerfile. Uma tag como 8.3-fpm aponta, no momento em que se obtém a imagem, para o estado mais recente desse ramo. Se a imagem foi obtida antes de 21 de outubro e não foi renovada desde então, contém uma versão vulnerável, embora a tag aponte hoje para um estado corrigido. Segundo as diretrizes das Docker Official Images, as imagens são reconstruídas ativamente, também perante correções de segurança. O seu estado local não é, contudo, afetado por isso.
O procedimento completo, da reconstrução ao contentor recriado, está descrito em Aplicar patches ao PHP em contentores Docker. Aqui trata-se da questão prévia: qual é a imagem certa e como comprova o seu estado?
Tags das imagens Docker do PHP: como são construídas
As tags compõem-se de até três partes. O Docker Hub mostra exemplos como php:8.2-cli, php:8.2-fpm-alpine ou php:8.4.27-zts-alpine3.24.
| Componente | Exemplo | Significado |
|---|---|---|
| Indicação de versão | 8.4.27 ou 8.4 |
a versão completa mantém-se neste estado, a indicação do ramo acompanha os novos patches |
| Variante | cli, fpm, apache, zts |
modo de operação do PHP no contentor |
| Sistema base | alpine3.24, bookworm, trixie |
versão subjacente do Alpine ou do Debian |
As variantes não são equivalentes para o PHP2Shell. O fpm opera o PHP-FPM, o apache opera o PHP como módulo Apache, ou seja, mod_php. A equipa do PHP classifica este modo de operação como o de maior risco, porque aí foi demonstrado um exploit antes de sequer correr o código da aplicação. Mais sobre isto em Porque é que o mod_php está particularmente exposto. A variante cli destina-se a tarefas de linha de comandos.
O sistema base também tem consequências. As imagens Alpine são pequenas, mas usam uma biblioteca C diferente das imagens Debian; algumas extensões ou bibliotecas pré-compiladas comportam-se aí de outro modo. Não mude por isso o sistema base de passagem com a atualização de segurança, mas fique primeiro com o que a sua aplicação conhece.
É importante perceber: na imagem oficial, o PHP não provém dos pacotes da distribuição base. O Docker Hub descreve que o código-fonte do PHP está na imagem e que as extensões são incorporadas através de scripts auxiliares como docker-php-ext-install. Uma atualização de pacotes do sistema base no seu próprio Dockerfile não altera por isso a versão do PHP. Decisivo é apenas sobre que estado da imagem oficial constrói.
Tag ou digest: o que muda e quando
Um digest é uma soma de verificação do conteúdo de uma imagem, escrita como sha256: com uma longa sequência de caracteres. Muda a cada reconstrução. Por isso serve como comprovativo: quem conhece o digest sabe exatamente que estado está a correr.
Na prática, resulta bem uma divisão de tarefas:
- No Dockerfile usar a tag do ramo, por exemplo
php:8.4-fpm, para que uma reconstrução receba automaticamente o patch mais recente desse ramo. - Na publicação usar o digest da imagem própria já construída, para que fique inequívoco o que é entregue.
- Na documentação registar ambos: tag, digest e a versão verificada com
php -v.
Quem, em vez disso, fixa uma tag de versão completa como 8.3.35-fpm nunca recebe um patch automaticamente. Pode ser intencional, mas exige um processo que eleve a tag a cada aviso de segurança.
PHP2Shell: verificar uma imagem antes de a usar
Os comandos seguintes obtêm uma imagem e leem informações. Não alteram nenhum contentor em execução.
# Obter o estado atual da tag do ramo
docker pull php:8.4-fpm
# Que versão do PHP está na imagem?
docker run --rm php:8.4-fpm php -v
# Mostrar o digest da imagem obtida
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Consultar o digest e as plataformas diretamente no registo
docker buildx imagetools inspect php:8.4-fpm
A consulta com imagetools mostra, nas imagens multiplataforma, um digest de nível superior e, por baixo, um digest próprio por plataforma, por exemplo linux/amd64 ou linux/arm64. Documente o digest que os seus servidores obtêm realmente e tenha em conta que computadores de desenvolvimento com outra arquitetura recebem outro digest de plataforma.
Se o php -v não mostrar pelo menos a versão corrigida do ramo, a imagem está desatualizada ou vem de uma cache intermédia. Verifique então se o seu ambiente usa um espelho de registo que entrega estados antigos.
Para o PHP 8.1 e anteriores, o projeto PHP já não fornece lançamentos oficiais. Uma imagem oficial desses ramos não pode por isso conter uma versão corrigida regular. As tags que deixam de ser mantidas continuam, segundo as diretrizes do Docker, acessíveis, mas já não são atualizadas.
A imagem traz, segundo o Docker Hub, php.ini-development e php.ini-production e recomenda vivamente a versão de produção para a operação produtiva. As suas próprias definições guarda-as como ficheiro em $PHP_INI_DIR/conf.d/, também os valores provisórios do php.net.
Erros típicos na escolha da imagem
- Variante por hábito: escolhe-se a variante apache porque arranca facilmente, embora fosse possível o fpm com servidor web separado.
- Sem reconstrução das imagens próprias: a imagem base está atual, a imagem de aplicação construída a partir dela não.
- Builds de várias fases ignorados: num Dockerfile com várias linhas
FROM, só uma é adaptada. - Imagens secundárias esquecidas: workers, contentores cron e ferramentas de administração usam tags próprias.
- Confiar só em
latest: a tag não diz nada sobre ramo e variante e pode saltar inesperadamente num novo ramo principal.
Como automatizar as reconstruções, para que uma imagem desatualizada nem sequer chegue a correr muito tempo, está descrito em CI/CD: reconstruir imagens PHP automaticamente. Os fundamentos do PHP em contentores são explicados em PHP em contentores.
Como ajuda concretamente a PHP SOS?
- Verificar o inventário: lemos que tags, digests e versões do PHP estão nas suas imagens e contentores em execução.
- Avaliar a variante: verificamos se o mod_php é necessário ou se o fpm com servidor web separado reduz o risco.
- Reconstruir e comprovar: com o serviço de patch PHP, reconstruímos imagens sobre uma base corrigida e documentamos tag, digest e versão.
- Fixar o processo: configuramos Dockerfiles e publicações de modo que o próximo patch chegue de forma planeável.
Perguntas frequentes
Qual é a diferença entre tag e digest?
Uma tag como php:8.4-fpm é um nome que, após cada reconstrução, pode apontar para um novo estado. Um digest é uma soma de verificação que designa exatamente um estado imutável. Para comprovativos e publicações reproduzíveis, o digest é a indicação mais fiável.
Que tag contém a correção do PHP2Shell?
Estão corrigidos o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Uma tag com o número de versão completo mostra diretamente o estado. Nas tags mais curtas, como 8.4-fpm, verifique com php -v, depois de obter a imagem, que versão está realmente incluída.
Existe uma imagem oficial com patch para o PHP 8.1?
O projeto PHP já não fornece lançamentos oficiais para a 8.1 e anteriores. Uma imagem oficial desses ramos não pode por isso conter uma versão corrigida regular. Planeie a mudança para um ramo suportado.
A variante apache é mais arriscada do que a fpm?
A variante apache opera o PHP como módulo Apache, ou seja, mod_php. A equipa do PHP classifica este modo de operação no PHP2Shell como o de maior risco. Ambas as variantes precisam da atualização; no mod_php a pressa é particularmente indicada.