Duas vulnerabilidades críticas no PHP acenderam um alerta para administradores de servidores, desenvolvedores e proprietários de sites. Identificadas como CVE-2026-109618 e CVE-2026-109619, as falhas podem permitir a execução remota de código sem autenticação em ambientes vulneráveis, colocando sites e aplicações web em risco.
O problema merece atenção especial porque o PHP é utilizado por milhões de sites, incluindo projetos desenvolvidos com WordPress, lojas virtuais, sistemas de gerenciamento de conteúdo e aplicações empresariais.
A principal recomendação é atualizar o PHP para uma versão corrigida o mais rápido possível. Quando a atualização imediata não for viável, existem medidas temporárias que podem ajudar a reduzir a exposição, mas nenhuma delas deve ser considerada uma substituição definitiva da correção.
Neste artigo, você vai entender o que são essas vulnerabilidades, quais versões do PHP receberam correções e quais medidas devem ser adotadas para proteger seu site.
Índice
O que são as vulnerabilidades CVE-2026-109618 e CVE-2026-109619?
O PHP é uma linguagem de programação utilizada principalmente no desenvolvimento de aplicações web. Quando um visitante acessa um site desenvolvido nessa linguagem, o servidor executa o código PHP para gerar páginas, processar informações e realizar operações no sistema.
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 afetam o funcionamento interno do PHP e podem permitir que um invasor execute código remotamente sem precisar autenticar-se previamente, dependendo das condições do ambiente vulnerável.
As duas falhas receberam classificação crítica, com pontuação CVSS de 9,2 em 10.
Embora tenham consequências semelhantes, suas causas técnicas são diferentes:
- CVE-2026-109618: envolve corrupção de memória associada a situações de falta de memória (Out of Memory), durante o processamento de determinadas solicitações.
- CVE-2026-109619: envolve uma condição conhecida como use-after-free, na qual o programa pode acessar um estado interno relacionado a uma região de memória que já deveria ter sido liberada.
Uma exploração bem-sucedida pode comprometer a execução da aplicação e, dependendo das permissões do processo afetado, permitir acesso a recursos do servidor.
Isso não significa que todos os sites que utilizam PHP já tenham sido invadidos. Entretanto, servidores que executam versões vulneráveis e aceitam solicitações de fontes não confiáveis devem ser tratados como prioritários para atualização.
Fontes oficiais:
Quais versões do PHP foram corrigidas?
O projeto PHP publicou versões atualizadas para corrigir as duas vulnerabilidades.
| Versão do PHP | Versão mínima corrigida |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Se você utiliza PHP 8.3.35, por exemplo, deve atualizar para a versão 8.3.36 ou uma versão posterior corrigida dessa linha.
Esses números correspondem aos lançamentos oficiais do projeto PHP. Em alguns ambientes, fornecedores podem disponibilizar correções de segurança incorporadas a pacotes que mantêm uma numeração diferente. Nesses casos, consulte a documentação oficial do fornecedor para confirmar se as duas vulnerabilidades foram corrigidas.
Atenção: utilizar uma versão antiga do PHP pode representar um risco adicional. O PHP 8.1 e as versões anteriores não recebem atualizações de segurança diretamente do projeto PHP. Embora alguns fornecedores possam disponibilizar correções específicas, isso não significa que todas as instalações antigas estejam protegidas.
Além de instalar as correções para essas vulnerabilidades, é recomendável planejar a migração para uma versão do PHP que ainda receba atualizações de segurança. A compatibilidade com o site e suas aplicações deve ser verificada antes da mudança.
Para consultar os lançamentos e avisos oficiais, acesse php.net.
Como essas vulnerabilidades podem afetar um site?
O impacto depende da versão do PHP, da configuração do servidor e das permissões disponíveis para a aplicação.
Entre os riscos de uma exploração bem-sucedida estão:
- Execução de código não autorizado no ambiente afetado.
- Comprometimento de arquivos e componentes da aplicação.
- Acesso indevido a informações disponíveis para o processo vulnerável.
- Utilização do site comprometido como ponto de partida para outras atividades maliciosas.
- Interrupção do funcionamento da aplicação e possíveis prejuízos operacionais.
Sites desenvolvidos em WordPress também merecem atenção. Entretanto, é importante compreender que essas falhas estão relacionadas ao ambiente de execução do PHP, e não exclusivamente ao WordPress.
Por isso, manter apenas o sistema de gerenciamento de conteúdo atualizado não resolve o problema se o servidor continuar executando uma versão vulnerável do PHP.
E se não for possível atualizar imediatamente?
A atualização para uma versão corrigida continua sendo a medida mais importante. Porém, em alguns ambientes, a mudança pode depender de testes de compatibilidade, manutenção programada ou da disponibilização de uma correção pelo fornecedor.
Nesses casos, algumas medidas temporárias podem ajudar a reduzir a exposição.
1. Utilize um WAF com regras de segurança atualizadas
Um firewall de aplicações web, conhecido como WAF (Web Application Firewall), pode ajudar a identificar e bloquear determinadas solicitações maliciosas antes que elas cheguem à aplicação.
Verifique se as regras de segurança estão atualizadas e se contemplam as ameaças relacionadas às vulnerabilidades em questão.
No entanto, um WAF não consegue garantir o bloqueio de todas as formas possíveis de exploração. A eficácia depende das regras utilizadas, da configuração e das características do tráfego recebido.
2. Restrinja o acesso sempre que possível
Se a aplicação não precisa receber solicitações de qualquer origem, avalie restringir o acesso por endereço IP, VPN, autenticação adicional ou outras medidas apropriadas ao serviço.
Quando aplicável, desative temporariamente funcionalidades ou pontos de entrada que não sejam essenciais e que aumentem a exposição.
Essas medidas devem ser planejadas para evitar interrupções indevidas. Em sites públicos, simplesmente bloquear visitantes não é uma solução viável para todos os cenários.
3. Avalie a possibilidade de suspender temporariamente o serviço vulnerável
Se o ambiente estiver exposto à internet, não houver correção disponível e o risco for considerado elevado, retirar temporariamente a aplicação do ar pode ser mais seguro do que mantê-la acessível sem proteção adequada.
Essa decisão deve considerar a criticidade do serviço, os impactos operacionais e a existência de alternativas seguras.
4. Siga as recomendações oficiais antes de alterar parâmetros do PHP
Alguns avisos de segurança podem indicar ajustes de configuração como mitigação temporária. Entretanto, uma configuração recomendada para uma vulnerabilidade específica pode não resolver a outra.
No caso da CVE-2026-109618, o aviso oficial discute o parâmetro memory_limit como parte de uma possível mitigação temporária. Alterar esse parâmetro para -1, porém, remove o limite de memória por solicitação e pode aumentar o risco de consumo excessivo de recursos. Essa mudança não deve ser aplicada indiscriminadamente, principalmente em ambientes compartilhados.
Não existe uma configuração genérica que possa ser recomendada com segurança para todos os servidores e que elimine o risco das duas vulnerabilidades.
Importante: regras de WAF, restrições de acesso e ajustes de configuração são medidas de redução de risco, não garantias de proteção. Elas não substituem a atualização do PHP para uma versão corrigida.
Como mitigar temporariamente as vulnerabilidades do PHP?
A recomendação principal é atualizar o PHP para uma versão corrigida. Entretanto, se a atualização não puder ser realizada imediatamente, algumas configurações podem ajudar a reduzir a exposição do servidor enquanto a correção definitiva é preparada.
Uma das medidas temporárias discutidas após a divulgação das vulnerabilidades é desativar o recurso de acompanhamento do progresso de uploads de arquivos do PHP.
1. Desative o session.upload_progress
O PHP possui um recurso chamado session.upload_progress, utilizado para acompanhar o progresso de determinados uploads de arquivos. Esse recurso pode ser desativado por meio da seguinte configuração:
session.upload_progress.enabled = OffA configuração deve ser aplicada em um arquivo php.ini efetivamente utilizado pelo ambiente ou em uma configuração administrativa do PHP-FPM ou do servidor web, conforme a arquitetura da instalação. Depois da alteração, os processos PHP precisam ser reiniciados ou recarregados conforme o procedimento adequado ao ambiente.
Atenção: alterar essa configuração em um arquivo que não é utilizado pelo site não produzirá o efeito esperado. Além disso, configurações definidas apenas durante a execução do script podem ser aplicadas tarde demais para impedir o processamento inicial da solicitação.
Desativar esse recurso pode afetar funcionalidades que dependem especificamente das informações de progresso de upload. Por isso, teste o comportamento da aplicação após a mudança.
2. Entenda as limitações dessa medida
Desativar session.upload_progress.enabled é uma medida temporária de redução de risco, não uma correção definitiva. Ela pode bloquear determinados caminhos de exploração associados ao processamento de uploads, mas não há garantia de que impeça todas as variantes possíveis das duas vulnerabilidades.
Outras medidas, como utilizar um WAF com regras atualizadas, restringir o acesso quando possível e limitar solicitações de upload desnecessárias, também podem ajudar a diminuir a exposição. Entretanto, sua eficácia depende do ambiente e da configuração utilizada.
Não presuma que o site está seguro apenas porque essa opção foi desativada.
3. Atualize o PHP assim que possível
A correção definitiva é instalar uma versão corrigida do PHP ou um pacote que contenha oficialmente as correções para CVE-2026-109618 e CVE-2026-109619.
As versões mínimas corrigidas pelo projeto PHP são:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
Após a atualização, confirme qual versão está sendo utilizada pela aplicação e verifique se os processos PHP estão executando os componentes corrigidos.
Se o servidor utiliza uma versão antiga que já não recebe atualizações oficiais do projeto PHP, planeje a migração para uma linha suportada.
Importante: não considere a mitigação temporária equivalente à atualização. Enquanto o ambiente permanecer vulnerável, o risco residual continua existindo. Se não houver possibilidade de corrigir o sistema e a exposição for elevada, avalie restringir ou suspender temporariamente o serviço até que seja possível aplicar uma solução adequada.
Consulte os avisos oficiais de segurança do PHP e a documentação de mitigação antes de alterar configurações em produção.
WordPress: mantenha o núcleo, os plugins e os temas atualizados
Além de corrigir o PHP, quem utiliza WordPress deve manter todos os componentes da aplicação atualizados.
Um site pode estar executando uma versão corrigida do PHP e, ainda assim, permanecer vulnerável por causa de um plugin desatualizado, um tema com falhas conhecidas ou uma instalação antiga do próprio WordPress.
Siga estas recomendações:
- WordPress: instale as atualizações estáveis que corrigem falhas de segurança e outros problemas conhecidos.
- Plugins: atualize as extensões utilizadas e remova aquelas que não são mais necessárias.
- Temas: mantenha o tema ativo e os demais componentes instalados atualizados, removendo os que não são utilizados.
- Compatibilidade: verifique se os componentes funcionam corretamente com a versão do PHP escolhida.
- Procedência: evite temas e plugins de fontes não confiáveis ou sem manutenção.
Sempre que possível, teste as atualizações em um ambiente de homologação antes de aplicá-las em sites críticos.
Lembre-se: atualizar o WordPress não corrige uma versão vulnerável do PHP, assim como atualizar o PHP não corrige automaticamente falhas nos plugins, temas ou no próprio WordPress. A segurança exige a manutenção de todas essas camadas.
Por que o backup é indispensável?
Antes de atualizar o PHP ou realizar alterações importantes no site, faça um backup completo.
Uma mudança de versão pode revelar incompatibilidades em códigos antigos, plugins personalizados ou temas. Além disso, se houver suspeita de comprometimento, uma cópia confiável pode ser importante para investigar o incidente e recuperar dados.
Um bom plano de backup deve incluir:
- Arquivos: código do site, temas, plugins, imagens, documentos e arquivos de configuração necessários.
- Banco de dados: publicações, páginas, usuários, configurações, pedidos e demais informações armazenadas.
- Cópia independente: mantenha uma cópia separada do ambiente de produção, preferencialmente com proteção contra alterações indevidas.
- Histórico de versões: preserve cópias de períodos diferentes para permitir a recuperação de um estado anterior.
- Teste de restauração: confirme que os arquivos e o banco de dados podem ser recuperados corretamente.
Não basta configurar um backup automático. É necessário verificar se ele está sendo concluído sem erros e se a restauração funciona.
Se houver suspeita de invasão, preserve evidências antes de sobrescrever arquivos ou restaurar o ambiente. Restaurar uma cópia antiga também não elimina a vulnerabilidade do PHP. Antes de colocar o site novamente em operação, corrija a causa do problema e investigue possíveis sinais de comprometimento.
Conclusão
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 reforçam a importância de manter o ambiente de execução das aplicações sempre atualizado.
Como as falhas podem permitir a execução remota de código sem autenticação, servidores expostos que executam versões vulneráveis devem receber atenção prioritária. A atualização do PHP é a principal medida de correção, enquanto WAF, restrições de acesso e outros controles podem ajudar a reduzir temporariamente a exposição.
Também é fundamental manter o WordPress, os plugins e os temas atualizados, além de contar com backups confiáveis e testados.
Não confunda mitigação com correção definitiva. Medidas temporárias podem reduzir o risco, mas não garantem proteção absoluta. A prioridade deve ser instalar uma versão corrigida e verificar se o ambiente está efetivamente protegido.
Perguntas frequentes
Quais são as falhas CVE-2026-109618 e CVE-2026-109619?
São vulnerabilidades críticas no PHP que podem permitir a execução remota de código sem autenticação em ambientes afetados.
Quais versões do PHP corrigem as falhas?
As versões mínimas publicadas pelo projeto PHP são 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Consulte o fornecedor do seu ambiente para confirmar se o pacote instalado contém as correções.
O que fazer se não for possível atualizar o PHP imediatamente?
Avalie medidas temporárias, como regras atualizadas de WAF, restrições de acesso e redução da exposição da aplicação. Essas medidas não substituem a correção oficial e não garantem proteção absoluta. Em ambientes de risco elevado, pode ser necessário suspender temporariamente o serviço.
Atualizar o WordPress resolve essas vulnerabilidades?
Não. As falhas estão no PHP. É necessário corrigir o ambiente de execução e, separadamente, manter o WordPress, os plugins e os temas atualizados.
Por que fazer backup antes de atualizar?
O backup permite recuperar arquivos e dados caso ocorram incompatibilidades ou outros problemas durante a manutenção. As cópias devem ser verificadas e testadas periodicamente.
Versões antigas do PHP devem ser atualizadas?
Sim. O PHP 8.1 e versões anteriores não recebem atualizações diretamente do projeto PHP. A recomendação é migrar para uma linha ainda suportada e confirmar que as correções necessárias estão instaladas.
Fontes oficiais
