Um sistema publicado continua sendo uma responsabilidade
Um sistema pode estar funcionando, atendendo clientes e gerando receita enquanto um componente da sua infraestrutura precisa de uma correção urgente. A ausência de erro visível não comprova que o ambiente está protegido.
É por isso que eu insisto em olhar para software além do desenvolvimento. O deploy inicia uma operação que precisa continuar confiável. Alguém deve acompanhar os componentes utilizados, avaliar alertas e conseguir aplicar mudanças com rapidez. Quando essa responsabilidade fica indefinida, a empresa transforma manutenção em improviso.
O que aconteceu com o PHP
Em 21 de outubro de 2026, foram publicadas correções para duas vulnerabilidades críticas no PHP, identificadas como CVE-2026-109618 e CVE-2026-109619 e conhecidas em conjunto como PHP2Shell. Ambas receberam pontuação oficial de 9,2 no CVSS v4.0. (PHP — comunicado de lançamento, PHP — aviso prévio)
Uma envolve corrupção de estado durante falhas por esgotamento de memória. A outra envolve referências internas a memória já liberada, que podem ser utilizadas por uma requisição posterior. Os avisos descrevem condições capazes de permitir execução remota de código sem autenticação. Isso é um impacto potencial grave; não significa que toda aplicação PHP esteja sendo explorada da mesma forma. (Aviso sobre memória, aviso sobre estado interno)
O problema alcança a infraestrutura da aplicação
A orientação oficial abrange instalações PHP que atendem requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O projeto considera o risco maior em mod_php, onde foi demonstrado um caminho de ataque antes da execução do código da aplicação. A configuração e os caminhos de execução importam. (PHP — escopo do alerta)
Para uma empresa, a pergunta prática é onde esse runtime está presente. Pode estar no site institucional, no comércio eletrônico, em um portal interno ou em um serviço de terceiro. Essa identificação exige conhecer o ambiente que sustenta a operação.
A consequência técnica vira uma consequência de negócio
Uma execução indevida no servidor pode afetar dados, disponibilidade e confiança. O alcance depende das permissões do processo e das conexões disponíveis. Um componente com acesso a outras informações pode ampliar o impacto de uma falha inicialmente localizada.
Isso muda a avaliação da manutenção. O custo de atualizar precisa ser considerado junto com o custo de interromper vendas, perder acesso a um processo ou investigar uma possível exposição. Mesmo quando nada disso ocorre, uma empresa sem inventário e responsáveis perde tempo tentando descobrir quem deveria agir.
O tamanho da equipe não resolve essa ausência de decisão. Uma operação enxuta precisa conhecer seus limites e contar com responsáveis claros para desenvolvimento, hospedagem e manutenção.
Atualizar exige uma decisão e uma entrega verificável
As correções upstream foram lançadas nas versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12. A Fundação PHP reforçou a necessidade de atualização. Para pacotes mantidos por distribuições ou fornecedores, é preciso conferir o aviso correspondente e a existência de backport. (PHP Foundation — correções e contexto)
A liderança precisa estabelecer prioridade, responsável e critério de conclusão. Avisar que a atualização foi solicitada não comprova que o ambiente em produção já utiliza o componente corrigido.
A correção também precisa alcançar imagens, réplicas e produtos que incorporam PHP. O NCSC dos Países Baixos orienta verificar esses ambientes separadamente. Depois, a equipe deve confirmar a versão efetiva e validar os fluxos importantes do negócio. (NCSC-NL — orientação operacional)
Uma atualização importante em 23 de outubro
Em 23/10/2026, o PHP recomendou desabilitar session.upload_progress.enabled até o próximo bugfix para um cenário incomum de sessão. Inclua essa orientação adicional na atualização. (PHP — aviso de 23 de outubro)
Acompanhar o aviso depois de aplicar o primeiro patch faz parte da manutenção. Segurança depende de informação atualizada e de alguém capaz de transformá-la em ação.
O vídeo e a responsabilidade depois da entrega
No vídeo sobre as falhas críticas do PHP, a discussão é justamente o que esse tipo de alerta representa para quem mantém aplicações no ar. Colocar um sistema em produção inclui assumir a continuidade da sua manutenção. (Assista ao vídeo no Instagram)