Na noite de 20 de outubro, um post no Hacker News revelou a existência de duas falhas graves no PHP — antes de as correções ficarem prontas.

O time de segurança do PHP confirmou em seguida e antecipou o lançamento emergencial. No dia 21, às 13h30 UTC, saíram as versões corrigidas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

As duas falhas ganharam o apelido de PHP2Shell.

O que são

As duas podem levar a execução remota de código sem autenticação — o tipo de falha mais grave que existe para um site, porque significa alguém de fora fazendo o servidor obedecer a comandos.

E elas não estão num plugin, num tema ou na lógica de uma aplicação. Estão no motor que interpreta o código PHP, abaixo de tudo.

A reação foi rápida e ampla

O CTIR Gov, centro de tratamento de incidentes do governo brasileiro, publicou o Alerta 93/2026 no mesmo dia 21, recomendando que as instituições identifiquem onde usam PHP, verifiquem as versões e apliquem as correções imediatamente.

O CERT-EU publicou o advisory 2026-018, registrando que provas de conceito já circulavam e que isso elevava a probabilidade de exploração ativa.

Dois dias depois, em 23 de outubro, veio um complicador: o PHP publicou aviso sobre a CVE-2026-115560, um terceiro caminho de execução remota ligado ao recurso de acompanhamento de upload em sessão. Essa ainda não tem correção — a recomendação oficial é desativar session.upload_progress.enabled e reiniciar os workers até a próxima versão regular.

Até o fechamento deste texto, relatos apontavam milhões de tentativas de exploração contra as duas primeiras falhas, sem comprometimentos confirmados publicamente. Nenhuma das três constava no catálogo de vulnerabilidades exploradas da CISA.

Atualizar o WordPress não resolve

Essa é a parte que pega a maioria das empresas de surpresa.

O site pode estar com o WordPress na última versão, todos os plugins atualizados, plugin de segurança ativo, firewall de aplicação na frente — e continuar vulnerável. Porque a falha não está no WordPress. Está no PHP, a linguagem sobre a qual o WordPress roda.

É uma camada abaixo de tudo que aparece no painel administrativo. Nenhum botão de “atualizar” dentro do WordPress alcança ela.

E isso vale igual para Drupal, Joomla, Magento e praticamente todo e-commerce brasileiro. O PHP é a base.

A pergunta que o caso realmente levanta

Não é “você atualizou o PHP?”.

É: quem, na sua empresa, responde por essa camada?

Faça o exercício agora. Numa operação de médio porte típica, a conversa costuma ser assim:

• O site foi feito por uma agência, que entregou e segue cuidando do layout e do conteúdo
• Ele está numa hospedagem, contratada talvez pela agência, talvez pelo marketing
• A TI interna cuida de rede, estações, servidores e nuvem — mas o site “é do marketing”
• O marketing cuida do conteúdo e das campanhas, e não sabe o que é PHP

Quatro partes envolvidas. E a versão do PHP não está, por escrito, na responsabilidade de nenhuma delas.

Por que a lacuna é estrutural, não desleixo

Vale dizer com todas as letras: isso não é sinal de equipe ruim.

A camada de servidor é invisível por projeto. Ela funciona sem pedir atenção, não aparece em painel nenhum que o time olhe no dia a dia, e não gera alerta quando envelhece. O site continua no ar, rápido, bonito e funcionando — com uma versão sem suporte embaixo.

A conta só chega quando aparece uma falha crítica e alguém pergunta “estamos expostos?”. Aí descobre-se que ninguém sabe responder, porque ninguém tinha a tarefa.

É a mesma lacuna que vimos no acesso de fornecedor esquecido na rede e nas credenciais que ninguém monitorava. Muda a camada. Não muda o padrão: existe, é crítico, e não tem dono.

Como descobrir onde você está, hoje

1. Veja a versão do PHP. No WordPress: Ferramentas → Diagnóstico do site → Informações → Servidor. Lá aparecem a versão do PHP, o servidor web e o modo de execução. Em outros sistemas, pergunte à hospedagem.

2. Compare com as corrigidas.

Esse último caso é o mais incômodo e mais comum do que se imagina. Se a versão for 8.1 ou anterior, não existe patch a aplicar — a única saída é migrar de série, o que exige teste, porque versões novas podem quebrar plugin ou tema antigo.

3. Mande a pergunta certa para quem hospeda. Copie e cole:

“Qual versão de PHP nosso site usa hoje? As correções de 21 de outubro de 2026 para CVE-2026-109618 e CVE-2026-109619 foram aplicadas? E a configuração session.upload_progress.enabled está desativada, conforme a mitigação recomendada para a CVE-2026-115560?”

Citar os identificadores muda a conversa. O suporte entende na hora do que se trata e você recebe resposta objetiva em vez de “está tudo certo por aqui”.

4. Registre quem é o dono. Depois de resolver o incidente de hoje, defina por escrito quem acompanha versão e fim de suporte dessa camada, e com que frequência revisa. Sem isso, em dois anos o problema volta igual.

5. Confira onde mais você tem PHP. Site institucional, blog, landing pages, área de cliente, loja, ambiente de homologação, aquele sistema antigo que ninguém usa mas continua no ar. O CTIR Gov foi explícito nesse ponto: identificar todos os sistemas que usam PHP, não só o principal.

A terceira falha, que ainda não tem correção

Vale repetir porque é fácil passar batido: atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 não resolve a CVE-2026-115560.

Ela depende de uma combinação incomum de configurações de sessão, e o próprio PHP classifica o risco como improvável — por isso não houve correção emergencial. A mitigação é desativar session.upload_progress.enabled e reiniciar os workers. Quem já fez isso seguindo o aviso de 21 de outubro não precisa fazer nada.

O que não tem dono não é cuidado

Este é o quarto caso grande em poucas semanas com a mesma anatomia.

No ataque que desviou R$ 53 milhões de depósitos judiciais, o acesso era de um parceiro. Nos supermercados franceses, o equipamento conectado não estava no inventário de ninguém. No vazamento das câmeras municipais, a credencial era legítima e ninguém monitorava. Agora, uma camada de software que sustenta o site inteiro e não consta na descrição de função de nenhuma área.

Nenhum dos quatro foi falha de ferramenta. Nos quatro, a ferramenta existia e funcionava — faltou alguém responder por ela.

E é por isso que a pergunta mais útil que um gestor de TI pode fazer hoje não é “temos firewall?”. É:

“De tudo que sustenta nossa operação, o que não tem dono declarado?”

Quase sempre a lista é maior do que a expectativa. E quase sempre o que está nela é justamente o que ninguém vê — até virar notícia.

Como a Strati trata isso

Todo contrato começa por um assessment. Não para entregar uma lista de problemas, mas para responder quatro perguntas antes de assumir a responsabilidade de proteger: o que existe, em que versão está, quem acessa e quem responde.

A camada de servidor entra nessa conta. Versão de PHP, data de fim de suporte, modo de execução, quem aplica correção e em quanto tempo. Não porque é glamouroso, mas porque é exatamente o tipo de coisa que envelhece em silêncio.

Você sabe dizer, agora, quem responde pela versão de PHP do seu site? Se a resposta demorar mais de dez segundos, essa é a lacuna. Fale com a Strati e comece pelo assessment.