Em 21 de outubro de 2026, o PHP corrigiu duas falhas críticas, com nota 9,2 de 10 em gravidade. Elas permitem que um invasor rode comandos no servidor de um site sem precisar de senha.
As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Se o seu site roda uma versão abaixo dessas, ele está vulnerável até ser atualizado.
Aqui no Aprenda Bitcoin, a correção foi instalada 25 minutos depois de publicada. Abaixo eu explico tudo em linguagem simples e mostro o passo a passo, tanto para quem tem site numa hospedagem quanto para quem cuida do próprio servidor.
O que é PHP, em uma frase
PHP é a linguagem de programação que roda por trás da maior parte dos sites da internet. Quando você abre uma loja virtual, um blog em WordPress ou a área de login de um curso, muitas vezes é o PHP que monta aquela página no servidor e entrega pronta para o seu navegador.
Uma boa comparação é a de um carro. O site é a lataria, as cores, os bancos. O PHP é o motor. Você não vê o motor, mas se ele tiver um defeito de fábrica, todo carro daquele modelo tem o mesmo defeito, não importa a cor.
Foi isso que aconteceu: um defeito de fábrica no motor, que afeta todo site que roda PHP sem a correção.
O que aconteceu, dia e hora
O projeto PHP fez algo incomum: avisou com um dia de antecedência que ia publicar uma correção grave, sem dizer qual era o defeito. A ideia era dar tempo para as empresas de hospedagem se prepararem antes que os detalhes ficassem públicos.
| Quando | O que aconteceu |
|---|---|
| 20/10, terça | O PHP anuncia que vai corrigir 2 falhas críticas, ambas com nota 9,2 de 10, sem revelar detalhes. |
| 20/10 e 21/10 | O assunto se espalha. Começam boatos sobre onde estaria o defeito. |
| 21/10, 11h | Sai a correção oficial: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, junto com o comunicado de segurança. |
| A partir daí | Começa a corrida: quem atualiza fica protegido; quem demora vira alvo. |
Horários em Brasília. Fonte: comunicados oficiais em php.net de 20 e 21 de outubro de 2026.
Por que essa falha é tão grave
As duas falhas permitem "execução remota de código". Em português simples: um invasor, de qualquer lugar do mundo, consegue fazer o servidor do site obedecer a comandos dele. Não precisa de login, não precisa de senha.
Com isso, ele pode, por exemplo:
- Mudar o que aparece no site, inclusive colocar páginas falsas ou janelas de golpe.
- Roubar dados guardados no servidor, como cadastros de clientes.
- Usar o servidor para atacar outras pessoas, sem o dono perceber.
E aqui está o ponto que pouca gente entende: o perigo aumenta depois que a correção sai, não antes. A correção mostra, para quem sabe ler o código, exatamente onde estava o furo. A partir daí, criminosos conseguem montar o ataque e procurar automaticamente os sites que ainda não atualizaram. Cada dia sem atualizar é um dia de porta aberta com placa na frente.
Para quem quer o nome técnico, as duas falhas são:
- CVE-2026-109618: quando o servidor fica sem memória no meio de uma requisição, o PHP pode tratar dados incompletos como se fossem válidos.
- CVE-2026-109619: restos de uma requisição podem "sobrar" na memória e ser usados pela requisição seguinte, que pode ser de um invasor.
Meu site está em risco?
Está em risco todo site que roda PHP numa versão anterior às corrigidas. A forma mais rápida de saber é olhar o tipo do seu site:
| Seu caso | Risco | Quem resolve |
|---|---|---|
| Site em WordPress, WooCommerce, Joomla ou Moodle | Alto | A hospedagem atualiza o PHP. Você confere e cobra. |
| Hospedagem compartilhada com cPanel (Hostgator, Hostinger, Locaweb e similares) | Alto | A hospedagem. Você confere a versão e abre chamado. |
| Servidor próprio (VPS ou dedicado) | Alto | Você ou o seu técnico. Ninguém vai atualizar por você. |
| Site em PHP 8.1, 7.4 ou mais antigo | Muito alto | Não existe correção para essas versões. Precisa migrar para PHP 8.3 ou 8.4. |
| Site feito em Wix, Squarespace, Shopify ou Nuvemshop | Baixo | A plataforma cuida do servidor. Você não precisa fazer nada. |
| Você só usa sites, não tem site | Indireto | Seu risco é cair em golpe dentro de site invadido. Veja a parte de cripto no final. |
Como resolver: passo a passo para quem não é técnico
Se o seu site está numa hospedagem com painel (a maioria dos sites pequenos no Brasil), este é o caminho. Leva uns 15 minutos, mais o tempo de resposta da hospedagem.
- Descubra a versão do PHP do seu siteEntre no painel da hospedagem (cPanel) e procure por MultiPHP Manager ou Selecionar versão do PHP. A versão aparece ao lado do seu domínio. No WordPress, também dá para ver em Ferramentas → Saúde do site → Informações → Servidor. Anote os três números, por exemplo 8.2.34.
- Compare com a tabela de versões corrigidasUse a tabela logo abaixo. Se o seu número for menor que o corrigido da mesma linha, o site está vulnerável.
- Faça um backup antes de qualquer mudançaNo cPanel, use Backup ou JetBackup e baixe uma cópia para o seu computador. É o seu seguro se algo der errado na troca.
- Abra um chamado na hospedagemEm hospedagem compartilhada, quem instala a correção é a empresa. Copie a mensagem pronta logo abaixo e envie.
- Se a sua versão é 8.1 ou mais antiga, troque de versãoNo mesmo Selecionar versão do PHP, escolha 8.3 ou 8.4. Logo depois, abra o site e teste as páginas principais, o login e o carrinho, se tiver. Se algo quebrar, volte para a versão anterior e chame um técnico: algum plugin antigo precisa ser atualizado.
- Confira de novo depois de 24 horasVolte ao painel e veja se o número mudou para a versão corrigida. Chamado respondido não é o mesmo que correção instalada.
| Sua linha do PHP | Versão corrigida | Situação |
|---|---|---|
| PHP 8.5 | 8.5.12 ou maior | Tem correção |
| PHP 8.4 | 8.4.27 ou maior | Tem correção |
| PHP 8.3 | 8.3.36 ou maior | Tem correção |
| PHP 8.2 | 8.2.35 ou maior | Tem correção, mas a linha 8.2 para de receber correções em 31/12/2026 |
| PHP 8.1 ou anterior | Não existe | Sem correção. Precisa migrar. |
Atualizar o WordPress resolve?
Não. Essa é a confusão mais comum desta semana. O WordPress é o programa do site. O PHP é o motor que roda por baixo dele, no servidor. A falha está no motor.
Você pode estar com o WordPress e todos os plugins em dia e, mesmo assim, estar vulnerável. A correção só entra quando a hospedagem (ou você, no servidor próprio) atualiza o PHP. Atualizar WordPress e plugins continua sendo importante, só não fecha esta falha.
Como resolvemos aqui no Aprenda Bitcoin, passo a passo
A plataforma do Aprenda Bitcoin roda em servidor próprio. Isso significa que ninguém ia atualizar por nós. Vou mostrar exatamente o que fizemos, em linguagem simples, porque a lógica vale para qualquer pessoa que cuida de um servidor, e para quem quer cobrar o técnico com conhecimento de causa.
| Horário | O que fizemos | Por quê |
|---|---|---|
| 06h10 | Desligamos um recurso do PHP que a plataforma não usa, apontado como um dos caminhos da falha. | Diminuir a exposição antes da correção existir. Custo zero: nada no site dependia dele. |
| 11h00 | Sai a correção oficial. | A partir daqui, o relógio corre contra quem não atualizou. |
| 11h24 | Backup das configurações do PHP e registro de como cada página respondia. | Ter como voltar atrás e como comparar o antes e o depois. |
| 11h25 | Conferimos a assinatura digital dos pacotes de atualização e instalamos a correção. | Garantir que a atualização veio do fornecedor oficial e não foi alterada no caminho. |
| 11h27 | Testamos pelo próprio site a versão em uso e as 10 páginas principais. | Confirmar que o site, e não só o servidor, está rodando a versão corrigida. |
Três detalhes desse processo fazem diferença e quase ninguém comenta:
- Agimos antes da correção, mas sem confiar só nisso. A proteção das 6h fechava apenas parte do problema. O próprio projeto PHP avisou que não existe proteção completa sem atualizar. Medida provisória é ponte, não destino.
- Conferimos a origem da atualização antes de instalar. Em dia de falha famosa, criminosos espalham "correções" falsas com vírus dentro. Cada pacote oficial vem com uma assinatura digital do fornecedor. Conferimos a dos 51 pacotes, e nenhum veio com problema. Se um único byte tivesse sido alterado, a conferência teria falhado.
- Testamos pelo site, não só pelo servidor. Em alguns servidores, a versão nova fica instalada, mas o site continua rodando a antiga até os processos do PHP serem reiniciados. Por isso a confirmação final foi feita abrindo o site de fora, como um visitante faria. Resultado: versão 8.2.35 rodando e todas as páginas respondendo igual a antes.
O comunicado oficial lista mitigações parciais, que não substituem a atualização: para a CVE-2026-109619, session.upload_progress.enabled=0 e reiniciar todos os workers; para a CVE-2026-109618, ajustes de memory_limit e post_max_size. O risco é considerado maior em mod_php, mas PHP-FPM, php-cgi, FrankenPHP e LiteSpeed também são afetados. Em servidores com cPanel, os pacotes corrigidos do EasyApache 4 saíram no mesmo dia. Depois de atualizar, recicle os processos do PHP e confirme a versão por uma requisição web, não só pelo terminal.
O risco para quem tem criptomoedas
Mesmo quem não tem site precisa prestar atenção nos próximos dias, principalmente quem tem cripto.
Quando muitos sites são invadidos ao mesmo tempo, o golpe mais comum é esconder uma armadilha dentro de um site legítimo. Pode ser uma janela pedindo para "conectar a carteira", uma página falsa de corretora ou um aviso pedindo para "validar" a sua seed phrase. Você confia no site porque já conhece, conecta, assina e o saldo vai embora. Esse tipo de golpe tem nome: drainer, o "drenador" de carteira.
Os 4 cuidados para as próximas semanas:
- Não conecte a carteira em site que não precisa dela. Blog, loja e portal de notícias não precisam da sua carteira.
- Nunca digite a seed phrase em lugar nenhum. Nenhum site, suporte ou "verificação" legítima pede as 12 ou 24 palavras. Veja como guardar a seed phrase com segurança.
- Leia o que está assinando. Uma permissão "ilimitada" de gasto é um cheque em branco para quem pediu.
- Use autenticação de dois fatores por aplicativo, não por SMS, em e-mail e corretoras.
Se quiser ir mais fundo, temos um guia completo dos golpes com cripto mais comuns no Brasil e como evitar cada um.
O que eu tiro disso
- Segurança é gestão de risco, igual no trade. Você não espera o problema acontecer para se proteger. Prepara a saída antes.
- O perigo maior vem depois do anúncio. Quem lê a manchete e esquece fica exposto justamente quando os ataques começam.
- Desconfie de tudo que chega "urgente" nesses dias. E-mail de "atualize agora", plugin de "correção", link no WhatsApp: muito disso é golpe aproveitando o assunto.
- Saber quem cuida do seu servidor vale ouro. Se a resposta for "não sei", descubra hoje.
⚠ Aviso
Conteúdo educativo, escrito em 21/10/2026 com base nos comunicados oficiais do projeto PHP. Se o seu site é importante para o seu negócio e você não tem segurança para mexer no painel, peça ajuda à hospedagem ou a um técnico de confiança.
