O PHP corrigiu duas falhas críticas no interpretador, a CVE-2026-109618 e a CVE-2026-109619. Quem roda PHP em container só estará protegido depois do rebuild das imagens e trocar todos os pods. No Quor, as imagens já estão nas versões corrigidas.
CEO
Diogo Goebel
Na daily de hoje, o assunto foi o PHP2Shell: o que são as duas CVEs novas, que risco elas trazem para quem roda PHP e em que pé estavam as nossas imagens. A versão corrigida saiu ontem e as imagens do Quor já estavam com a correção aplicada.
Resolvi juntar aqui o que a gente levantou, principalmente a parte de container, que quase não aparece nas notícias.
As duas CVEs
CVE | Advisory | Descrição do PHP |
|---|---|---|
GHSA-w8hw-w9fx-j79w | RCE via corrupção de memória no tratamento de out-of-memory | |
GHSA-6wmf-4rv5-p3rp | RCE via estado global que sobrevive entre requisições |
As duas têm CVSS 9.2 e podem ser exploradas sem autenticação. A falha está no motor do PHP, então vale para qualquer aplicação em versão afetada, inclusive um "Hello World".
O mecanismo é parecido nas duas. Uma requisição termina no meio, normalmente por estourar o memory_limit, e o PHP deixa para trás um estado interno que deveria ter sido descartado. A requisição seguinte no mesmo worker usa esse estado. Com isso dá para ler a memória do processo, onde ficam senhas, tokens e chaves de API, ou executar código.
As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35, de 21/10. Para 8.1 e anteriores não há release oficial, só backport de código-fonte para 7.4, 8.0 e 8.1. Desligar session.upload_progress reduz alguns caminhos de ataque, mas segundo o próprio PHP a correção completa é atualizar.
Por que o prazo encurtou
O código vulnerável estava no PHP havia mais de dez anos. Explorar a falha exigia encadear vários bugs e ajustar o ataque ao layout de memória de cada alvo, e até agora ninguém tinha chegado lá. A Wiz conta que usou modelos de IA para encontrar o problema e adaptar o exploit para WordPress, Drupal e Joomla em poucas horas.
Os números das CVEs vazaram um dia antes da correção, e na manhã do release já havia relatos de tentativas de ataque. Na prática, um bug antigo que todo mundo considerava difícil de explorar teve um prazo de horas entre se tornar público e começar a ser explorado.
Newsletter Getup.
Atualizações sobre Kubernetes e Software Supply Chain Security todos os meses.
No container
A correção só chega ao container quando a imagem é rebuildada. Quem usa tag flutuante, como php:8.3-fpm, precisa fazer rebuild e redeploy. Atualizar o host não muda o PHP que roda dentro do container. Quem herda o PHP de outra imagem (WordPress, Drupal, uma base interna) depende de quem mantém essa imagem.
O scanner também atrasa. As bases de vulnerabilidade levam um tempo para incorporar um advisory novo, e até lá uma imagem vulnerável pode aparecer limpa no relatório.
No Quor, as imagens de PHP já usam as versões corrigidas e estão livres das duas CVEs. Aproveito para trazer o comparativo da semana de 15 a 22/10 entre a nossa php:8.5-fpm-zts-alpine e a pública docker.io/library/php:8.5:
Imagem Quor | Imagem pública | |
|---|---|---|
CVEs (total) | 3 | 941 |
Críticas | 0 | 13 |
Altas | 1 | 131 |
Médias | 2 | 80 |
Pacotes | 86 | 172 |
Tamanho comprimido (MB) | 38,55 | 189,39 |
A pública tem o dobro de pacotes e quase cinco vezes o tamanho, e cada pacote a mais é mais uma coisa para corrigir numa semana como esta. No nosso caso, a versão corrigida saiu ontem e hoje de manhã as imagens já estavam reconstruídas.
Checklist
Liste onde o PHP roda: hosts, imagens base, imagens de terceiros que embutem PHP, appliances e painéis.
Confira a versão no binário, não na tag: docker run --rm --entrypoint php <imagem> -r 'echo PHP_VERSION;'. Em distros que fazem backport, olhe o changelog do pacote.
Faça rebuild com --pull, redeploy e fixe a imagem por digest.
Confira pod a pod se todos os workers reiniciaram com o binário novo.
Se suspeitar de exploração, colete memória e logs antes de reiniciar, porque o restart apaga o estado que essas falhas usam.
Se estiver no 8.1 ou abaixo, planeje a migração além do backport.
Para quem está sob a BCB 538 e a CMN 5.274, vale guardar o registro desta semana: quando a correção saiu, quando cada imagem foi reconstruída e qual digest está rodando em cada pod.
Fontes
Há mais de 13 anos operando Kubernetes em produção. Com o Quor, essa experiência alcança também a segurança da cadeia de software.
