Quem administra um site sabe que manter o servidor atualizado é uma tarefa que nunca termina. Quando tudo parece estar funcionando perfeitamente, surge uma nova atualização de segurança para lembrar que tranquilidade e tecnologia nem sempre caminham juntas.
Foi exatamente isso que aconteceu nesta semana com o PHP, uma das linguagens mais utilizadas no desenvolvimento de aplicações web e responsável pelo funcionamento de plataformas como WordPress, WooCommerce e inúmeros sistemas espalhados pela internet.
No dia 21 de outubro de 2026, o projeto PHP disponibilizou correções para duas vulnerabilidades críticas, identificadas como CVE-2026-109618 e CVE-2026-109619. Ambas receberam pontuação de 9,2 em uma escala de gravidade que vai até 10.
Como se duas falhas críticas não fossem suficientes, no dia 23 de outubro uma terceira vulnerabilidade, CVE-2026-115560, também foi divulgada.
O problema ganhou ainda mais atenção após a Hostinger publicar um comunicado alertando seus clientes, especialmente aqueles que utilizam servidores VPS.
E existe um detalhe importante nessa história: ter o WordPress atualizado não significa necessariamente que seu servidor esteja protegido.
O que aconteceu com o PHP?
As duas primeiras vulnerabilidades, conhecidas em conjunto como php2shell, estão relacionadas a problemas no gerenciamento de memória do PHP.
Em determinadas circunstâncias, falhas no tratamento de requisições podem provocar comportamentos inesperados na aplicação e abrir espaço para ataques.
A CVE-2026-109618 envolve uma situação em que o PHP atinge seu limite de memória durante o processamento de uma requisição. Dependendo do momento em que isso acontece, estruturas internas podem permanecer em um estado inconsistente.
Já a CVE-2026-109619 está relacionada ao uso de memória que já foi liberada. Esse tipo de falha, conhecido como use after free, pode permitir que informações sejam acessadas indevidamente ou que o funcionamento do processo seja comprometido.
Em cenários de exploração, as consequências podem incluir execução de código malicioso, acesso indevido a informações e indisponibilidade de serviços.
E aqui está o ponto que merece atenção: não estamos falando de uma vulnerabilidade em um plugin desconhecido ou em um tema abandonado há anos. Estamos falando de falhas no próprio PHP.
Isso significa que aplicações perfeitamente atualizadas também podem estar expostas quando executadas sobre versões vulneráveis da linguagem.
Quais versões do PHP foram afetadas?
Segundo o comunicado publicado pela Hostinger, as vulnerabilidades afetam versões anteriores às atualizações de segurança disponibilizadas em 21 de outubro.
As versões corrigidas são PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 e PHP 8.5.12.
Versões anteriores também podem estar vulneráveis, incluindo edições antigas que já não recebem manutenção oficial do projeto PHP.
Esse é um problema especialmente relevante para quem mantém aplicações legadas.
É comum encontrar servidores executando PHP 7.4, 8.0 ou 8.1 simplesmente porque determinados sistemas nunca foram adaptados às versões mais recentes. O problema é que compatibilidade não é sinônimo de segurança.
Uma aplicação continuar funcionando em uma versão antiga não significa que aquela versão seja adequada para permanecer exposta à internet.
Uma terceira vulnerabilidade complicou ainda mais a situação
No dia 23 de outubro, o projeto PHP divulgou a CVE-2026-115560, acrescentando uma nova preocupação para administradores de servidores.
Diferentemente das duas vulnerabilidades anteriores, essa terceira falha ainda não possuía uma correção definitiva disponível no momento do comunicado.
A recomendação emergencial foi desativar um recurso do PHP responsável pelo acompanhamento do progresso de uploads utilizando sessões.
A configuração indicada é:
session.upload_progress.enabled = OffEmbora pareça uma alteração simples, existe um detalhe que não pode ser ignorado.
A configuração precisa ser realizada no arquivo php.ini ou no ambiente de execução correspondente, seguida da reinicialização dos processos PHP para que a alteração seja efetivamente aplicada.
Modificar essa opção dentro do código da aplicação utilizando ini_set() não resolve o problema.
A Hostinger informou que a desativação desse recurso protege contra a nova vulnerabilidade enquanto uma correção definitiva não é disponibilizada.
É uma medida preventiva importante, especialmente porque a maioria dos sites não depende dessa funcionalidade específica para realizar uploads convencionais.
Hostinger protege hospedagens compartilhadas, mas usuários de VPS precisam agir
A Hostinger informou que implementou medidas de proteção em sua infraestrutura de hospedagem gerenciada.
Entre as ações realizadas estão a atualização das versões do PHP, a implementação de regras adicionais de firewall e a desativação do recurso de progresso de upload baseado em sessões.
Segundo a empresa, as correções para as duas primeiras vulnerabilidades foram distribuídas em seus servidores gerenciados até o dia 22 de outubro.
Entretanto, existe uma diferença fundamental entre contratar uma hospedagem convencional e administrar uma VPS.
Na hospedagem gerenciada, a empresa assume a responsabilidade por determinadas atualizações da infraestrutura.
Em uma VPS autogerenciada, essa responsabilidade geralmente pertence ao administrador do servidor.
Em outras palavras, contratar uma VPS não significa contratar alguém para cuidar automaticamente de todas as atualizações.
O servidor é seu. A responsabilidade também.
Continua depois da publicidade
E é justamente nesse cenário que ferramentas como CyberPanel, OpenLiteSpeed e outros painéis de gerenciamento exigem atenção adicional.
CyberPanel e OpenLiteSpeed: atenção às diferentes versões do PHP
Quem utiliza CyberPanel normalmente trabalha com OpenLiteSpeed, um servidor web que pode executar diferentes versões do PHP por meio do LSAPI.
Isso permite que um mesmo servidor hospede sites utilizando versões distintas da linguagem.
Na prática, é possível encontrar uma VPS com PHP 7.4 configurado no terminal, enquanto os sites publicados utilizam PHP 8.5.
Essa diferença é importante porque executar php -v no SSH não necessariamente revela a versão utilizada pelos visitantes do site.
Em uma verificação recente em um ambiente com CyberPanel, por exemplo, identificamos sete versões do PHP instaladas, desde a 7.4 até a 8.5.
Apesar disso, os dois sites hospedados naquele servidor estavam configurados para utilizar PHP 8.5.
A descoberta foi possível analisando os processos e registros do OpenLiteSpeed, que indicavam os executáveis PHP associados a cada domínio.
Esse tipo de verificação evita uma situação relativamente comum: atualizar a versão errada do PHP e acreditar que o problema foi resolvido.
Como proteger uma VPS com CyberPanel
O primeiro passo é identificar quais versões do PHP estão instaladas e quais delas são efetivamente utilizadas pelos sites.
Em servidores com OpenLiteSpeed, os arquivos de configuração normalmente ficam em diretórios semelhantes a /usr/local/lsws/lsphp85/etc/php.ini, variando conforme a versão instalada.
Antes de realizar qualquer alteração, é fundamental criar uma cópia de segurança dos arquivos de configuração.
Para mitigar a vulnerabilidade CVE-2026-115560, a orientação publicada pela Hostinger é definir explicitamente a opção de progresso de upload como desativada.
É importante observar que encontrar uma linha como ;session.upload_progress.enabled = On não significa que o recurso esteja desligado.
O ponto e vírgula indica que aquela configuração está comentada. Nesse caso, o PHP pode continuar utilizando o valor padrão, que é ativado.
Após realizar a alteração, os processos PHP precisam carregar a nova configuração.
No OpenLiteSpeed, isso exige atenção ao funcionamento dos processos LS PHP, que não necessariamente seguem os mesmos procedimentos utilizados em ambientes com PHP-FPM.
Também é recomendável validar a configuração efetiva no ambiente web, em vez de confiar exclusivamente no conteúdo do arquivo php.ini.
Por fim, a atualização do PHP continua indispensável para corrigir as duas primeiras vulnerabilidades.
Desativar o progresso de upload não substitui a instalação das versões corrigidas.
Reiniciar o PHP pode deixar o site temporariamente lento?
Durante a aplicação das medidas de proteção em um servidor com CyberPanel, observamos um comportamento que merece ser compartilhado.
Após solicitar a reinicialização dos processos PHP, os sites apresentaram lentidão temporária.
A análise dos registros do OpenLiteSpeed mostrou que os processos antigos haviam sido encerrados e novos processos estavam sendo inicializados.
O consumo de CPU permanecia baixo, havia memória disponível e não foram identificados erros críticos nos registros examinados.
Pouco tempo depois, o funcionamento dos sites aparentemente voltou ao normal.
Isso não significa que toda reinicialização do PHP provoque lentidão. Entretanto, mostra por que alterações em ambientes de produção precisam ser acompanhadas de verificações.
Em determinados cenários, a recriação dos processos, a inicialização das aplicações e o aquecimento dos mecanismos de cache podem afetar temporariamente o tempo de resposta.
O importante é não confundir um comportamento transitório com uma falha permanente, nem reiniciar repetidamente o servidor sem investigar a causa.
Firewall ajuda, mas não substitui atualização
Uma das medidas adotadas pela Hostinger foi implementar regras de firewall para bloquear padrões conhecidos de exploração.
Esse tipo de proteção é extremamente importante, principalmente quando vulnerabilidades começam a ser exploradas antes que todos os administradores consigam atualizar seus servidores.
Entretanto, um firewall não corrige o problema existente no código do PHP. Ele funciona como uma camada adicional de defesa.
Se um atacante encontrar uma forma diferente de explorar a vulnerabilidade, uma regra criada para bloquear determinado padrão pode não ser suficiente.
Por isso, a combinação entre atualização do PHP, configurações seguras e monitoramento contínuo continua sendo a abordagem mais adequada. Segurança não deveria depender de uma única barreira.
O que esperar das próximas atualizações?
A CVE-2026-115560 ainda aguardava uma correção definitiva no momento da atualização do comunicado da Hostinger, em 23 de outubro de 2026.
O projeto PHP informou que a solução seria incluída em uma próxima versão regular.
Até lá, a recomendação é manter desativado o progresso de upload baseado em sessões, acompanhar os comunicados oficiais e verificar periodicamente as atualizações disponíveis para o ambiente utilizado.
Também vale lembrar que o PHP 8.2 está previsto para encerrar seu período de atualizações de segurança em 31 de dezembro de 2026.
Administradores que ainda dependem dessa versão devem começar a planejar a migração para uma edição mais recente e compatível com suas aplicações.
Segurança não é apenas instalar atualizações
O episódio envolvendo essas três vulnerabilidades deixa uma lição importante. Manter um site seguro não depende exclusivamente de atualizar plugins, instalar um certificado SSL ou contratar uma hospedagem conhecida.
É necessário compreender minimamente a infraestrutura que sustenta a aplicação.
Isso inclui saber qual versão do PHP está em execução, como os processos são gerenciados, quais serviços estão expostos e quem é responsável pelas atualizações.
No caso de servidores VPS, essa responsabilidade merece atenção redobrada.
Afinal, de pouco adianta investir tempo e dinheiro em um site se a infraestrutura que mantém tudo funcionando permanece vulnerável.
E quando o assunto é segurança, descobrir um problema por meio de um comunicado oficial ainda é muito melhor do que descobrir depois de uma invasão.
