PHP2Shell: Como o Sweent corrigiu cada sistema cliente em menos de 12 horas
Duas falhas críticas do PHP (CVE-2026-109618 e CVE-2026-109619) colocam a maior parte da web em risco. O Sweent corrigiu todos os sistemas que gerenciamos em menos de 12 horas e escaneou cada um em busca de tentativas de intrusão.
Em 21 de outubro de 2026, o projeto PHP lançou correções emergenciais para duas falhas críticas no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, que a comunidade de segurança rapidamente chamou de PHP2Shell. Poucas divulgações nos últimos anos causaram tanto alarme. O PHP roda WordPress, Drupal, Joomla, Magento, WooCommerce e uma grande parte dos aplicativos personalizados na web, e a equipe do PHP disse que os bugs afetam todas as instalações do PHP que atendem às solicitações da web.
Nossa equipe se mudou assim que soubemos do problema. Em menos de 12 horas, o Sweent corrigiu todos os sistemas pelos quais somos responsáveis, tanto os nossos quanto os de nossos clientes. Em seguida, examinamos cada um desses sistemas em busca de sinais de intrusão ou tentativa de comprometimento.
O que é o PHP2Shell
Ambas as vulnerabilidades têm uma pontuação CVSS v4.0 de 9,2 em 10. Eles permitem que um invasor execute código em um servidorsem fazer login, com as mesmas permissões do processo PHP. Na prática, isso pode significar dados roubados, um site desfigurado ou um backdoor oculto que sobrevive por muito tempo após o ataque original.
- CVE-2026-109618 vem de como o PHP lida com a falta de memória, o que pode deixar os dados da solicitação apenas parcialmente configurados.
- CVE-2026-109619 vem do estado de solicitação que permanece após a liberação da memória.
As versões corrigidas sãoPHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e versões anteriores não recebem mais atualizações de segurança de rotina do projeto PHP, então os sites que ainda estão nessas versões precisam de uma atualização, não apenas de um patch.
Por que a indústria entrou em pânico
A divulgação não saiu conforme o planejado. Detalhes vazaram antes do lançamento programado, então defensores e atacantes estavam correndo ao mesmo tempo. A Cloudflare relatou tráfego de ataque precoce em poucas horas, e empresas de segurança relataram tentativas ativas de exploração.
As agências governamentais responderam rapidamente:
- CISA instou todas as organizações a inventariarem seus sistemas PHP e corrigirem imediatamente. Qualquer coisa que não possa ser atualizada, incluindo o PHP 8.1 e versões anteriores, deve ser desativada.
- O Centro Nacional de Segurança Cibernética do Reino Unido recomendou colocar os sistemas off-line até que eles pudessem ser totalmente mitigados.
- CERT-EU disse às organizações que considerassem isolar aplicativos PHP voltados para a Internet das redes públicas.
- A NSA emitiu seu próprio aviso que também levantou a opção de colocar sites offline.
Grandes organizações tomaram medidas drásticas. Partes da Wikipedia ficaram temporariamente offline, assim como Pinboard, 4chan e Something Awful enquanto esperavam pelo patch. O registrador de domínios NameSilo supostamente colocou todo o portal do cliente offline, mostrando um aviso de manutenção que descrevia a mudança como uma precaução contra as falhas do PHP. De acordo com o aviso, o acesso retornaria somente depois que o patch fosse instalado e as verificações de segurança fossem concluídas. Quando empresas desse porte escolhem o tempo de inatividade em vez do risco, a ameaça é real.
O que Sweent fez
Quando surge uma vulnerabilidade desse tamanho, as primeiras horas são mais importantes. Veja como lidamos com isso.
- Inventário. Listamos todos os servidores, contêineres e aplicativos que gerenciamos que executam PHP, incluindo softwares que incorporam PHP e são fáceis de ignorar.
- Patch. Atualizamos cada um para uma versão fixa do PHP, começando com sistemas voltados para a Internet. Quando um cliente estava em uma versão não suportada do PHP, nós a atualizamos para uma versão compatível.
- Verifique. Verificamos todos os sistemas após a atualização para confirmar se estavam executando a compilação corrigida. Um patch conta somente quando está confirmado em produção, não quando está programado.
- Verifique se há intrusões. O patch fecha a porta, mas não informa se alguém já entrou. Como os ataques começaram antes e durante a janela do patch, examinamos todos os sistemas que gerenciamos em busca de sinais de intrusão ou tentativa de penetração. Isso abrangeu processos inesperados iniciados por trabalhadores de PHP, arquivos novos ou modificados em diretórios da web, contas de administrador desconhecidas e solicitações suspeitas nos registros.
Tudo isso foi feito em menos de 12 horas a partir do momento em que soubemos do problema.
Se você é um cliente Sweent
Você já está protegido contra o PHP2Shell. Todos os sistemas gerenciados pelo Sweent foram corrigidos e escaneados em busca de sinais de intrusão ou violação. Você não precisa fazer nada. Se você tiver dúvidas sobre um site ou servidor específico, entre em contato com sua equipe Sweent e explicaremos o que foi feito em seus sistemas.
Se você não for um cliente Sweent
Não espere. Aqui está o que fazer agora:
- Encontre todos os sistemas que executam PHP, incluindo plug-ins, dispositivos e software de fornecedores fornecidos com ele.
- Atualize para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou atualize se você estiver usando a versão 8.1 ou anterior.
- Confirme se a atualização está ativa. Peça ao seu host ou provedor de TI a confirmação de que ela está instalada, não apenas programada.
- Se você não conseguir corrigir imediatamente, coloque o sistema offline. Um firewall de aplicativo da web pode reduzir a exposição, mas é um paliativo, não uma solução.
- Procure sinais de comprometido. Verifique se há shells ou downloads lançados por processos PHP, novos arquivos em diretórios da web e novas contas de administrador.
Se precisar de ajuda com isso, [fale com Sweent] (https://sweent.com/contact). Podemos corrigir, verificar e escanear seus sistemas da mesma forma que fizemos com nossos clientes.
**Fontes: ** [alerta CISA] (https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) · [Malwarebytes] (https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates) · [NBC News] (https://www.nbcnews.com/tech/security/critical-vulnerabilities-php-update-systems-rcna604751) · [Qualys] (https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities) · [The Next Web] ( https://thenextweb.com/news/php-vulnerability-cert-eu-websites-offline)