Atualizar o WordPress não atualiza o PHP. Quem corrige?

Na semana passada, sites de governo, prefeituras e empresas pela Europa entraram em modo de manutenção. O motivo foram duas falhas críticas no PHP, a linguagem que roda o WordPress e boa parte da web, corrigidas em 21 de outubro de 2026. O próprio projeto PHP chamou as falhas de "vulnerabilidades críticas de execução remota de código" e pediu que todo mundo atualizasse imediatamente. O detalhe que pegou a maioria das empresas de surpresa é simples: atualizar o WordPress não atualiza o PHP. Outra pessoa precisa fazer isso, e em muita empresa ninguém sabe direito quem é.

O seu produto pode nem rodar em PHP. O seu site institucional, o blog, as landing pages ou a agência que fez tudo isso muito provavelmente rodam. É aí que essa história chega em você.

O que aconteceu

Os fatos das fontes primárias, sem o barulho:

• A correção. O PHP lançou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 em 21 de outubro. As duas falhas têm nota 9,2 de 10 e, segundo o PHP, "podem permitir execução remota de código sem autenticação", ou seja, um atacante poderia assumir o servidor sem fazer login.
• Quem está exposto. O PHP diz que o risco vale pra "todas as instalações de PHP que atendem requisições web", nas formas mais comuns de rodar a linguagem.
• Versões antigas não têm correção oficial. Nas palavras do PHP: "o PHP 8.1 e anteriores não recebem mais atualizações do projeto PHP". Algumas distribuições Linux e fornecedores de suporte estendido publicam correções próprias.
• O que as autoridades disseram. O CERT-EU, time de segurança das instituições da União Europeia, recomenda atualizar "o quanto antes" e, quando não der, "isolar os recursos expostos à internet das redes públicas até a correção ser aplicada e verificada". Traduzindo: tirar o site do ar.
• Ataques. A watchTowr relatou tentativas de exploração a partir de 21 de outubro, e o CTO da Cloudflare relatou "os primeiros ataques surgindo". Em 26 de outubro, a BleepingComputer noticiou a primeira exploração bem-sucedida confirmada, registrada em honeypots (servidores-isca) rodando PHP 8.4.26, com os achados confirmados pelo pesquisador Marcus Hutchins, da Expel. Até essa reportagem, nenhuma organização real tinha sido confirmada publicamente como invadida.
• Uma terceira falha, ainda sem correção. Em 23 de outubro o PHP divulgou a CVE-2026-115560, que ele mesmo chama de "vetor improvável de execução remota de código" e que exige uma configuração incomum. A correção vem na próxima versão regular, ainda sem data. Até lá, o PHP recomenda uma mudança de configuração e, sobre as duas falhas principais, repete que "atualizar é a única escolha segura".
• Não é só site. O PHP também roda dentro de produtos que ninguém associa a PHP. A Help Net Security relata que a Palo Alto Networks confirmou que os firewalls PAN-OS e o Panorama são afetados, com correções saindo até 30 de outubro, e que a Cisco lista o Expressway, o Duo Access Gateway e um produto de rede sem fio, um deles com correção prevista só pra fevereiro de 2027. A Fortinet ainda investigava quatro produtos.

A Malwarebytes resumiu a consequência pro negócio numa frase: "Atualizar o WordPress ou os plugins não é o mesmo que atualizar o PHP. A hospedagem ou os administradores do servidor podem precisar aplicar a correção."

O mecanismo: três camadas, três donos

Um site de empresa típico tem três camadas, e muitas vezes cada uma tem um dono diferente.

1. A aplicação. WordPress, tema e plugins. O time de marketing ou uma agência atualiza isso, muitas vezes num painel com um botão "atualizar".
2. O runtime. O próprio PHP, o programa que executa o WordPress no servidor. Ele não aparece no painel do WordPress e não atualiza quando o WordPress atualiza.
3. O servidor. A máquina e o sistema operacional, quase sempre cuidados por uma empresa de hospedagem, às vezes por um terceirizado de TI, de vez em quando por ninguém em especial.

Essas falhas estão na camada 2. Quem costuma clicar em "atualizar" está na camada 1, então pra essas pessoas o site parece em dia enquanto está exposto. A correção precisa vir da camada 3, e se ela vem ou não depende de um contrato que ninguém lê há tempos.

Alguns detalhes deixam isso mais difícil do que parece:

• O número da versão pode enganar. Hospedagens que aplicam correções retroativas podem deixar a versão visível igual. Um site pode mostrar "PHP 8.4.26" e estar protegido, ou mostrar o mesmo número e não estar. É preciso perguntar.
• A versão corrigida pode estar perto do fim. O próprio anúncio do PHP lembra que o PHP 8.2 "chega ao fim da vida em 31 de dezembro de 2026". Um site corrigido pro 8.2.35 agora volta a rodar uma versão sem suporte em umas dez semanas.
• Regra de firewall é paliativo. Fornecedores de segurança publicaram regras pra bloquear padrões de ataque conhecidos, e o CTO da Cloudflare avisou que essas proteções "são só um paliativo".

Por que essa é uma decisão de negócio, não técnica

Tirar um site do ar é uma troca que marketing, vendas e diretoria sentem, não só a engenharia. Um dia sem site custa leads e pega mal. Um servidor invadido pode custar muito mais: dados de clientes, página inicial pichada, malware servido pros visitantes ou uma porta de entrada pra outros sistemas.

A maioria das empresas tomou essa decisão sob pressão na semana passada, muitas vezes sem saber quem conseguia aplicar a correção. É o mesmo padrão de quando uma zona do Google Cloud caiu e levou bancos junto: o risco não estava na parte que alguém vigiava. Estava numa dependência que foi delegada e depois esquecida.

O que fazer agora

• Pergunte à hospedagem por escrito se a versão corrigida do PHP é a que de fato está servindo cada um dos seus sites. Instalada, não agendada. A Malwarebytes dá o mesmo conselho: confirmar que as correções estão "instaladas, não só agendadas".
• Liste todos os seus sites em PHP, inclusive os esquecidos: páginas de campanhas antigas, site de vagas, central de ajuda, o blog que uma agência montou anos atrás. Cada um precisa de um dono nomeado pro runtime, não só pro conteúdo.
• Saia do PHP 8.1 e anteriores. Eles não recebem mais correções do projeto PHP. Se não der pra migrar nesta semana, pague um fornecedor que publique correções retroativas, ou tire o site do ar.
• Planeje agora a saída do PHP 8.2. O fim do suporte é 31 de dezembro de 2026, então um site que só foi até o 8.2 precisa de outra atualização antes do fim do ano.
• Decida antes quem pode tirar um site do ar e como entra uma página de manutenção. A pior hora pra descobrir isso é a manhã em que o alerta chega.
• Pergunte também aos fornecedores de rede e segurança. Firewalls, gateways de VPN e equipamentos podem ter PHP embutido. Pergunte a cada fornecedor se os produtos dele são afetados e quando sai a correção, e acompanhe os que ainda estão "em investigação".
• Acompanhe a próxima versão do PHP. A terceira falha só será corrigida na próxima versão regular. Aplique a mudança de configuração recomendada pelo PHP até lá e garanta que alguém esteja de olho nessa versão.
• Coloque o runtime no contrato. Se uma agência ou hospedagem cuida dos seus sites, o contrato deve dizer quem aplica atualizações de segurança no PHP e no servidor, e em quanto tempo.

Mapear quem é dono de cada camada, antes que algo quebre, é uma parte grande de como levamos produtos pra produção. É um trabalho sem glamour, e é ele que decide se uma semana como a passada custa uma tarde ou uma invasão.

Pontos principais

• O PHP corrigiu duas falhas críticas em 21 de outubro de 2026, nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Sites pela Europa saíram do ar enquanto eram corrigidos.
• O PHP 8.1 e anteriores não têm correção oficial, e o PHP 8.2 perde o suporte em 31 de dezembro de 2026.
• Atualizar o WordPress ou os plugins não atualiza o PHP. Quem aplica a correção é a hospedagem ou o administrador do servidor.
• A exploração bem-sucedida foi confirmada em servidores-isca em 26 de outubro. Nenhuma organização real tinha sido confirmada publicamente como invadida.
• Uma terceira falha, de risco menor, ainda não tem correção, e o PHP também roda dentro de firewalls e outros equipamentos de fornecedores como Palo Alto Networks e Cisco.
• Pergunte à hospedagem por escrito, liste todos os sites em PHP, dê um dono pro runtime e decida antes quem pode tirar um site do ar.

Perguntas frequentes

O que é o PHP2Shell? O nome dado a duas vulnerabilidades críticas no PHP, corrigidas em 21 de outubro de 2026, que poderiam permitir a um atacante executar código num servidor web sem fazer login. O PHP deu nota 9,2 de 10 pras duas.

Meu site é WordPress. Fui afetado? Talvez. O WordPress roda sobre o PHP, então a correção depende da versão de PHP da sua hospedagem, não do WordPress. Atualizar o WordPress ou os plugins não aplica essa correção. Peça à hospedagem a confirmação de que o PHP corrigido está instalado.

Devo tirar meu site do ar? Se a hospedagem confirmar que a correção ou proteções temporárias estão aplicadas, normalmente não. Se você tem servidor próprio e ainda não conseguiu corrigir nem proteger, o CERT-EU recomenda isolá-lo da internet até a correção ser aplicada e verificada.

Se o meu site ficou fora do ar na semana passada, ele foi invadido? Não necessariamente. Muitos sites entraram em manutenção por precaução enquanto aplicavam a correção. Como lembra a Malwarebytes, ficar fora do ar por um tempo não significa, por si só, que o site foi invadido.

Não tenho nenhum site em PHP. Posso ignorar isso? Ainda não. O PHP roda dentro de alguns firewalls, gateways e outros equipamentos. A Palo Alto Networks e a Cisco já confirmaram produtos afetados. Pergunte aos seus fornecedores se você está exposto e quando sai a correção.

E se eu estou no PHP 8.1 ou anterior? O projeto PHP não corrige mais essas versões. Migre pra uma versão com suporte ou use um fornecedor que publique correções retroativas. Se nenhuma das duas for possível logo, manter o site fora do ar é a escolha mais segura.