Em resumo: no Kubernetes, o PHP está na imagem do contentor, não no cluster. Depois do PHP2Shell, tem de recompilar cada imagem PHP do Kubernetes com a versão PHP corrigida, fazer novo rollout de todos os workloads afetados e verificar depois o nível em cada pod em execução. Uma imagem de base atualizada no registry não altera nada nos pods em execução.
Porque é que o cluster por si só não aplica patches
O Kubernetes gere contentores, mas não se ocupa do software que está dentro deles. Cada pod corre com a imagem a partir da qual foi iniciado, até ser substituído. Quem opera aplicações PHP no cluster é por isso responsável pelas imagens, mesmo que o cluster corra como serviço gerido num fornecedor de cloud. O fornecedor mantém tipicamente o plano de controlo e os nós, não as imagens dos clientes.
O PHP2Shell engloba a CVE-2026-109618 e a CVE-2026-109619, cada uma com CVSS v4.0 9.2. Estão afetados, entre outros, o PHP-FPM, o Apache com mod_php e o FrankenPHP, ou seja, os modos de operação habituais nas imagens PHP. Estão corrigidos o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Levantamento: que imagem PHP do Kubernetes corre onde?
Comece por uma lista de todas as imagens do cluster. Os comandos seguintes apenas leem. Os nomes de namespaces, deployments e contentores são exemplos.
# Todas as imagens de todos os pods, agrupadas
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Digest da imagem realmente em execução, por contentor
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# Versão PHP num pod em execução
kubectl exec -n shop deploy/web -c php -- php -v
Pense, além dos deployments, também nos StatefulSets, DaemonSets, CronJobs e init containers. Em clusters maiores ajudam os analisadores de imagens, que pesquisam as imagens à procura de CVE conhecidas. Para pacotes de distribuição dentro da imagem vale, como em todo o lado: um backport pode deixar o número de versão inalterado, e então conta o registo de alterações do pacote.
Recompilar as imagens
Atualize primeiro a imagem de base. Se usar imagens PHP oficiais, escolha uma variante com a versão PHP corrigida. Depois, recompile a sua própria imagem, sem aproveitar da cache a camada de base antiga.
# Exemplo: recompilar a imagem, obtendo de novo ativamente a imagem de base
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Verificar a versão PHP na imagem nova antes do rollout
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Não confie em tags como latest ou numa mera versão principal. No manifesto, referencie sempre que possível o digest da nova imagem, para que fique claro que nível é lançado. Se a disponibilização for feita por GitOps ou Helm, altere a imagem aí, para que o nível não seja reposto na próxima sincronização.
Rollout e verificação
Um novo rollout substitui gradualmente todos os pods de um workload. Depois, verifique o nível nos pods em execução. Só então o patch é eficaz, porque ficheiros novos só ajudam se os processos PHP antigos já não estiverem a correr.
# Rollout com imagem nova (nomes como exemplo)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Verificação: todos os pods reiniciados, novo digest ativo?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Se a imagem foi enviada de novo com a mesma tag, kubectl rollout restart desencadeia um reinício; no entanto, os pods só voltam a obter a imagem se a imagePullPolicy o previr. Mais seguro é mudar para um novo digest.
Preserve os registos antes de substituir pods. Com o pod antigo desaparecem também os seus registos locais. Guarde os registos do servidor web e da aplicação a partir de 20/10/2026, idealmente numa plataforma de logs central.
Medidas provisórias no cluster
Se ainda não existir uma imagem corrigida para a sua versão PHP, o php.net recomenda medidas provisórias sem proteção completa. No cluster, defina os limites de memória através dos limites de recursos dos contentores, que se baseiam em cgroups. Isto corresponde à recomendação de limitar a memória através do contentor ou de cgroups e não através de RLIMIT_AS ou RLIMIT_DATA.
; php.ini ou pool FPM na imagem, por exemplo integrado através de ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Com função de upload, o php.net indica post_max_size = 32M. No PHP 8.5 acresce fatal_error_backtraces=0. Depois de alterar a configuração, é necessário um novo rollout. Complementarmente, as NetworkPolicies limitam as ligações de saída dos pods PHP, e um Ingress com regras de proteção pode dificultar tentativas de ataque. Regras baseadas apenas nos dados do pedido não bastam, segundo a Cloudflare.
Ficar melhor preparado a longo prazo
Planeie rebuilds automáticos regulares de todas as imagens PHP, uma verificação de imagens na cadeia de compilação e políticas que só admitam imagens assinadas ou verificadas. Se os contentores PHP correrem com utilizador sem direitos de root e sistema de ficheiros protegido contra escrita, diminui o dano de um ataque bem-sucedido. As indicações para contentores individuais estão em Aplicar patch ao PHP em contentores Docker, para o FrankenPHP em Proteger o FrankenPHP.
Em muitos clusters, as aplicações PHP não correm sozinhas. Há muitas vezes contentores sidecar para registo ou métricas, imagens auxiliares para migrações de bases de dados e jobs que só arrancam de noite. Também imagens de terceiros, por exemplo para uma wiki, uma interface de monitorização ou um sistema de tickets, podem conter PHP sem que isso seja reconhecível no nome. Verifique por isso não só as suas aplicações, mas todas as imagens do cluster. Para imagens de terceiros vale: aguarde por uma versão atualizada do fabricante, confira as indicações dele sobre a versão PHP incluída e limite a acessibilidade até ela existir. Se um sistema desses só correr internamente, isso reduz o risco, mas não substitui a atualização.
Como ajuda concretamente a PHP SOS?
- Levantamos todos os workloads com PHP, as suas imagens e digests e verificamos a versão PHP nos pods em execução.
- Através do serviço de patches PHP, recompilamos imagens, fazemos o rollout e documentamos o nível por workload.
- Preservamos os registos antes da substituição e verificamos se há vestígios de um ataque.
- Com monitorização de segurança e rebuilds automatizados, fazemos com que o próximo patch chegue mais depressa ao cluster.
Perguntas frequentes
Basta atualizar a imagem de base no registry?
Não. Os pods em execução continuam a usar a imagem com que foram iniciados. Só um novo rollout com a imagem recompilada substitui os pods. Verifique depois a versão PHP em cada pod em execução.
Porque referenciar as imagens por digest?
Uma tag pode apontar para níveis de imagem diferentes, consoante o momento em que foi obtida. Um digest identifica exatamente um nível. Assim sabe com certeza que código corre em que pod, e os rollouts tornam-se rastreáveis.
E os CronJobs e os init containers?
Também podem conter PHP e fazem parte do levantamento. Os CronJobs iniciam novos pods a partir do seu modelo em cada execução; atualize por isso a imagem no modelo. Os init containers correm no arranque de cada pod.
Uma NetworkPolicy protege contra o PHP2Shell?
Não fecha a vulnerabilidade, mas pode limitar os danos. Quem restringe as ligações de saída dos pods PHP dificulta o carregamento de código malicioso e os movimentos laterais no cluster.