O PHP é uma das linguagens de programação mais usadas do mundo. Já que ela serve como base para milhões de sites e aplicações web. Recentemente, duas vulnerabilidades críticas no núcleo de execução do PHP, conhecidas conjuntamente como PHP2Shell, chamaram a atenção de toda a comunidade de cibersegurança pela sua pontuação de severidade CVSS de 9.2. Nesse post, nós da Hosting Machine vamos falar mais sobre toda essa situação.
Vulnerabilidades no PHP
Quando e como as vulnerabilidades foram descobertas?
A divulgação técnica das vulnerabilidades ocorreu de forma prematura em 20 de outubro de 2026, quando detalhes sobre as falhas vazaram na internet antes do lançamento oficial das correções planejadas. Esse vazamento não coordenado gerou um alerta imediato em toda a indústria de segurança cibernética.
A descoberta das falhas envolveu pesquisas independentes de segurança, incluindo análises associadas à iniciativa Patch the Planet da OpenAI, além de investigações detalhadas conduzidas por especialistas das empresas Calif.io e Wiz.
Em resposta ao vazamento e ao risco iminente de ataques, a equipe oficial do PHP mobilizou um lançamento de emergência em 21 de outubro de 2026, disponibilizando versões atualizadas para todas as ramificações suportadas da linguagem. Em poucas horas depois da publicação das correções, redes globais de sensores e monitoramento já registravam diversas tentativas ativas de exploração contra servidores expostos na internet.
O que é a vulnerabilidade CVE-2026-109618?
Identificada como CVE-2026-109618, essa vulnerabilidade crítica está no mecanismo interno do PHP que trata erros de memória esgotada (Out-of-Memory ou OOM) durante o processamento de requisições HTTP. Em suma, quando o PHP atinge o limite de memória ao analisar os parâmetros ou o corpo de uma requisição, ele interrompe abruptamente a execução utilizando a função de biblioteca longjmp().
No entanto, o problema é que a função longjmp() encerra o fluxo de execução sem permitir que as rotinas normais de limpeza da memória sejam concluídas. Por conta disso, certas estruturas de dados internas continuam em um estado parcialmente inicializado ou inconsistente no momento em que a requisição é cancelada.
Durante a etapa de encerramento do pedido, a rotina de limpeza tenta ler ou redirecionar a execução utilizando esses ponteiros inválidos. Assim, um atacante remoto não autenticado pode enviar requisições HTTP preparadas para induzir a condição de OOM e manipular o layout da memória. Dessa forma, a falha permite alcançar a execução remota de código (RCE) no servidor web, permitindo que o invasor assuma o controle do processo e execute comandos com os privilégios da aplicação.
O que é a vulnerabilidade CVE-2026-109619?
Sendo identificada como CVE-2026-109619, essa vulnerabilidade crítica está relacionada à retenção incorreta de referências na memória global do motor Zend do PHP. Isto é porque, durante o processamento de uma requisição web, o PHP usa estados globais que apontam temporariamente para blocos de memória alocados especificamente para aquele pedido.
Entretanto, em casos específicos de erro ou interrupção, o programa não limpa corretamente esses estados globais ou os repovoa inadequadamente depois da limpeza. Com isso, o programa mantém as variáveis globais apontando para regiões de memória que o sistema operacional já liberou, caracterizando uma falha do tipo Use-After-Free.
Dai quando o mesmo processo do PHP atende uma requisição posterior, ele tenta operar sobre esse estado global obsoleto antes que ele seja reinicializado. O atacante pode explorar essa vulnerabilidade para obter execução remota de um código. Além de poder usá-la para fazer vazamento de dados confidenciais armazenados na memória, como as chaves de API, senhas e tokens de sessão.
Como essas vulnerabilidades afetam o PHP?
Essas vulnerabilidades afetam diretamente o motor interno do PHP. Consequentemente colocando em risco praticamente qualquer infraestrutura web que use PHP para processar requisições de usuários. Como as falhas estão situadas nos mecanismos de gestão de memória do Zend Engine, o perigo não depende do código da aplicação instalada. Ele vai afetando desde sistemas CMS populares até plataformas empresariais complexas.
No entanto, o nível de exposição e a facilidade de exploração variam de acordo com o modo de integração do PHP no servidor web. Os ambientes que usam o servidor Apache junto com o módulo mod_php, por exemplo, enfrentam um risco extremamente elevado. Isto acontece porque um atacante não autenticado consegue explorar a vulnerabilidade antes mesmo que a aplicação processe qualquer arquivo ou script. Já em arquiteturas baseadas em PHP-FPM, php-cgi, LiteSpeed ou FrankenPHP, o perigo decorre do reaproveitamento constante dos processos workers. Pois isso faz com que um estado de memória corrompido afete diretamente todos os pedidos subsequentes.
Além disso, elas também impactam gerenciadores de conteúdo populares, como WordPress, Drupal, Joomla e Magento, e até se estendeu a softwares corporativos e painéis de hospedagem. Alguns fabricantes como a Palo Alto Networks confirmaram impacto nas interfaces de gestão do PAN-OS. Já os ambientes de hospedagem geridos por cPanel, WHM e CloudLinux precisaram aplicar correções imediatas para conter o risco de invasão. Aqui na Hosting Machine nós já aplicamos todas as correções e patches de segurança.
O que pode ser feito para se proteger?
A principal e mais eficaz medida de proteção consiste em atualizar imediatamente todas as instalações do PHP para uma das versões corrigidas oficiais que o projeto disponibilizou: 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Em ambientes de hospedagem geridos por painéis como o cPanel, deve-se executar a atualização dos pacotes do sistema e reiniciar todos os serviços web e processos workers para garantir que o novo código entre em vigor na memória.
Caso você não consiga realizar a atualização imediatamente, adote medidas temporárias de mitigação por meio de configurações no arquivo php.ini. A alteração da diretiva session.upload_progress.enabled = Off reduz a exposição aos principais caminhos de ataque conhecidos. Além disso, recomenda-se restringir o acesso a interfaces administrativas e monitorar a execução de processos filhos anômalos iniciados pelos processos do PHP.
Como a Hosting Machine tratou essa vulnerabilidade do PHP?
Na Hosting Machine, a segurança e a tranquilidade dos nossos clientes são prioridades. Por isso, diante da identificação dessas vulnerabilidades, nossa equipe técnica agiu prontamente e realizou todas as atualizações e correções de segurança necessárias em nossa infraestrutura, aplicando os patches disponibilizados para garantir a proteção dos ambientes de hospedagem. Dessa forma, nossos clientes podem ficar tranquilos: as medidas preventivas e corretivas já foram implementadas, mantendo nossos servidores protegidos contra as ameaças identificadas. Seguimos monitorando continuamente nossos ambientes para garantir a segurança, a estabilidade e a confiabilidade dos serviços oferecidos.
