PHP2Shell: o checklist do gestor para o site da empresa em 8 passos
Em um aviso crítico como a PHP2Shell, o gestor precisa de três respostas. O site executa a tecnologia afetada? Quem atualiza e até quando? Existe um ponto de backup anterior ao aviso, de 21 de outubro de 2026?
Com essas três respostas em mãos, o resto é execução em ordem. Sem elas, qualquer reunião vira especulação.
TL;DR: A PHP2Shell afeta o próprio mecanismo do PHP, e não um plugin ou tema. Se o site da empresa roda PHP, o gestor deve confirmar a versão, cobrar a atualização com prazo e garantir um backup anterior a 21/10. Sites com menos partes móveis tornam essa lista mais curta.
O que é a PHP2Shell e por que ela importa para o site da empresa?
Segundo a CyberSec Brazil, o projeto PHP anunciou em 21 de outubro de 2026 a correção emergencial de duas falhas. Os identificadores são CVE-2026-109618 e CVE-2026-109619, apelidadas de PHP2Shell, com pontuação 9,2 no CVSS v4.0, a escala padrão de gravidade.
O tipo de falha é execução remota de código (RCE, na sigla em inglês) sem autenticação. Na prática, um invasor pode rodar comandos no servidor sem login. Os pesquisadores também demonstraram leitura de memória dos processos PHP.
O aviso oficial fala em "praticamente todas as versões desde o PHP 5.4". O problema está no mecanismo de execução do PHP, e não em uma aplicação específica. Entre os componentes afetados estão PHP-FPM, Apache mod_php, php-cgi e FrankenPHP.
Há tentativas reais de exploração. A Cloudflare detectou tráfego de ataque antes mesmo dos patches, e a watchTowr confirmou tentativas ativas. Até a última atualização da matéria, não havia confirmação pública de servidor comprometido, e as falhas não constavam no catálogo KEV da CISA.
Resumo: não é um alerta teórico, e o relógio já está correndo.
Quais versões do PHP já estão corrigidas?
As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para as versões 7.4, 8.0 e 8.1, que não recebem mais atualizações regulares, o projeto publicou correções de código-fonte nos branches. Aplicar essas correções exige trabalho técnico manual.
A recomendação oficial é direta: "a atualização é a única medida capaz de corrigir completamente as vulnerabilidades". Existem mitigações temporárias, como session.upload_progress = 0 para a CVE-2026-109619 e memory_limit = -1 com post_max_size reduzido para a CVE-2026-109618. Elas reduzem alguns caminhos de ataque, mas não protegem por completo.
Mitigação compra horas. Atualização resolve.
Com esse contexto, o gestor não precisa virar técnico. Precisa fazer as perguntas certas, na ordem certa.
Qual é o checklist do gestor quando sai um aviso crítico?
São oito passos, em ordem de prioridade. Os três primeiros cabem em uma manhã.
- Descobrir o que o site executa. Pergunte ao time ou à agência se o site, o blog e as landing pages rodam PHP. WordPress, WooCommerce e muitos sistemas de loja rodam.
- Perguntar ao provedor ou à agência a versão e o prazo da correção. A pergunta é objetiva: "Qual versão do PHP está em uso e até que horas ela estará em 8.2.35 ou superior?". Resposta sem horário não é resposta.
- Pedir o ponto de backup mais recente anterior a 21/10. Se algo der errado, esse é o estado limpo para restaurar. Confirme a data e quem consegue restaurar.
- Trocar senhas de painel e de admin. Isso vale para o painel do site, a hospedagem, o e-mail de recuperação e as contas com acesso de administrador. A leitura de memória demonstrada pelos pesquisadores justifica a troca.
- Avisar o time que atende cliente. Comercial, suporte e redes sociais devem saber o que dizer se o site ficar lento ou fora do ar. Uma frase pronta evita improviso.
- Monitorar formulários e vendas por 48 horas. Queda brusca de leads, pedidos estranhos ou formulários que não chegam são sinais de alerta. Compare com a mesma janela da semana anterior.
- Registrar o que foi feito. Anote horário, responsável, versão final e backup usado. Esse registro serve para auditoria, para clientes corporativos e para o próximo incidente.
- Revisar a arquitetura depois que passar. A pergunta de fundo é: quantas partes do site precisam ser atualizadas toda vez que sai um aviso desses?
Se a empresa usa WordPress, o caminho é cuidar bem dele. A Rollin Host, empresa-irmã da Agência Rollin, mantém política de backup diário com 14 pontos de restauração, o que responde ao passo 3 sem drama.
O passo 8 é onde a lista pode ficar mais curta da próxima vez.
Como um site com menos partes móveis encurta essa lista?
Cada tecnologia que o site executa é algo para atualizar, monitorar e explicar em dia de crise. Esse é o status quo que a gente questiona: muitos sites institucionais rodam um motor completo de aplicação só para exibir páginas que mudam pouco.
Um site em Astro funciona de outro jeito. O Astro gera HTML estático, ou seja, páginas prontas entregues ao visitante, e usa renderização no servidor em Node só quando o projeto precisa. Um site em Astro não executa PHP, então não é afetado por falhas no mecanismo do PHP, como a PHP2Shell.
| Pergunta do checklist | Site institucional em PHP | Site em Astro (estático) |
|---|---|---|
| Executa a tecnologia afetada? | Sim, PHP no servidor | Não executa PHP |
| Precisa de atualização urgente? | Versão do PHP, plugins e tema | Dependências do projeto, em ciclo próprio |
| Backup anterior ao aviso | Essencial e urgente | Recomendado, com o código versionado |
| Itens de atenção em crise | Muitos | Menos itens |
Isso não significa site imune. A superfície de ataque fica menor, não zero: dependências, servidor, DNS e formulários continuam existindo e precisam de cuidado.
O argumento não é "WordPress é ruim". É "o que o seu site realmente precisa executar?".
Uma loja com catálogo grande, área de membros ou fluxo editorial complexo pode precisar de WordPress. Um site de marca, com páginas de serviço, blog e captação de leads, muitas vezes não precisa. A decisão é de estratégia, não de gosto técnico.
Existe ainda um ganho de marca. Páginas prontas carregam rápido, o que ajuda conversão e a forma como o site é lido por buscadores e por IAs generativas, tema do nosso trabalho em GEO e LLM SEO.
Se a dúvida é por onde começar, fale com a gente no WhatsApp.
O que a Agência Rollin pergunta na análise gratuita?
A análise gratuita começa pelas mesmas perguntas do checklist, sob o olhar de marca e conversão:
- O que o site executa hoje, e o que de fato precisa executar?
- Quais páginas geram leads e vendas, e quais só ocupam manutenção?
- Quem atualiza, com que frequência e com qual prazo em caso de aviso crítico?
- Existe backup com data conhecida e alguém que saiba restaurar?
- O site é encontrado por buscadores e por IAs como ChatGPT e Gemini?
O resultado é um diagnóstico: o que manter, o que simplificar e o que fazer primeiro. O preço de qualquer projeto vem sob proposta, depois da análise.
Principais aprendizados
- A PHP2Shell (CVE-2026-109618 e CVE-2026-109619) tem pontuação 9,2 no CVSS v4.0 e afeta o mecanismo do PHP desde a versão 5.4.
- As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Mitigações não substituem a atualização.
- O gestor precisa de três respostas: o site roda PHP, quem atualiza e até quando, e qual é o backup anterior a 21/10.
- Sites com menos partes móveis, como os feitos em Astro, encurtam a lista, mas não zeram o risco.
Perguntas frequentes
Como saber se o site da minha empresa usa PHP?
Pergunte ao responsável técnico ou à agência qual plataforma o site usa. WordPress, WooCommerce e muitos sistemas de loja rodam PHP. Peça também a versão exata em uso.
A mitigação temporária basta contra a PHP2Shell?
Não. Segundo o aviso oficial, a atualização é a única medida que corrige completamente as vulnerabilidades. As mitigações apenas reduzem alguns caminhos de ataque.
Um site em Astro é imune a ataques?
Não existe site imune. Um site em Astro não executa PHP e, por isso, não é afetado pela PHP2Shell, mas dependências, servidor, DNS e formulários continuam exigindo cuidado.
Preciso sair do WordPress por causa dessa falha?
Não necessariamente. Muitos negócios precisam do WordPress, e o caminho é mantê-lo atualizado e com backup. A revisão de arquitetura serve para avaliar se o site precisa de tudo o que executa.
Por que trocar senhas se o site já foi atualizado?
Os pesquisadores demonstraram leitura de memória dos processos PHP. Trocar senhas de painel e de admin fecha uma porta que a atualização sozinha não fecha.
Qual é o próximo passo?
Antes do próximo aviso crítico, vale responder internamente: quantos itens desse checklist o site da sua empresa exige? A meta é que essa lista fique mais curta a cada revisão.
Fale com a gente: mande a URL do site da sua empresa no WhatsApp. A gente diz o que ele executa e o que fazer primeiro.
Equipe Agência Rollin
Comentários
Carregando comentários...