Vulnerabilidades no PHP: O que são e como proteger seu site?

Se você tem um site hospedado em qualquer lugar, você precisa ler o que preparamos pra você!

Entre as vulnerabilidades descobertas nos últimos anos, a mais recente e que está relacionada à linguagem de programação PHP, é vista pelos especialistas na área como uma falha de alta prioridade global, seja pelos aspectos técnicos, seja porque cerca de 7 em cada websites no mundo é baseado nessa linguagem, direta ou indiretamente.

Vamos entender o que está acontecendo?

O que é o PHP?

O PHP é uma linguagem de programação de script interpretada, gratuita e de código aberto (open source), que é executada nos servidores que hospedam inúmeras aplicações Web e, que em 2026, responde direta ou indiretamente por aproximadamente 70% dos sites existentes no mundo.

Em termos práticos significa que:

O PHP funciona como um intermediador entre cada recurso presente no site (consultas de produtos, acessos às páginas, autenticações, etc) e o servidor que o hospeda;
Juntamente com o HTML, o PHP é responsável pelo que cada usuário vê conforme navega em cada página de um site;
É a linguagem de programação por trás do CMS mais usado do mundo – o WordPress – e dos seu plugins, mas também de outros CMS populares, como o Moodle, Drupal e o Magento;
Os mais diversos tipos de sites (institucionais, blogs, e-commerces, etc) são desenvolvidos diretamente em PHP e utilizam frameworks, ou indiretamente ao serem criados sobre um CMS que o tenha como linguagem.

Portanto, a probabilidade de você ter interesse neste assunto, é imensa!

Qual a vulnerabilidade do PHP?

Em 21 de outubro de 2026, tornou-se pública a notícia de duas vulnerabilidades críticas presentes no núcleo do PHP, descoberta pela empresa de cibersegurança Wiz, que classificou como as “falhas como as mais graves já detectadas por inteligência artificial”.

A Wiz informou que contou com o Gemini 4 Argon, do Google, e o GPT-5.6 Sol, da OpenAI, na identificação das duas vulnerabilidades.

As falhas foram “apelidadas” de PHP2Shell e identificadas como CVE-2026-109618 e CVE-2026-109619. Ambas receberam pontuação de severidade 9,2/10 e podem permitir execução remota de código sem autenticação em servidores vulneráveis.

As faixas de severidade qualitativa são:

Nenhuma (None) – 0.0;
Baixa (Low) – 0.1 a 3.9;
Média (Medium) – 4.0 a 6.9;
Alta (High) – 7.0 a 8.9;
Crítica (Critical) – 9.0 a 10.0 (aqui é onde estão ambas!)

Ou seja, essas vulnerabilidades estão próximas do limite máximo dessa “escala de gravidade” e, sendo assim, exigem medidas corretivas urgentes.

O grau de importância da questão se viu na prática no mundo todo. De sistemas de grandes empresas à sites governamentais, do ocidente ao oriente, muitos ficaram offline já no dia da descoberta, seja para evitar possíveis ataques, seja para aplicar medidas corretivas ou adicionar alguma camada adicional de proteção.

No Brasil, o Sistema Eletrônico de Informações (SEI) – que é a plataforma oficial do Governo Federal brasileiro para a gestão de documentos e processos administrativos em formato digital – também ficou indisponível, conforme informou a Anatel, além de vários sites governamentais que são desenvolvidos sobre PHP.

Equipes de suporte e cibersegurança estão tendo muito trabalho e correndo para aplicar correções, atualizar sistemas e fazer verificações. Os responsáveis técnicos têm afirmado que “fazia tempo que não víamos uma ameaça desse tipo”.

Detalhes das vulnerabilidades

Eis o resumo dos detalhes técnicos de cada falha descoberta:

CVE-2026-109618 – trata-se de uma vulnerabilidade de corrupção de memória causada por falha no tratamento de falta de memória (Out-of-Memory). Quando o PHP encontra falta de memória durante a inicialização da requisição, dados internos podem ficar incompletamente inicializados. Durante a limpeza subsequente, o PHP trata erroneamente esses dados como válidos, resultando em corrupção de memória, que pode ser explorada para executar código arbitrário;
CVE-2026-109619 – trata-se de uma vulnerabilidade de use-after-free (UAF). Quando o PHP falha ao redefinir adequadamente o estado global interno após o encerramento anormal de uma requisição, requisições subsequentes podem fazer referência a memória já liberada, levando a vazamento de informações ou execução de código

Qual o impacto das vulnerabilidades?

As consequências possíveis da exploração dessas vulnerabilidades, são:

Execução de código malicioso no servidor;
Instalação de backdoors;
Alteração de arquivos do site;
Leitura de dados que pertenciam a outros usuários;
Exposição de senhas, cookies ou tokens de autenticação;
Obtenção de chaves de API;
Em alguns cenários, comprometimento completo da hospedagem.

Assim, um hacker – na verdade um cracker – pode assumir o controle do servidor ou roubar informações do site explorando erros internos do próprio PHP, sem precisar explorar falhas do WordPress, plugins ou de qualquer outra camada de segurança, como um firewall.

Isso porque as vulnerabilidades afetam o próprio PHP, independentemente da aplicação utilizada.

No site do próprio PHP, o alerta menciona diferentes formas de execução do PHP em servidores Web, como PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed:

PHP-FPM – atualmente é a forma mais utilizada para executar PHP em servidores Linux. É comum em muitos hostings e em servidores com Nginx ou Apache. Não é um software de site, mas um mecanismo que gerencia processos PHP com foco em desempenho;
Apache com mod_php – é a integração tradicional entre o servidor Web Apache e o PHP. Nesse modelo, o PHP funciona diretamente dentro do próprio Apache. É o cenário considerado de maior risco para as vulnerabilidades recém-divulgadas;
php-cgi – método mais antigo de execução do PHP. Hoje é menos comum, mas ainda existe em alguns ambientes legados;
FrankenPHP – uma implementação mais recente que combina servidor Web e execução de PHP em um único serviço;
LiteSpeed – servidor Web bastante popular em empresas de hospedagem, especialmente em ambientes que executam WordPress visando máxima performance.

Apesar de se tratarem de tecnologias diferentes, todas têm a mesma função básica, que é receber a requisição do visitante e executar o código PHP do site. As falhas estão presentes nessa camada de execução do PHP, razão pela qual podem afetar diversos tipos de hospedagem e aplicações.

Como manter meu site seguro?

Nesse ponto, quando você já compreendeu a seriedade da questão, além de como ela pode ameaçar sua conta, a pergunta que falta responder, é: “Como manter sua conta segura?”.

É importante salientar que, como o ataque pode ocorrer antes que WordPress, Joomla, Laravel, Magento ou qualquer outra aplicação tenha a oportunidade de processar a requisição, manter plugins, temas e o CMS atualizados continua sendo importante, mas não elimina o risco se a versão do PHP que roda na sua conta estiver desatualizada. A correção precisa ser aplicada no próprio PHP.

Atualize para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Se você tem servidores na empresa rodando aplicações baseadas nesta linguagem, no site oficial do próprio PHP consta que já há downloads do código-fonte atualizado, bem como o código-fonte e os binários para Windows na mesma página.

Os muitos desenvolvedores das distribuições Linux também receberam as correções antecipadamente e, portanto, se há servidores Linux na empresa, cheque se há atualizações para a sua distro.

Vale alertar que o PHP 8.1 e versões anteriores não recebem mais atualizações do projeto PHP e, sendo assim, é fundamental atualizar o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Segundo o site do PHP, se por alguma razão não puder atualizar a versão do PHP imediatamente, as seguintes medidas reduzem a exposição a caminhos de ataque específicos, ainda que não tornem segura uma instalação:

Defina memory_limit=-1, preferencialmente de forma que os aplicativos não possam sobrescrever, como php_admin_value no pool FPM ou na configuração do Apache, e verifique se nenhuma configuração de pool, diretório ou aplicativo impõe um limite finito. Isso remove a falha controlável do limite de memória do PHP, mas uma falha de alocação subjacente ainda pode atingir o caminho vulnerável;
Defina um post_max_size baixo, para aplicativos que não exigem uploads de arquivos, defina “post_max_size = 8M”. Se os uploads de arquivos forem necessários, defina “post_max_size = 32M”. Mantenha upload_max_filesize abaixo de post_max_size. Considere impor limites no nível do servidor Web ou proxy para tamanho de solicitação decodificada, contagem de campos de entrada, contagem de partes multipart, contagem de cabeçalhos e profundidade de aninhamento. Esses limites também devem abranger solicitações sem um Content-Length utilizável.
Use um limite de contêiner ou cgroup como limite de disponibilidade, de preferência com uma política que encerre apenas o worker afetado. Não substitua RLIMIT_AS ou RLIMIT_DATA, pois isso pode causar a falha de alocação vulnerável;
Defina session.upload_progress.enabled=0 e reinicie cada worker. Use php.ini, um pool FPM ou uma configuração de servidor que se aplique antes da análise da requisição. Não dependa de ini_set() ou FPM .user.ini. Isso bloqueia os caminhos de sessão confirmados, mas não outras variantes;
No PHP 8.5, defina fatal_error_backtraces=0 e reinicie cada worker. Isso bloqueia apenas o caminho de backtrace fatal confirmado.
Remova configurações inválidas ou obsoletas aplicadas por requisição que emitem diagnósticos antes da inicialização. Ocultar diagnósticos com error_reporting, display_errors ou @ não ajuda.
Corrija erros fatais e timeouts de execução acessíveis por atacantes, incluindo falhas em callbacks, processamento de upload ou importação e limpeza.

ModSecurity ativo

O ModSecurity – ou outro WAF (Web Application Firewall) – ativo pode ajudar a reduzir a exposição bloqueando algumas requisições maliciosas antes que elas cheguem ao PHP. Diversos fornecedores de WAFs já publicaram regras emergenciais para tentar identificar e bloquear padrões de exploração do PHP2Shell.

Entretanto, saiba que nenhum WAF substitui ou evita a atualização do PHP!

As orientações publicadas pelos fornecedores e pesquisadores são claras em afirmar que a única correção completa é atualizar o PHP para uma versão corrigida. O WAF é uma camada adicional de defesa, mas não é a solução definitiva.

O ideal é PHP atualizado e ModSecurity ativo.

Se você usa cPanel/WHM, vale verificar se:

O ModSecurity está habilitado;
As regras OWASP ((Open Worldwide Application Security Project) ou do fornecedor foram atualizadas após a divulgação do PHP2Shell;
O PHP já foi atualizado para uma versão corrigida (8.5.12, 8.4.27, 8.3.36 ou 8.2.35, por ocasião desse post!).

Como verifico minha versão do PHP?

Depende de onde seu site está hospedado.

A seguir informamos as formas mais comuns de saber qual versão do PHP você está executando:

Linux (SSH)

Conecte-se via SSH ao servidor e execute:

php -v

Você deverá receber como saída algo como:

PHP 8.3.15 (cli)

Hospedagem com cPanel

Acesse o cPanel;
Procure por “Select PHP Version”, “PHP Selector” ou “MultiPHP Manager”;
A versão ativa será exibida na tela.

WordPress

Você pode verificar em:

Ferramentas > Saúde do site > Informações > Servidor;
Lá aparecerá algo como: “Versão do PHP: 8.3.15”.

Criando um arquivo de informação

Crie um arquivo chamado phpinfo.php e salve na pasta PUBLIC_HTML, com:

<?php
phpinfo();

Depois acesse: https://seusite.com.br/phpinfo.php

A página mostrará a versão exata do PHP e outras informações do ambiente. Após a verificação, lembre-se de remover esse arquivo por segurança.

O que o cliente HostMídia precisa fazer?

Desde que a informação sobre as vulnerabilidades foram conhecidas, os administradores e a equipe técnica da HostMídia interviram imediatamente para aplicar as correções nos servidores dedicados e VPSs de todos os clientes, bem como atualizaram as versões de PHP dos servidores compartilhados.

Sendo assim, se você tem um plano de hospedagem compartilhada na HostMídia, você deve acessar seu painel de controle para verificar qual versão está ativa e proceder com a alteração.

Há dois tutoriais a respeito:

Mas caso você tenha dúvidas ou não saiba como proceder, nosso suporte técnico está habilitado a ajudá-lo no processo.

Tenha em mente que independentemente dessa falha, manter as versões do PHP atualizadas, é uma prática altamente recomendável, seja para ajudar a manter seu site seguro, seja para que ele desempenhe melhor.

Conclusão

Em cenários de vulnerabilidades críticas como a PHP2Shell, a agilidade na resposta faz toda a diferença. Enquanto nossa equipe na HostMídia atua na retaguarda dos servidores, verificar sua versão do PHP e aplicar atualizações é o melhor caminho para proteger seu projeto. Precisa de ajuda? Nosso suporte está a postos!