Notas Técnicas do zhaoJian

PHP2Shell explora falhas críticas do PHP e países emitem alertas: alternativa gratuita ao WordPress para sites de empresas

Tecnologia ~14712 palavras · 37 min de leitura - visualizações

Em 21 de outubro de 2026, o PHP lançou uma atualização de segurança emergencial que corrige duas vulnerabilidades graves, CVE-2026-109618 e CVE-2026-109619. O atacante não precisa fazer login: basta uma única requisição para executar código arbitrário no servidor.

A Wiz Research, que descobriu as falhas, encadeou as duas em um script de exploração chamado PHP2Shell e demonstrou execução remota de código sem autenticação nas versões mais recentes do WordPress, Drupal e Joomla (Wiz).

O WordPress roda sobre PHP. Desta vez a falha está no próprio PHP, então manter o WordPress e os plugins atualizados não adianta: todo site institucional feito em WordPress precisa agir.

Vulnerabilidades críticas do PHP CVE-2026-109618 e CVE-2026-109619 e a ferramenta de exploração PHP2Shell, CVSS 9.2

Resumo das vulnerabilidades do PHP CVE-2026-109618 e CVE-2026-109619

Segundo o aviso de segurança oficial do PHP:

ItemDetalhe
IdentificadoresCVE-2026-109618, CVE-2026-109619
Nome oficialRCE via OOM corruption, RCE via stale global state
PontuaçãoCVSS 4.0, 9.2
ConsequênciaExecução remota de código (RCE) sem login
AbrangênciaTodo PHP que atende requisições web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed
Maior riscoApache mod_php: o ataque acontece antes de o código do site rodar
Versões corrigidasPHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
Sem correção oficialPHP 8.1 e anteriores
  • CVE-2026-109618: quando o PHP fica sem memória (OOM), ele pode ser interrompido com os dados da requisição inicializados só pela metade; depois, ao limpar a requisição, usa esses dados inválidos como se fossem válidos.
  • CVE-2026-109619: depois que a requisição termina e a memória é liberada, parte do estado interno continua lá, e o mesmo processo worker pode usar esse estado vencido ao atender a próxima requisição.

Vários países emitem alertas e sites saem do ar às pressas

Todos os horários abaixo são de 21 de outubro de 2026.

O CERT-EU da União Europeia (NL Times), o NCSC do Reino Unido (Patchstack), o NCSC da Holanda (Sansec) e o Escritório Nacional de Cibersegurança do Japão junto com o IPA (Impress Watch) emitiram alertas pedindo a aplicação do patch o quanto antes. A UE, o Reino Unido e o Japão recomendaram ainda tirar do ar os sites que não pudessem ser corrigidos a tempo.

Os ataques já começaram

O registro em tempo real da Patchstack, empresa de segurança para WordPress:

  • UTC 07:34: vários provedores de hospedagem relatam sites atacados.
  • UTC 07:43: o CTO da Cloudflare diz ter visto os primeiros ataques e ativa regras de firewall.
  • UTC 13:52: o PHP lança as versões corrigidas.
  • UTC 13:57: a Patchstack ainda vê apenas ataques de sondagem e prevê aumento quando os detalhes da correção forem divulgados.

A ferramenta PHP2Shell da Wiz Research atacando o WordPress: identifica o alvo automaticamente e executa comandos

O Centro Nacional de Cibersegurança da Holanda (NCSC) disse na ocasião que ainda não havia confirmado ataques reais. Para comparação: em junho de 2024, após a divulgação da vulnerabilidade do PHP CVE-2024-4577, a Akamai viu tentativas de ataque em menos de 24 horas (The Hacker News).

Sites do governo da Holanda e da Finlândia fora do ar

  • O site da Câmara dos Representantes da Holanda (Tweede Kamer) saiu do ar temporariamente. Também foram suspensos os sites do clube de futebol Fortuna Sittard, do sindicato policial ACP, da Real Associação de Farmacêuticos KNMP e da empresa de transporte EBS, além de parte da rede de TI compartilhada por universidades e instituições de pesquisa holandesas (NL Times).
  • O próprio site do NCSC holandês, o site de tecnologia Tweakers e o portal de notícias de segurança Security.NL saíram do ar (Sansec).
  • O sistema de identificação do governo holandês DigiD e o portal de serviços públicos MijnOverheid suspenderam o atendimento (Patchstack).
  • A Valtori, centro de TI do governo finlandês, desligou os sites públicos de vários órgãos estatais, entre eles o Serviço Nacional de Agrimensura da Finlândia e o Centro de Exposições e Convenções de Helsinque (Pasquale Pillitteri).

Japão: a primeira-ministra Takaichi faz apelo noturno; pixiv, DMM e outros em manutenção emergencial

Às 21:55, horário do Japão, a primeira-ministra Sanae Takaichi publicou no X (reproduzido pelo Impress Watch):

皆様に、今夜に対応して頂きたい大至急のお願いです。(中略)公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時(日本時間)に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。

Em resumo: verifiquem hoje à noite se o site usa PHP e apliquem o patch assim que ele sair, às 23h no horário do Japão; quem não conseguir a tempo pode suspender o site temporariamente.

O Escritório Nacional de Cibersegurança do Japão e o IPA também emitiram alertas, e alguns governos locais anunciaram paradas temporárias de sistemas. Serviços citados na mesma reportagem:

  • A plataforma de lojas virtuais BASE e o serviço para creches CoDMON entraram em manutenção a partir da tarde;
  • pixiv, DMM.com, niconico e Sakura Internet fizeram manutenção emergencial em parte dos serviços, e depois das 20h muitos serviços foram suspensos;
  • Jogos como Granblue Fantasy e Umamusume: Pretty Derby suspenderam o serviço.

O modo de manutenção do WordPress não protege

A Sansec aponta que o modo de manutenção nativo do WordPress e do Magento não funciona: o PHP já processou a requisição antes de a aplicação checar a chave de manutenção. O que funciona é parar o PHP-FPM e fazer o servidor web devolver diretamente uma página de manutenção estática.

Então, naquela noite, um site institucional em WordPress tinha só dois caminhos: alguém entrar no servidor e atualizar o PHP, ou tirar o site inteiro do ar. Sites sem ninguém responsável só podiam ficar no ar e torcer.

Por que o site institucional em WordPress é o mais exposto

Falha no nível do PHP não é barrada por plugin de WordPress. Com mod_php, o ataque acontece antes de o código do site rodar, então plugins de segurança, captcha e esconder o painel não servem de nada. A Sansec também diz: a única saída é atualizar o PHP do servidor, e quem não administra o próprio servidor só pode cobrar a hospedagem.

Muitos servidores ainda usam PHP sem suporte. A empresa de segurança Mallory contou em 20 de outubro, via Shodan, cerca de 884 mil hosts públicos cujos cabeçalhos de resposta indicam PHP 8.1 ou anterior, 59% dos hosts que informam a versão (cerca de 1,5 milhão). A contagem é por cabeçalho e não significa que todos estejam vulneráveis (The Hacker News). Essas versões não têm patch oficial: só resta pedir à hospedagem um patch portado ou atualizar o PHP, e temas e plugins antigos costumam quebrar na atualização.

Custa dinheiro todo ano. Renovação da hospedagem, taxa de manutenção, licença anual de plugins pagos e, se der problema, o custo da limpeza. Um site que só apresenta a empresa, serviços, cases, notícias e vagas precisa manter PHP + MySQL rodando e ainda alguém de plantão no servidor em noites como a de 21 de outubro.

Minha solução: Astro + Cloudflare / GitHub / Vercel / Netlify

Há dois anos deixei de recomendar WordPress e PHP aos meus clientes e já migrei todos os sites deles para Astro combinado com Cloudflare, GitHub, Vercel e Netlify. Os planos gratuitos dessas plataformas atendem com folga um site institucional: a hospedagem não custa nada, e o resultado é mais rápido, mais seguro e dá menos dor de cabeça que o antigo site em WordPress.

Com esta falha do PHP, os sites desses clientes não precisaram de nenhuma ação e continuaram no ar normalmente naquela noite. Meu blog zhaojian.net é montado do mesmo jeito e tem versões em 12 idiomas.

O processo é simples:

  • O Astro gera todas as páginas no build; o que vai ao ar é só HTML, CSS, JS e imagens;
  • o código-fonte fica no GitHub; para mudar um texto ou publicar uma notícia, basta fazer um commit;
  • Cloudflare Pages / Vercel / Netlify fazem o build e publicam automaticamente ao receber o commit; em poucos minutos está no ar, e as páginas são servidas por uma CDN global.

Mais seguro: não há PHP, banco de dados nem página de login no servidor; ferramentas de exploração como o PHP2Shell não têm por onde entrar. Futuras falhas do PHP, do WordPress ou de plugins não afetam o site.

Mais rápido: as páginas são arquivos prontos, servidos do nó da CDN mais próximo do visitante; o acesso é rápido no Japão, na China, na Europa e nas Américas.

Grátis e sem manutenção: não há hospedagem nem servidor para renovar; sobra só o domínio. Não há servidor para acessar nem programa para atualizar.

WordPress x site estático com Astro

Site em WordPressSite estático com Astro
Programas em execuçãoPHP + MySQL + tema + pluginsNenhum, só arquivos estáticos
Esta falha do PHPAfetado: atualizar de madrugada ou tirar do arNão afetado
Custo de hospedagemRenovar hospedagem / servidor todo anoGrátis
ManutençãoAtualizar WordPress, plugins e PHP regularmenteNenhuma
VelocidadeDepende do servidor e do cacheServido direto pela CDN
Atualizar conteúdoEntrar no painel e editarCommit e publicação automática
MultilíngueVia plugin de idiomasPáginas de cada idioma geradas no build

Recursos que leem e gravam dados em tempo real, como loja virtual, área de membros ou agendamento, precisam de planejamento à parte. O que um site institucional costuma ter — formulário de contato, notícias, cases, vagas, vários idiomas — dá para fazer com site estático e um serviço de formulários de terceiros.

Como migrar do WordPress para o Astro

  1. Levantar as páginas: liste todas as páginas, posts, imagens e formulários.
  2. Exportar o conteúdo: exporte posts e páginas para Markdown e baixe as imagens junto.
  3. Manter as URLs: preserve as URLs originais sempre que possível e configure redirecionamentos 301 para as que mudarem, evitando queda no ranking de busca.
  4. Refazer o design: reproduza o visual atual ou crie um novo, já responsivo para celular.
  5. Substituir recursos: formulários passam para um serviço de terceiros, e as estatísticas, para uma solução sem servidor.
  6. Trocar o domínio: com tudo conferido, aponte o domínio para a nova plataforma e não renove o servidor antigo quando vencer.

Perguntas frequentes

O PHP2Shell pode atacar meu site WordPress?

Sim. A falha está no próprio PHP: se o PHP do servidor não for 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou uma versão corrigida pela hospedagem, ele é afetado, independentemente da versão do WordPress.

Ativar o modo de manutenção do WordPress resolve?

Não. O PHP processa a requisição antes de o modo de manutenção entrar em ação. Ou você atualiza o PHP, ou para o PHP-FPM e serve uma página de manutenção estática.

E se eu usar PHP 8.1 ou anterior?

O PHP não lança mais atualizações para essas versões. Você pode pedir à hospedagem um patch portado ou atualizar para PHP 8.2 ou superior; se o tema e os plugins não forem compatíveis, vale considerar migrar direto para um site estático.

Site estático é mesmo de graça?

Os planos gratuitos de Cloudflare Pages, Vercel, Netlify e GitHub Pages bastam para um site institucional; você paga só o domínio.

Quer substituir o site institucional em WordPress? Fale comigo

Fale comigo se:

  • seu site institucional usa WordPress e, na noite de 21 de outubro, você não sabia se devia tirá-lo do ar nem a quem pedir o patch;
  • seu servidor ainda roda PHP 8.1 ou anterior;
  • você paga todo ano hospedagem, servidor e taxa de manutenção;
  • quem fez o site sumiu e ninguém cuida dele;
  • você atende o mercado japonês ou internacional e precisa de um site multilíngue em japonês, inglês e outros idiomas.

Posso migrar seu site institucional em WordPress para um site estático com Astro: mais rápido, mais seguro, sem renovar hospedagem e servidor todo ano, com build e publicação automáticos a cada commit, sem precisar de alguém para manter.

Fale comigo pelo WeChat (757118), informado na página Sobre, ou pelo X (@zhaoJianNet). Envie o endereço do site e o que você precisa, e eu mando um plano de migração concreto.

Referências

Compartilhar:

Comentários