Falhas críticas no PHP: o que aconteceu e como proteger os sistemas da sua empresa

O alerta internacional exige uma resposta rápida de quem mantém sites e aplicações. Entenda a origem das vulnerabilidades, o alcance do risco e os cuidados para corrigir o ambiente com segurança.

Apuração atualizada em 23 de outubro de 2026 • Conteúdo preparado para o blog da Gerati

Um site pode continuar funcionando normalmente e, ainda assim, precisar de uma correção urgente de segurança. Esse é um dos pontos mais importantes do alerta sobre duas vulnerabilidades críticas no PHP, tecnologia utilizada para executar aplicações web. A ausência de erro na tela não demonstra que o servidor está protegido.

Em 21 de outubro, autoridades europeias divulgaram um comunicado conjunto sobre as falhas CVE-2026-109618 e CVE-2026-109619. Elas podem permitir a execução remota de código sem autenticação. A orientação é identificar aplicações dependentes de PHP, envolver os fornecedores e priorizar sistemas expostos à internet. Produtos que incorporam PHP nos bastidores também precisam entrar nessa avaliação. [1]

Para uma empresa, isso transforma uma notícia técnica em uma questão de continuidade operacional. O levantamento não deve parar no site institucional: precisa alcançar os serviços dos quais clientes, colaboradores e parceiros dependem.

O que é PHP e por que o problema importa?

PHP é uma linguagem de programação executada no servidor. Em uma aplicação que utiliza essa tecnologia, ele pode processar formulários, consultar informações e montar as páginas que chegam ao navegador. O visitante vê o resultado; a execução acontece na infraestrutura que sustenta o serviço.

Essa separação ajuda a entender a responsabilidade pela correção. Atualizar um navegador no computador do usuário não modifica o PHP do servidor. Da mesma forma, publicar uma nova página ou instalar uma atualização do gerenciador de conteúdo não comprova, por si só, que o ambiente de execução recebeu o reparo necessário.

O que aconteceu: duas falhas no funcionamento interno do PHP

As vulnerabilidades envolvem a maneira como o PHP administra memória e informações internas durante o processamento de requisições. Não se trata simplesmente de uma senha fraca ou de um formulário mal desenvolvido.

CVE-2026-109618: corrupção de memória ao tratar falta de memória

O PHP precisa interromper uma requisição quando determinadas alocações de memória falham. O problema identificado é que essa interrupção pode acontecer antes de algumas estruturas internas estarem completamente preparadas. Na etapa de encerramento, o sistema pode lidar com esse conteúdo incompleto como se ele fosse válido.

Essa inconsistência pode permitir execução remota de código. Em linguagem direta, uma condição que deveria encerrar o processamento com segurança pode abrir espaço para alterar o comportamento do servidor. O aviso técnico classifica a falha como crítica. [2]

CVE-2026-109619: referências que permanecem após a liberação da memória

A segunda falha está relacionada a informações internas que permanecem associadas a um processo de trabalho depois que a memória da requisição anterior já foi liberada. Antes de uma nova inicialização corrigir esse estado, operações posteriores podem acessar referências inválidas.

Esse tipo de erro é conhecido como use after free, ou uso de memória após sua liberação. Em condições de exploração, também pode resultar em execução remota de código. A causa envolve a sequência de limpeza e reutilização do estado interno, inclusive em caminhos de erro. [3]

Não há base, nesses avisos, para atribuir o episódio à negligência de uma empresa específica, a uma sabotagem ou a uma invasão de todos os sites. As causas técnicas estão documentadas; uma explicação sobre intenções ou responsabilidades exigiria outras evidências.

Por que o alerta ganhou alcance internacional?

O CERT-EU atribui às duas falhas pontuação 9,2 no CVSS, escala técnica de gravidade. O órgão descreve risco para instalações que atendem requisições web em diferentes modos de operação, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O cenário com mod_php recebe destaque de maior risco, com exploração demonstrada antes da execução do código da aplicação. [4]

A implicação prática é relevante: uma empresa não deve presumir proteção apenas porque seu site exige login. Também não deve tratar a troca de sistema operacional ou de servidor web como uma correção automática. É necessário verificar o componente realmente utilizado e a atualização aplicada.

O tamanho da organização não elimina a exposição. Um portal pequeno, sem dados financeiros próprios, ainda pode armazenar credenciais, receber informações de clientes ou compartilhar infraestrutura com outros serviços.

Estar vulnerável significa que a empresa foi invadida?

Não. Vulnerabilidade é uma condição que pode viabilizar um ataque. Uma tentativa é uma ação contra o ambiente, que pode falhar ou ser bloqueada. Comprometimento significa que houve sucesso e precisa ser sustentado por evidências.

No alerta de 21 de outubro, a CISA informou que ainda não havia observado exploração dessas duas falhas no momento daquela publicação. Essa informação tem uma data de referência e não representa garantia sobre o cenário posterior. [5]

Por isso, a decisão de corrigir não deve depender de esperar uma confirmação de ataque. Ao mesmo tempo, não é adequado transformar relatos de varreduras ou provas de conceito em uma contagem de empresas invadidas.

Quais são as versões corrigidas?

Os avisos oficiais identificam os seguintes patamares de correção para as duas vulnerabilidades principais, dentro de cada série: [2] [3]

Essa tabela é uma referência para as duas CVEs, não uma recomendação para permanecer indefinidamente nessas versões. Na execução da mudança, consulte as atualizações estáveis e os avisos do fornecedor.

Distribuições podem disponibilizar correções incorporadas aos próprios pacotes, sem reproduzir exatamente a numeração upstream. Para instalações antigas, o CERT-EU orienta consultar o fornecedor de suporte prolongado ou migrar para uma série suportada. PHP 8.1 e anteriores estão fora do suporte regular do projeto. [4]

Atualização de 23 de outubro: uma orientação adicional

O projeto PHP publicou um aviso sobre um cenário incomum relacionado ao progresso de upload de sessão, associado à CVE-2026-115560. A combinação envolve o recurso habilitado e a mudança do serializador de sessão de php_binary ou php_serialize para php, em tempo de execução, antes de session_start().

A recomendação publicada é configurar session.upload_progress.enabled=0 até a próxima versão regular de correção. Aplicações que nunca alteram o serializador em tempo de execução podem manter o recurso habilitado, segundo o comunicado. A equipe técnica deve conferir a configuração efetiva e os impactos funcionais. Esse aviso adicional não substitui a atualização das duas falhas principais. [6]

Como agir agora, com uma mudança controlada

Localize o PHP que realmente atende cada aplicação

Organize um inventário com o endereço do serviço, responsável, provedor, versão em uso, forma de execução e exposição à internet. Inclua subdomínios, homologação, instalações antigas, contêineres e produtos de terceiros. Um sistema esquecido pode ficar fora da atualização mesmo quando o site principal já foi corrigido.

Peça ao responsável técnico evidências do ambiente web em execução. A versão exibida por um comando no terminal pode corresponder a outra instalação. Em hospedagens com vários sites, cada domínio pode utilizar uma configuração diferente. Evite publicar páginas de diagnóstico abertas apenas para fazer essa conferência.

Defina quem fará a correção e quem validará o serviço

Hospedagem, desenvolvedor e equipe de TI precisam trabalhar com responsabilidades explícitas. O provedor pode cuidar do PHP, enquanto o desenvolvedor testa a compatibilidade e a empresa confirma que os processos essenciais continuam funcionando.

Solicite uma resposta objetiva: quais ambientes foram corrigidos, qual pacote foi aplicado, quando a mudança ocorreu e como foi verificada. Uma afirmação genérica de que “a segurança está atualizada” dificulta a gestão do risco.

Aplique a atualização e teste os fluxos que sustentam o negócio

Como procedimento operacional, prepare uma cópia recuperável dos dados e das configurações, valide a compatibilidade e execute a mudança com prioridade proporcional à exposição. Teste autenticação, formulários, envio de mensagens, integrações, uploads e outras funções efetivamente utilizadas pela empresa.

Depois da instalação, confirme que os processos passaram a utilizar o componente corrigido. Em ambientes distribuídos, verifique todas as instâncias. Atualizar uma imagem de contêiner sem substituir as instâncias antigas, por exemplo, não demonstra que toda a operação está protegida.

Um plano de retorno também precisa considerar segurança. Se uma atualização provocar incompatibilidade, voltar a expor uma versão vulnerável pode recriar o risco. A decisão pode exigir restrição temporária de acesso enquanto o problema funcional é resolvido.

Se a correção imediata não for possível, reduza a exposição

O CERT-EU recomenda considerar o isolamento dos serviços expostos até que a atualização seja aplicada e verificada. As mitigações de configuração descritas nos avisos reduzem caminhos específicos de exploração, mas não tornam uma instalação vulnerável segura. [4]

Essa decisão deve ser coordenada com quem depende do serviço. Um bloqueio parcial no lugar errado pode interromper clientes e ainda deixar outro acesso aberto. A equipe deve avaliar o caminho completo até a aplicação e registrar o que ficou temporariamente restrito.

Firewall, antivírus e backup: onde cada proteção ajuda

Na análise operacional da Gerati para esse cenário, as camadas de segurança precisam ter funções claras. Um firewall controla conexões; um WAF pode filtrar padrões de requisições web; ferramentas de proteção e monitoramento podem ajudar a detectar comportamentos suspeitos. Nenhuma dessas funções comprova que o código vulnerável foi corrigido.

Regras de proteção dependem de cobertura, configuração e atualização. Por isso, um painel sem alertas não deve ser usado como certificado de integridade do servidor. A confirmação de correção precisa existir separadamente.

Backups têm outro papel: apoiar a recuperação. Eles não impedem a exploração nem desfazem uma possível exposição de informações. O planejamento deve contemplar cópias protegidas contra alteração e exclusão, testes de restauração e a identificação de um ponto confiável para retorno.

Também vale reduzir o alcance de um possível incidente: separar aplicações, limitar permissões, evitar credenciais compartilhadas e controlar o acesso dos servidores a outros recursos. Essas medidas são recomendações de arquitetura defensiva, e não correções específicas para as duas CVEs.

E se houver suspeita de que o servidor já foi comprometido?

Atualizar e investigar são trabalhos diferentes. A atualização remove a vulnerabilidade corrigida, mas não comprova a remoção de alterações que um invasor eventualmente tenha feito antes.

Uma resposta operacional deve preservar registros e evidências, restringir a comunicação do ambiente suspeito de forma coordenada e investigar alterações não autorizadas. Arquivos novos, tarefas agendadas inesperadas, processos incomuns e conexões externas sem justificativa são exemplos de sinais que merecem análise; isoladamente, não provam uma invasão.

Quando houver evidência de comprometimento, a recuperação pode exigir reconstrução a partir de uma base confiável e troca das credenciais potencialmente expostas. A sequência importa: renovar segredos dentro de um ambiente ainda controlado pelo invasor pode expor os novos valores.

O responsável pelo incidente deve documentar o alcance confirmado, as incertezas, as medidas executadas e os critérios para retomada. Isso ajuda a empresa a tomar decisões com base em evidências, em vez de depender apenas da aparência normal do site.

Como evitar que a próxima atualização se transforme em crise

O episódio reforça uma necessidade de gestão: cada sistema precisa ter um responsável, uma política de atualização e um caminho de recuperação. A empresa deve saber quem recebe os alertas dos fornecedores, quem avalia o impacto e quem pode autorizar uma intervenção urgente.

Manter o inventário atualizado, retirar serviços sem uso e planejar a substituição de versões sem suporte reduz o volume de decisões improvisadas. Homologação e testes recorrentes também encurtam o intervalo entre a divulgação de uma correção e sua implantação segura.

Para o gestor, a pergunta mais útil não é apenas “nosso site usa PHP?”. É “conseguimos demonstrar quais serviços dependem dele, quem cuida deles e quando a correção foi validada?”. Essa resposta mostra o grau de controle que a empresa tem sobre sua operação digital.

Proteja a continuidade da sua operação

A Gerati pode apoiar sua empresa na avaliação do ambiente de TI e na organização das prioridades de proteção, em conjunto com os responsáveis pelas aplicações e pela hospedagem. Converse com nossa equipe para entender quais verificações e medidas fazem sentido para a sua operação.

Este artigo descreve o cenário apurado em 23/10/2026. Antes de executar mudanças, consulte os avisos atualizados do projeto PHP e do fornecedor responsável pelo ambiente.