PHP2Shell é o nome dado a duas vulnerabilidades críticas no PHP, a linguagem que roda na maioria dos sites, registradas como CVE-2026-109618 e CVE-2026-109619 e com nota de gravidade 9.2 de 10. Elas permitem que alguém execute código em um servidor web sem usuário nem senha. O PHP corrigiu as falhas em 21 de outubro de 2026, nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e atualizar é a única correção completa.
Se a sua empresa tem um site, uma loja virtual, um portal de clientes ou uma intranet feitos em PHP, o trabalho desta semana é concreto: descobrir onde o PHP roda, atualizar e vigiar enquanto isso. A seguir, explicamos como fazer e o que já fizemos nos ambientes dos nossos clientes desde o dia do aviso.
O que é o PHP2Shell e por que é tão grave
O PHP é a linguagem que roda no servidor e monta as páginas de um site toda vez que alguém o visita ou envia um formulário. Segundo a W3Techs, ele é usado por 69,3% dos sites cuja linguagem de servidor é conhecida; daí vem o dado de "7 em cada 10 sites" que aparece nas notícias.
O PHP2Shell permite a execução remota de código: um atacante, pela internet e sem usuário nem senha, consegue fazer o servidor executar as instruções que quiser.
São duas falhas na forma como o PHP administra a memória:
- CVE-2026-109618: quando o PHP fica sem memória no meio de uma requisição, como ao receber um arquivo por um formulário, ele deixa dados preparados pela metade e depois os trata como válidos.
- CVE-2026-109619: informações de uma visita anterior ficam guardadas no processo que atende o site, e a visita seguinte pode usá-las. Além de permitir a execução de código, a falha pode expor fragmentos da memória com dados de outras sessões.
O que torna o caso grave é o momento em que acontece: o PHP processa a requisição maliciosa antes de o seu site carregar. Por isso, o login da sua aplicação não impede o ataque, e não importa quão bem o site foi programado: a falha está no PHP, não no seu código.
O que o PHP anunciou
O PHP, uma das linguagens mais usadas na web, precisou lançar correções para duas vulnerabilidades críticas. Ele as anunciou no seu aviso oficial, e esta é a sequência:
- 17 de outubro de 2026: a Amazon registra uma tentativa de exploração na sua rede de honeypots, quatro dias antes do aviso público.
- 20 de outubro: o PHP anuncia que no dia seguinte vai lançar uma atualização de segurança para duas CVE críticas, ambas com nota 9.2.
- 21 de outubro: o PHP lança as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, junto com medidas temporárias para quem não pode atualizar na hora.
A equipe de resposta a emergências das instituições da União Europeia (CERT-EU) considera provável que a falha já esteja sendo explorada, porque os detalhes técnicos estão sendo discutidos publicamente. Até 22 de outubro, a agência de cibersegurança dos Estados Unidos (CISA) ainda não a tinha incluído no seu catálogo de vulnerabilidades exploradas. De qualquer forma, a conclusão é a mesma: o tempo entre a publicação de uma correção e os primeiros ataques é cada vez menor.
A sua empresa está exposta?
Qualquer servidor que use PHP para servir páginas web é afetado, seja com Apache, Nginx com PHP-FPM, LiteSpeed ou outra configuração. Todas as versões anteriores às corrigidas estão em risco, inclusive as linhas que já não recebem suporte. A pergunta útil não é se você usa PHP, e sim onde:
- ☐ O site institucional, principalmente se for feito em WordPress, Drupal ou Joomla.
- ☐ A loja virtual, se usa Magento, PrestaShop ou WooCommerce.
- ☐ Portais de clientes, fornecedores ou faturamento desenvolvidos sob medida.
- ☐ A intranet ou as ferramentas internas que a equipe usa pelo navegador.
- ☐ Equipamentos e softwares de outros fabricantes que trazem PHP embutido, como consoles de gerenciamento; vários fabricantes já estão revisando os seus produtos.
- ☐ Sites de campanha ou hotsites que uma agência criou e que ninguém revisou desde então.
Para cada um, o responsável ou o seu provedor de hospedagem deve informar qual versão do PHP está rodando. Em um servidor próprio, a sua equipe confirma em segundos:
Com essa resposta, esta tabela indica o que fazer:
| Se a sua versão é... | Versão corrigida | O que fazer |
|---|---|---|
| PHP 8.5 | 8.5.12 | Atualizar e reiniciar os processos do PHP |
| PHP 8.4 | 8.4.27 | Atualizar e reiniciar os processos do PHP |
| PHP 8.3 | 8.3.36 | Atualizar e reiniciar os processos do PHP |
| PHP 8.2 | 8.2.35 | Atualizar e reiniciar os processos do PHP |
| PHP 8.1, 8.0 ou 7.4 | Sem versão oficial | Pedir ao provedor a correção para a sua versão (o PHP publicou patches de código-fonte para essas linhas) e planejar a migração para uma versão com suporte |
| PHP 7.3 ou anterior | Sem correção | Migrar para uma versão com suporte ou isolar o servidor da internet enquanto isso |
Se o seu site está em uma hospedagem compartilhada, você não consegue atualizar o PHP por conta própria: peça ao provedor, por escrito, a versão exata e a data em que aplicou a correção. O mesmo vale para equipamentos de outros fabricantes: a correção chega com a atualização do fabricante.
O que fazer nesta semana
O aviso oficial do PHP é claro: não existe mitigação completa, apenas a atualização. Esta é a ordem que recomendamos:
- Priorize o que está exposto à internet. Primeiro os servidores acessíveis de fora; depois os internos.
- Atualize para a versão corrigida da sua linha. Se você usa os pacotes da sua distribuição Linux, a maioria já publicou a correção; a sua equipe deve confirmar a versão instalada depois de atualizar.
- Reinicie os processos do PHP. Uma das falhas vive em processos que continuam rodando, então atualizar sem reiniciar mantém o risco ativo.
- Se não puder atualizar hoje, reduza a exposição. O PHP publicou ajustes temporários que a sua equipe pode aplicar na configuração do servidor, como desativar o acompanhamento do progresso de upload (
session.upload_progress.enabled=0) e limitar o tamanho das requisições. Eles ajudam, mas não substituem o patch. - Isole o que não tem correção. Se um servidor não pode ser atualizado, tire-o da internet ou coloque-o atrás de um acesso restrito até resolver.
Assim ficam os passos 2 e 3 em um servidor Linux com PHP 8.3:
Se o seu site está atrás de um firewall de aplicações web (WAF) ou de uma rede de distribuição de conteúdo, confirme com o provedor se ele já ativou regras para essa falha; várias empresas do setor as lançaram no mesmo dia. São uma camada extra enquanto você atualiza, não um substituto. Esse ciclo de detectar, priorizar, aplicar e verificar é justamente o que uma boa gestão de patches de segurança organiza.
Sinais de tentativa de ataque
Como o ataque acontece antes de a sua aplicação carregar, os registros do site costumam dizer pouco. Fique atento a estes sinais no servidor enquanto termina de atualizar:
- Envios de arquivos incomuns seguidos de erros de falta de memória.
- Rajadas de erros 500, o código que um site devolve quando algo falha do lado do servidor.
- Cookies de sessão com tamanho ou formato anormais nas respostas do site.
- Processos do PHP que reiniciam sem causa clara.
Nenhum desses sinais prova um ataque sozinho. O que importa é correlacioná-los, verificar se o servidor abriu conexões ou executou programas incomuns depois da tentativa e agir rápido. Isso exige monitoramento contínuo com detecção de intrusões e a análise de cada alerta, não uma revisão manual uma vez por semana.
Como o TecnetSOC ajuda você com o PHP2Shell
Desde o aviso de 21 de outubro, no TecnetSOC identificamos os servidores expostos nos ambientes dos nossos clientes, ativamos regras de proteção e detecção para essa falha e coordenamos a atualização com cada responsável. Isto é o que fazemos por você:
Localizamos cada servidor com PHP e a sua versão
O inventário de software mostra o que roda em cada servidor monitorado e em qual versão, sem depender de revisões manuais.
Dizemos o que atualizar e como
O módulo de vulnerabilidades aponta cada CVE com a sua gravidade, os servidores afetados, a versão para a qual atualizar e a instrução exata para fazer isso. Nós priorizamos e avisamos; a sua equipe ou o seu provedor aplica a atualização na janela que combinarmos.
Protegemos você enquanto atualiza, com patch virtual
O patch virtual bloqueia as tentativas de explorar a falha mesmo enquanto o servidor ainda roda a versão vulnerável do PHP:
- No tráfego: regras de prevenção de intrusões que descartam as requisições feitas para explorar o PHP2Shell antes de chegarem ao PHP.
- No servidor: proteção que vigia os processos do PHP enquanto rodam e interrompe o comportamento anômalo de um ataque.
Não exige reinicialização e cobre também versões antigas do PHP que não podem ser atualizadas na hora. É temporário: a atualização continua sendo a única correção completa.
Detectamos e contemos qualquer tentativa
Vigiamos os sinais de ataque 24 horas por dia. Para incidentes críticos, o alerta e o início da investigação chegam em menos de 30 minutos, e a partir do plano Response a nossa equipe contém a ameaça por você: isola o equipamento ou bloqueia a atividade suspeita.
Você pode testar o TecnetSOC Response por 30 dias, sem método de pagamento e com atendimento em português, e revisar a sua exposição ao PHP2Shell com os seus próprios dados.
Perguntas frequentes sobre o PHP2Shell
É o nome usado para as duas falhas. Um "shell" é o console usado para dar comandos a um servidor, então o nome resume o risco: passar de uma visita atendida pelo PHP para o controle do servidor. Ele segue nomes como o Log4Shell, a falha de 2021 em uma biblioteca Java, e tecnicamente é uma falha de execução remota de código.
Se o seu WordPress roda em uma versão do PHP sem correção, sim: o WordPress roda sobre o PHP, assim como Drupal, Joomla e Magento. Atualizar o WordPress ou os seus plugins não corrige a falha; o que precisa ser atualizado é o PHP do servidor.
Não diretamente. A falha acontece dentro do servidor web, no momento em que o PHP recebe a requisição. O que ajuda enquanto você atualiza é o monitoramento do servidor e as regras de um firewall de aplicações web; a correção definitiva continua sendo atualizar o PHP.
Além dos sinais no servidor, procure arquivos novos nas pastas do site, usuários administradores que ninguém criou e conexões do servidor com endereços desconhecidos. Se encontrar algo, não apague nem reinstale nada antes de um especialista revisar: essas evidências mostram até onde o atacante chegou.
É a nota CVSS, a escala de 0 a 10 que o setor usa para medir a gravidade de uma vulnerabilidade. A partir de 9.0 é crítica: pode ser explorada remotamente, sem credenciais, e o atacante poderia ler, modificar ou interromper o que roda no servidor.
Em um servidor que usa os pacotes da sua distribuição, alguns minutos, mais a reinicialização dos serviços. O que leva mais tempo é verificar que o site continua funcionando, principalmente ao migrar de uma versão sem suporte, como a 7.4, para uma 8.x: nesse caso, teste antes em uma cópia do site.
Especialista em Microsoft Cloud e cibersegurança, com mais de uma década de experiência no setor de tecnologia. É reconhecido pelo amplo conhecimento na implementação de soluções em nuvem e na proteção de dados e sistemas contra ameaças cibernéticas. Como líder e palestrante, compartilha conhecimento e boas práticas em eventos de tecnologia e programas de capacitação, ajudando empresas e profissionais a aproveitar a tecnologia com segurança.