Aplicar patches ao PHP em contentores Docker

Em resumo: atualizar a imagem Docker do PHP é obrigatório contra o PHP2Shell, e não acontece por si. Tem de reconstruir ou voltar a obter a imagem com uma versão corrigida do PHP, recriar cada contentor a partir dela e verificar que no contentor em execução corre o 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Um simples reinício do contentor não basta.

Porque é que os contentores não são seguros automaticamente

Uma imagem Docker é um retrato congelado. O PHP que contém mantém-se no nível que tinha quando foi construída, mesmo que no anfitrião já tenham sido instaladas atualizações há muito. Uma atualização de pacotes no sistema anfitrião não altera nada no PHP do contentor.

Acrescem armadilhas típicas: imagens construídas há meses e desde então intocadas, imagens base com etiqueta fixa como php:8.3.35-fpm, caches locais que na construção reutilizam a imagem base antiga e contentores que foram reiniciados, mas nunca recriados. Estão afetados todos os modos de operação habituais em contentores: PHP-FPM, Apache com mod_php e FrankenPHP.

Acresce uma questão de responsabilidade. Em muitas empresas, uma agência ou um programador construiu a imagem uma vez, mas quem a opera é a TI interna ou um fornecedor de alojamento. Então ninguém se sente responsável pelo nível do PHP na imagem. Esclareça por isso primeiro quem constrói a imagem, onde está o Dockerfile e quem pode distribuir imagens novas.

Verificar a versão do PHP no contentor

Verifique o contentor em execução, e não apenas o Dockerfile. Os comandos são apenas de leitura.

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}}"

Se a imagem usar pacotes de distribuição em vez de compilações oficiais do PHP, verifique o estado do pacote no contentor. Os nomes dos pacotes variam conforme a distribuição base:

docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"

Nos pacotes de distribuição, pode haver um backport instalado, apesar de o número de versão continuar antigo. Nesse caso, conta o changelog do pacote. As imagens oficiais do PHP trazem, por outro lado, o PHP geralmente compilado por si; aí, o número de versão do php -v é o valor decisivo. Como reconhecer backports, descreve-o Verificar corretamente a versão do PHP e o nível de patch.

Atualizar a imagem Docker do PHP: reconstruir e distribuir

Imagem própria baseada numa imagem PHP: voltar a obter a imagem base e construir sem cache.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # verificar a versão antes de a distribuir

Com Docker Compose: obter ou construir as imagens e recriar os contentores.

docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate

Verifique depois, de novo, com docker exec <container> php -v, se a versão nova está em execução. Se o contentor tiver uma etiqueta de versão fixa no Dockerfile, por exemplo FROM php:8.3.35-fpm, tem de subir a etiqueta. Uma etiqueta para o ramo, como php:8.3-fpm, recebe novos níveis de patch, mas só se voltar a obter a imagem.

Mantenha a imagem anterior à mão até a versão nova estar testada. Se houver um erro, pode assim voltar atrás sem deixar a aplicação muito tempo offline. A imagem antiga contém, porém, de novo o PHP vulnerável; um retorno só é por isso defensável por pouco tempo e com as medidas provisórias.

Quem usa Kubernetes distribui a imagem nova através do deployment. Os pormenores constam de Aplicar patches ao PHP no Kubernetes. Para imagens FrankenPHP aplica-se o mesmo procedimento; indicações sobre o modo de operação encontra-as em Proteger o FrankenPHP.

Medidas provisórias no contentor

Se a atualização ainda não for possível, as medidas provisórias do php.net aplicam-se também no contentor. Não são uma proteção completa. O limite de memória pertence aqui ao contentor, pois o php.net recomenda-o através de contentor ou cgroup, e não através de RLIMIT_AS ou RLIMIT_DATA:

; p. ex. como ficheiro na imagem: /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 ...         # ou no Compose: deploy.resources.limits.memory

O valor, ajuste-o à sua aplicação. Tenha o cuidado de a aplicação não poder sobrepor ela própria o memory_limit; no PHP-FPM, defina para isso os valores no pool com php_admin_value. A configuração nova só produz efeito quando o contentor é recriado ou reiniciado; os antecedentes sobre o reinício constam de Reiniciar o PHP-FPM e todos os workers.

Para que seja mais rápido da próxima vez

• Reconstruir as imagens regular e automaticamente, e não apenas quando o código muda.
• Usar imagens base com etiqueta de ramo e versionar o estado construído com data ou digest.
• Mandar verificar as imagens quanto a vulnerabilidades conhecidas antes de as distribuir e operar contentores sem direitos de root.
• Manter um inventário de que contentores usam que imagem.

Como ajuda concretamente a PHP SOS?

• Registar o parque: verificamos todos os contentores em execução, as suas imagens e versões do PHP, também os contentores auxiliares e o staging.
• Reconstruir e distribuir: através do serviço de patches PHP, construímos as imagens com a versão corrigida e recriamos os contentores de forma controlada.
• Proteger a transição, onde a atualização depende da aplicação: valores do php.net, limite de memória no contentor.
• Vigiar de forma contínua: com a monitorização de segurança, mantemos sob observação os níveis das imagens e o comportamento anómalo dos contentores.

Perguntas frequentes

Fontes

• php.net: avisos de segurança
• PHP 8 ChangeLog
• OWASP Cheat Sheets