Em 21 de outubro de 2026, duas vulnerabilidades críticas foram divulgadas no núcleo do PHP, batizadas de PHP2Shell. Com pontuação de gravidade 9,2 de 10 na escala CVSS, elas permitem que um atacante execute código no seu servidor sem precisar de login ou senha. Qualquer site que rode PHP em versão anterior às atualizações de correção está exposto, incluindo WordPress, WooCommerce, Magento, Joomla e Drupal.
Ontem de manhã, a Anatel tirou sistemas do ar como medida preventiva. Tribunais brasileiros suspenderam o acesso às suas plataformas por precaução. Sistemas governamentais em Portugal, Espanha e no Reino Unido foram retirados de operação enquanto os times técnicos avaliavam a exposição. Nenhuma dessas organizações confirmou invasão. Mas todas entenderam que o risco era alto o suficiente para sair do ar antes de ser comprometidas. Tudo isso por causa de uma falha em uma linguagem de programação que, segundo a W3Techs, sustenta 69,3% dos sites com linguagem de servidor identificável na internet.
Essa linguagem é o PHP.
Se você tem um site, uma loja virtual ou um sistema web, provavelmente está usando PHP. Se esse PHP não foi atualizado nas últimas horas, você tem um trabalho urgente pela frente.
Esse artigo explica o que aconteceu, como saber se o seu site está vulnerável, o que fazer agora e como evitar que isso se repita.
O que é o PHP2Shell e por que seu site pode estar em risco
PHP2Shell é o nome coletivo dado a duas vulnerabilidades críticas de execução remota de código (RCE) descobertas no núcleo do PHP. Um atacante pode enviar uma requisição HTTP maliciosa para um servidor vulnerável e, sem nenhuma autenticação, executar comandos arbitrários. Isso inclui instalar arquivos maliciosos, acessar bancos de dados, roubar credenciais ou derrubar o site inteiro.
As duas falhas são:
CVE-2026-109618: quando o PHP fica sem memória ao processar uma requisição, especialmente uploads via POST, o processo de limpeza lê dados não inicializados. Um atacante pode induzir esse estado com uma requisição construída para esse fim e executar código no servidor.
CVE-2026-109619: quando o mesmo processo PHP processa requisições consecutivas, dados de uma requisição anterior podem vazar para a seguinte. Isso permite bypass de autenticação e execução remota de código.
O que torna isso diferente de vulnerabilidades comuns em plugins do WordPress é o seguinte: o problema está no runtime do PHP, não no código da sua aplicação. Mesmo que o seu site esteja com todos os plugins atualizados e o WordPress na versão mais recente, se o PHP do servidor não foi corrigido, o site continua exposto.
E a máquina concorda com isso toda vez que um scanner de segurança bypassa a aplicação e vai direto ao runtime.
Quais sites estão em risco
Estão expostos todos os servidores que rodam PHP em modo de atendimento web, incluindo:
- Apache com mod_php (risco considerado o mais alto)
- PHP-FPM com Nginx
- php-cgi
- FrankenPHP
- LiteSpeed com PHP
Em termos de plataformas, qualquer site feito em WordPress, WooCommerce, Magento, PrestaShop, Joomla, Drupal, Laravel ou frameworks PHP customizados está sujeito à falha se o runtime não foi atualizado.
As versões afetadas incluem PHP 5.x, 7.x e toda a família 8.x até as versões de correção publicadas em 21 de outubro de 2026.
| Versão PHP | Versão corrigida |
|---|---|
| 8.2.x | 8.2.35 |
| 8.3.x | 8.3.36 |
| 8.4.x | 8.4.27 |
| 8.5.x | 8.5.12 |
PHP 8.1 e versões anteriores estão fora de suporte oficial do projeto PHP. Para PHP 8.0 e 8.1, não há patch público do time do PHP, mas alguns fornecedores de hospedagem publicaram builds corrigidas de forma independente. A Plesk, por exemplo, distribuiu correções especiais para essas versões no Linux. Se você usa hospedagem gerenciada e ainda está em PHP 8.1, pergunte ao suporte se existe um backport disponível. Mesmo assim, a recomendação definitiva é migrar para uma ramificação ativamente suportada.
Como verificar a versão do PHP do seu site agora
Pílula de resposta: A forma mais confiável de verificar o PHP que seu site efetivamente usa é criar um arquivo temporário info.php com <?php phpinfo(); no diretório público, acessar pelo navegador e anotar a versão exibida. Delete o arquivo imediatamente depois. O comando php -v no terminal mostra a versão da linha de comando, que pode ser diferente da que serve as requisições web, especialmente em ambientes com múltiplas versões instaladas.
Pelo painel de hospedagem (mais prático e seguro):
- cPanel: Acesse “MultiPHP Manager” e veja a versão associada ao seu domínio.
- Plesk: Acesse “PHP Settings” ou “Domínios > configurações do servidor web.”
- WordPress: Instale o plugin Site Health e acesse Ferramentas > Saúde do Site. A versão do PHP aparece na aba “Informações.”
Pelo terminal, para uma referência rápida:
php -vO retorno deve ser algo como:
PHP 8.3.36 (cli) (built: Oct 21 2026)Atenção: esse comando verifica o PHP da linha de comando, não necessariamente o handler que serve o seu site. Se o servidor usa PHP-FPM, Apache mod_php ou php-cgi, confirme a versão diretamente no painel ou com o arquivo phpinfo() acessado pelo navegador. Se os dois números divergirem, o número que importa para segurança é o que aparece no phpinfo() pelo navegador.
Como corrigir a vulnerabilidade PHP2Shell
Se você usa hospedagem compartilhada ou gerenciada
Nesse caso, a atualização é responsabilidade do provedor. Mas você precisa confirmar que ela foi aplicada.
Envie esta mensagem ao suporte da hospedagem:
“Vocês já aplicaram o patch oficial do PHP2Shell (CVE-2026-109618 e CVE-2026-109619) nos servidores? Qual é a versão do PHP efetivamente em execução no meu domínio? A correção foi feita no runtime ou apenas via WAF?”
A resposta esperada é que o runtime foi corrigido. Regras de WAF reduzem o risco, mas não eliminam a vulnerabilidade no núcleo do PHP.
Provedores que já confirmaram correção até a publicação deste artigo: Hostinger, Cloudflare (WAF), AWS (WAF + orientação de atualização), xCloud e SmartHost.
Se você usa VPS, Droplet, EC2 ou servidor próprio
Aqui a atualização é 100% sua responsabilidade. O processo varia por sistema operacional.
O processo varia conforme a distribuição e o repositório que está sendo usado. Antes de executar qualquer comando, confirme qual repositório PHP seu servidor utiliza; instalar o pacote genérico sem verificar o repositório pode resultar em uma versão que não inclui o patch.
Ubuntu com repositório Ondrej PPA (repositório de terceiros, comum em VPS):
sudo add-apt-repository ppa:ondrej/php # pule se já adicionadosudo apt updatesudo apt install --only-upgrade php8.3 # ou php8.4, conforme a versão em usophp -vsudo systemctl restart php8.3-fpm # ajuste para o handler em uso# ou, se usar Apache mod_php:sudo systemctl restart apache2Nota: o PPA Ondrej é específico para Ubuntu. Em Debian puro, o repositório equivalente é deb.sury.org. Não use o PPA Ondrej em Debian.
Debian com repositório sury.org:
sudo apt updatesudo apt install --only-upgrade php8.3php -vsudo systemctl restart php8.3-fpmCentOS, AlmaLinux ou Rocky com repositório Remi:
sudo dnf update php83 # ou php84, conforme a versão instaladaphp -vsudo systemctl restart httpdsudo systemctl restart php-fpmApós atualizar, verifique a versão com php -v e reinicie o serviço PHP correspondente. Reiniciar é obrigatório: workers do PHP-FPM e processos do Apache carregam o binário em memória, e precisam ser encerrados para carregar o binário corrigido.
Se você usa WordPress
Atualizar WordPress, plugins e temas não corrige a falha do PHP. São camadas diferentes.
O que precisa ser feito:
- Atualize o PHP do servidor para a versão corrigida (passos acima).
- Depois da atualização do PHP, verifique se o WordPress ainda funciona corretamente. Versões antigas de plugins podem ter incompatibilidade com PHP 8.3 ou 8.4.
- Teste em ambiente de staging antes de aplicar em produção, se possível.
- Atualize plugins e temas em seguida, mas sabendo que isso é manutenção separada da correção da falha.
Mitigações temporárias (se não for possível atualizar agora)
Se a atualização do runtime não puder ser feita imediatamente, estas configurações reduzem a superfície de ataque. Elas não tornam o servidor seguro, mas diminuem a exposição enquanto o patch não é aplicado.
No php.ini ou na configuração do pool PHP-FPM:
; Mitiga CVE-2026-109618 (corrupção de memória); Atenção: memory_limit = -1 remove o limite de memória por requisição.; Aplique apenas como medida emergencial em servidor administrado por profissional; com limites de recursos (cgroups, container limits) configurados no nível do sistema.memory_limit = -1; post_max_size = 8M reduz a superfície de ataque, mas pode; interromper uploads legítimos se a aplicação aceita arquivos maiores.post_max_size = 8M; Mitiga CVE-2026-109619 (estado residual)session.upload_progress.enabled = 0; Para PHP 8.5fatal_error_backtraces = 0Essas configurações são paliativas, não corretivas. O comunicado oficial do PHP é claro sobre isso. Use-as apenas enquanto prepara a atualização real do runtime. memory_limit = -1 em particular exige atenção: sem um limite explícito de memória no sistema operacional, um ataque de exaustão de recursos pode derrubar o servidor. Não aplique isso em produção sem um profissional responsável pelo servidor.
Depois de editar, reinicie o PHP-FPM ou o Apache:
sudo systemctl restart php8.3-fpmOutras medidas complementares:
- Bloqueie requisições
multipart/form-datano WAF quando não forem necessárias. - Desative uploads no
php.inise a aplicação não precisa:file_uploads = Off - Em Apache com mod_php, proteções no nível da aplicação podem não ser suficientes porque a exploração ocorre antes do código da aplicação ser executado.
O que a vulnerabilidade PHP2Shell faz com o SEO do seu site
Esse ponto raramente é mencionado nos alertas de segurança. Mas para quem trabalha com SEO técnico, é tão crítico quanto a correção do runtime.
Um site comprometido via PHP2Shell pode ter os seguintes impactos diretos no ranking:
Injeção de spam e links maliciosos: atacantes frequentemente injetam páginas com links para cassinos, farmácias ou sites maliciosos. O Google detecta esse padrão e aplica penalidades manuais ou algorítmicas ao domínio inteiro.
Erros 500 e 503 em escala: se o servidor entrar em estado instável por exploração ativa ou por um ataque em andamento, o Googlebot registra erros ao rastrear as páginas. Se isso durar dias, páginas indexadas podem ser removidas temporariamente dos resultados.
Flags de malware no Google Safe Browsing: se o Google detectar código malicioso no site, ele exibe um aviso de segurança para os usuários antes de abrir a página. Isso colapsa o CTR e pode levar semanas para ser removido, mesmo depois de o site estar limpo.
Perda de crawl budget: servidores lentos ou instáveis reduzem a taxa de rastreamento do Googlebot. Para sites grandes com muitas páginas, isso significa que atualizações de conteúdo e novas páginas demoram mais para ser indexadas.
E a máquina concorda com esse impacto toda vez que o Google registra um site comprometido e reduz sua autoridade nos meses seguintes.
A segurança do servidor não é separada do SEO. Ela é parte da infraestrutura que garante que o conteúdo seja rastreado, indexado e bem posicionado.
Como verificar se seu site já foi comprometido
Se o servidor ficou exposto por algum tempo antes da correção, vale checar sinais de comprometimento:
Busca por web shells:
find /var/www -name "*.php" -newer /etc/passwd -lsfind /var/www -name "*.php" | xargs grep -l "eval(base64_decode" 2>/dev/nullfind /var/www -name "*.php" | xargs grep -l "system($_" 2>/dev/nullVerificação de arquivos modificados recentemente em diretórios públicos:
find /var/www/html/wp-content/uploads -name "*.php" 2>/dev/nullfind /tmp -name "*.php" 2>/dev/nullAnálise de logs de acesso:
Procure por requisições POST incomuns, especialmente para scripts em /uploads/, /cache/ ou diretórios de temp. Requests com payloads grandes ou repetitivos para os mesmos endpoints são sinais de varredura ativa.
No Google Search Console:
Acesse “Segurança e Ações Manuais > Problemas de Segurança”. Se o Google já detectou código malicioso no site, o aviso aparece aqui.
Como evitar a próxima vulnerabilidade crítica de PHP
A PHP2Shell foi descoberta por uma ferramenta de análise de segurança baseada em IA, o que vai acelerar a cadência desse tipo de descoberta. A tendência é que novas vulnerabilidades sejam encontradas com mais frequência e com menos tempo entre divulgação e exploração ativa.
O que isso significa na prática:
Monitore versões do PHP ativamente. Assine os canais oficiais: php.net/security, o GitHub do PHP e o CNCS (para alertas em Portugal) ou CISC (gov.br, para alertas no Brasil).
Mantenha o PHP sempre em versão suportada. PHP 8.1 chegou ao fim de vida. PHP 8.2 recebe correções de segurança até dezembro de 2026. Versões fora do ciclo de suporte não recebem patches, e qualquer vulnerabilidade descoberta nelas fica permanentemente sem correção.
Implemente WAF como camada adicional. Cloudflare, Sucuri e AWS WAF já implementaram regras específicas para PHP2Shell. O WAF não substitui o patch, mas adiciona um ponto de bloqueio antes que a requisição chegue ao runtime.
Faça backups verificados regularmente. Não apenas backups, mas backups que você testou e sabe que restauram o site com sucesso. Um backup não testado é um backup não confiável.
Separe ambientes de staging e produção. Atualizações de PHP devem ser testadas em staging primeiro. Isso reduz o risco de quebras de compatibilidade com plugins ou código customizado.
Revise permissões de arquivo e diretório. Diretórios com permissão de escrita desnecessária são pontos de entrada para web shells. O padrão recomendado para WordPress é 755 para diretórios e 644 para arquivos.
E a máquina concorda com isso toda vez que um scanner identifica um servidor sem monitoramento e o adiciona à lista de alvos.
Perguntas frequentes sobre a vulnerabilidade PHP2Shell
Meu WordPress está atualizado. Isso é suficiente para ficar protegido?
Não. O WordPress e seus plugins rodam em cima do PHP, mas a vulnerabilidade está no PHP em si, não no WordPress. Atualizar o CMS e os plugins é sempre importante, mas, nesse caso, a correção que importa é a versão do runtime PHP no servidor. São camadas diferentes: um WordPress 100% atualizado em cima de um PHP desatualizado ainda está exposto.
Minha hospedagem disse que já aplicou o patch. Ainda preciso fazer algo?
Depende do que eles fizeram. Pergunte exatamente assim: “A versão do PHP em execução no meu domínio foi atualizada para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12?” Se a resposta for que ativaram regras de WAF ou firewall, isso é uma camada de proteção adicional, mas não substitui a atualização do runtime. O banner da Hostinger que diz “Seus sites estão protegidos, aplicamos uma correção de segurança para a sua versão do PHP” indica atualização real do runtime. Esse é o tipo de resposta que você quer ouvir.
Atualizar o PHP pode quebrar meu site ou meus plugins?
Pode, especialmente se o site ainda usa código escrito para PHP 7.x. Plugins desatualizados e temas com funções depreciadas podem parar de funcionar em PHP 8.3 ou 8.4. A forma correta de proceder é: testar em ambiente de staging antes de aplicar em produção; verificar a compatibilidade dos plugins mais críticos; ter um backup restaurável antes de atualizar. Se o site não tem ambiente de staging, pelo menos garanta um backup funcional e testado antes de subir a atualização.
Tenho Cloudflare no site. O WAF me protege?
Parcialmente. O Cloudflare já implementou regras de WAF específicas para PHP2Shell e bloqueia padrões de ataque conhecidos antes que a requisição chegue ao servidor. Isso reduz a superfície de ataque, mas não elimina a vulnerabilidade no runtime. Se um atacante usar um vetor ainda não coberto pelas regras, o PHP subjacente ainda está exposto. WAF é camada complementar, não substituto do patch.
Preciso desabilitar meu site enquanto o patch não é aplicado?
Não necessariamente, mas considere as mitigações temporárias descritas acima no php.ini enquanto prepara a atualização. Agências de segurança como CERT-EU e o NCSC do Reino Unido recomendam isolar da internet pública apenas quando não for possível nem atualizar nem aplicar mitigações. Para a maioria dos sites em hospedagem compartilhada gerenciada, o provedor está aplicando o patch sem precisar tirar o site do ar.
Como sei se minha hospedagem já aplicou o patch?
Entre em contato diretamente pelo chat ou ticket de suporte e pergunte qual versão do PHP está efetivamente em execução no seu domínio. Peça confirmação de que o runtime foi atualizado, não apenas que regras de WAF foram ativadas. As duas coisas são complementares, mas só a atualização do runtime elimina a vulnerabilidade. Provedores que já confirmaram atualização: Hostinger, Cloudways, Google Cloud (App Engine Standard automático; outros ambientes exigem ação do usuário), xCloud e SmartHost.
Meu site ficou fora do ar por algumas horas. Isso prejudica o SEO?
Uma queda isolada de algumas horas raramente causa impacto duradouro no ranking, especialmente se o servidor retornou código 503 (indisponibilidade temporária) em vez de 500. O Googlebot interpreta o 503 como temporário e volta mais tarde. O problema ocorre quando o site fica fora do ar por dias ou apresenta erros repetitivos. Provedores como Sakura Internet e Xserver suspenderam temporariamente painéis de gerenciamento para aplicar os patches; essa indisponibilidade de horas controlada é muito menos custosa do que um comprometimento real.
PHP 7.4 ainda está em uso em muitos sites. Existe patch para ele?
Não. PHP 7.4 chegou ao fim de vida em novembro de 2022. A equipe do PHP não fornece mais patches de segurança para essa versão. Se você ainda usa PHP 7.4 ou qualquer versão anterior, a recomendação oficial é migrar para PHP 8.2 ou superior o quanto antes. O mesmo vale para PHP 8.1, que encerra suporte em dezembro de 2024, e PHP 8.2, que encerra em dezembro de 2026. Versões fora do ciclo de suporte não recebem patches de nenhuma vulnerabilidade, presente ou futura.
Preciso trocar senhas depois de aplicar o patch?
Se houver qualquer suspeita de comprometimento antes da correção, sim. Troque senhas do banco de dados, FTP/SFTP, painel de hospedagem, contas de e-mail vinculadas ao domínio e chaves de API de integrações críticas. Se não houver evidência de comprometimento e o patch foi aplicado rapidamente, a troca de senhas é uma boa prática, mas não estritamente obrigatória.
Preciso chamar alguém para resolver isso ou consigo fazer sozinho?
Depende do seu ambiente. Se você usa hospedagem compartilhada gerenciada como Hostinger, Locaweb ou Hostgator, o provedor trata da atualização. Confirme que fizeram e verifique a versão resultante. Se você tem VPS ou servidor próprio, a atualização é manual e exige acesso SSH com permissões de administrador. Se não tiver familiaridade com terminal e servidor Linux, contrate um profissional agora. O risco de adiar é concreto: o Cloudflare registrou que as tentativas de exploração passaram de milhares para milhões em poucas horas após a divulgação da vulnerabilidade.
As mitigações temporárias no php.ini realmente funcionam?
Elas reduzem a exposição para vetores específicos, mas não tornam o servidor seguro. O comunicado oficial do PHP é claro: são medidas paliativas enquanto o patch não é aplicado, não alternativas definitivas. O memory_limit = -1 reduz a probabilidade de acionar o bug de corrupção de memória do CVE-2026-109618; o session.upload_progress.enabled = 0 reduz a superfície do CVE-2026-109619. Mas um atacante determinado pode encontrar outros caminhos. A única correção completa é a atualização do runtime.
Fontes principais do artigo:
