Em 21 de outubro de 2026, os criadores do PHP, a linguagem de programação gratuita que roda a maioria dos sites, lançaram correções de emergência para duas falhas críticas. As falhas podem permitir que um estranho assuma o controle do computador de um site sem nenhuma senha.
Empresas de segurança já registraram ataques iniciais, e alguns serviços, incluindo sites do governo holandês, saíram do ar por precaução (fonte).
O que isso significa para pessoas como os leitores desta página: quem usa sites todos os dias, quem tem um pequeno negócio ou uma loja online, e quem cria ou cuida de sites? O que tende a acontecer nos próximos dias e semanas, e o que cada um deve fazer agora?
Em palavras simples: PHP — linguagem de programação gratuita que roda a maioria dos sites; Patchstack — empresa que acompanha falhas de segurança de sites; Cloudflare — empresa americana que protege sites contra ataques; CISA — a agência de defesa cibernética do governo dos EUA; CVE — número oficial de identificação de uma falha de segurança; Wiz — empresa de segurança, de propriedade do Google, que encontrou as falhas; BleepingComputer — site que publica notícias de segurança de computadores; Le Monde — principal jornal diário da França
O que fazer
Pergunte hoje à sua hospedagem: «Qual versão do PHP roda no meu site?» Versões corrigidas: 8.2.35, 8.3.36, 8.4.27, 8.5.12.
A versão do PHP da sua loja, e não os plugins, decide se você está seguro: um e-mail para a hospedagem resolve isso hoje.
Quem deve fazer o quê
Donos de lojas e criadores de sites: Hoje, 22 de outubro, peça por escrito à hospedagem a prova de que um PHP corrigido já está no ar; depois, troque as senhas de administrador e as chaves que o site guarda.
Usuários comuns da web: Troque a senha só se um site anunciar um vazamento, e então troque também as outras contas que usam a mesma senha; mantenha a confirmação em duas etapas ativa e ignore e-mails dizendo «seu site foi invadido».
O que não fazer: Não aceite «o WordPress está atualizado» como prova, e não instale plugins de correção não oficiais.
Atualizar o WordPress ou os plugins não fecha essa brecha. A falha está no PHP, o motor por trás da loja, então mesmo um site bem cuidado pode estar aberto. As sondagens começaram em 17 de outubro, antes de existir qualquer correção.
Corrigir não tira quem já está lá dentro. Invasões desse tipo quase não deixam rastro, então «não vi nada» não é prova de segurança. Travamentos ou erros estranhos nos registros do servidor devem ser tratados como possível invasão.
Pergunte hoje à sua hospedagem qual versão do PHP roda o seu site. Se for uma dessas versões (8.2.35, 8.3.36, 8.4.27 ou 8.5.12), peça à sua hospedagem que verifique os registros desde 17 de outubro. Se não for, peça uma correção antes do fim de semana, ou coloque o site em modo de manutenção até terminar. No PHP 8.1 ou mais antigo, peça ao fornecedor um backport, uma correção feita para versões antigas, ou migre para uma versão mais nova.
É o que aconselha a maioria das IAs. Abaixo, cada IA explica com suas palavras.
O que pensam as 10 IAs líderes do mundo
Concordam
Quase todos: atualizar plugins não ajuda; o PHP do servidor precisa mudar.
Divergem
Z.ai e Kimi acham que os ataques dificilmente dão certo; MiMo diz: o silêncio engana.
O que não é óbvio
Ataques começaram em 17 de outubro, logo sites já corrigidos podem ainda ter invasores.
O que acompanhar
Se até meados de novembro as invasões confirmadas seguirem poucas, vence a tese do ataque difícil.
Os dez concordam no essencial. As falhas estão no PHP, o motor por trás de cerca de 7 em cada 10 sites, e não no WordPress nem em nenhum plugin. Por isso, atualizar só o software da loja não resolve nada. Só contam quatro versões corrigidas do PHP: 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Quem só navega não precisa instalar nada, porque a brecha está nos servidores, e não nos celulares ou notebooks.
Eles também concordam nos fatos até agora. Os atacantes começaram a sondar em 17 de outubro, quatro dias antes da correção, e a Cloudflare contou milhões de tentativas depois da divulgação. As quedas, como os logins do governo dos Países Baixos, foram desligamentos preventivos. Até 22 de outubro, não foi confirmada nenhuma invasão bem-sucedida.
Eles divergem sobre o nível de preocupação. A Zhipu AI e o Kimi destacam que as ferramentas de ataque públicas costumam travar ou precisam de condições especiais no servidor. O MiMo e o Claude alertam que uma invasão bem-sucedida deixa quase nenhum rastro, então «não vimos nada» pode significar «não pegamos ninguém».
O Claude acrescenta que o centro de cibersegurança dos Países Baixos já analisava os primeiros sinais de uma invasão real. Os números de exposição também divergem, de cerca de 884 mil servidores antigos a 22,6 milhões de sistemas, porque cada empresa conta à sua maneira.
O que vem a seguir: alguns dias de correções em ritmo frenético, mais sites fora do ar por horas e, provavelmente, as primeiras invasões com vítimas identificadas. Sites em PHP 8.1 ou mais antigo não recebem correção oficial, por isso ficam expostos por mais tempo. Corrigir a brecha não tira quem já está lá dentro, então os donos também devem verificar os registros desde 17 de outubro e trocar as senhas e chaves armazenadas.
Divergem: Z.ai e Kimi acham que os ataques dificilmente dão certo; MiMo diz: o silêncio engana. O que vai resolver a disputa: Resultados do centro de cibersegurança holandês sobre primeiros sinais de invasão vão mostrar.
Não há divergência real: os dois lados dão as mesmas correções e as mesmas datas; as respostas da China trazem listas mais longas de quedas.
Quem ganha, quem perde: Quem mantém os servidores corrigidos ganha; donos de sites em PHP 8.1 ou mais antigo e seus clientes perdem.
A resposta final, escrita por uma IA
Ao lado de cada IA: a posição de hoje e a nota de 0 a 10, dada por outras IAs no papel de juízes. Toque numa resposta para lê-la.
1Z.aiChina8,2Um atacante atingiu 123 servidores dez vezes — nenhum foi invadido
Para quem só usa sites, isto é, em grande parte, a emergência de outra pessoa: a briga é entre os atacantes e quem administra os sites. O erro está no PHP, o software gratuito por trás de cerca de 7 em cada 10 sites.
Ele foi encontrado com a ajuda de IA e permite que um estranho execute o próprio código no computador de um site, sem nenhuma senha. Empresas de segurança viram ataques começarem antes mesmo de a correção aparecer, mas até hoje, 22 de outubro, nenhuma invasão bem-sucedida foi confirmada em lugar nenhum.
Muda a semana de quem administra uma pequena loja ou um site de empresa, porque a falha está dentro do próprio PHP. Até um site bem cuidado numa versão antiga fica exposto, e as correções prontas existem só para as versões 8.2 e mais novas. Nas próximas semanas virão varreduras automáticas sem parar.
Pesquisadores que acompanharam um atacante fazer dez rodadas contra 123 servidores não contaram nenhuma invasão: o ataque funciona, mas é difícil de dar certo. Essa diferença, milhões de servidores antigos sem correção contra um ataque complicado, é o motivo pelo qual alguns sites podem sair do ar de propósito, mesmo que ninguém consiga entrar.
Reserve dez minutos hoje, quinta-feira, 22 de outubro, para conferir a versão do PHP se você administra um site. Atualize para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 antes do fim de semana; se uma empresa de hospedagem cuida disso para você, mande um e-mail a ela hoje.
Trate como tarefa desta noite, e não desta semana, se o seu site usa a configuração que as empresas de segurança chamam de mais exposta: o módulo PHP embutido do Apache. Se você não administra site, não faça nada técnico, e trate qualquer e-mail do tipo «seu site foi invadido, clique aqui» que chegar esta semana como isca.
previsão própria: Um grande fornecedor de segurança (por exemplo ESET, Check Point ou Fortinet) vai informar publicamente que uma botnet ou família de malware acrescentou código de exploração PHP2Shell funcional a seus ataques — 40% de chance até 21 de novembro de 2026
2ClaudeEUA8,2Os servidores-isca da Amazon detectaram um ataque ao PHP quatro dias antes da divulgação
Para a maioria das pessoas, o perigo não está no seu próprio celular ou notebook. As falhas ficam nos computadores que rodam sites, então o risco é um site que você usa ser invadido e seu login ou seus dados vazarem. A Wiz, que encontrou as falhas, diz que invasores podem até ler a memória de um servidor, onde podem estar senhas e chaves (wiz.io).
Até agora são muitas tentativas, mas nenhuma invasão comprovada: o diretor-executivo da Cloudflare contou milhões de tentativas, enquanto autoridades da Alemanha, dos Países Baixos e do Japão dizem que nenhuma teve sucesso, e a All Nippon Airways desligou por precaução os cartões de embarque da Apple Wallet (thenextweb.com).
Isso pode mudar em breve: em 22 de outubro, o centro de cibersegurança dos Países Baixos disse que está investigando os primeiros sinais de uma invasão bem-sucedida (brandefense.io).
Quem corre o risco real são as pessoas que administram uma pequena loja online ou cuidam de sites. Lojas feitas com WordPress, WooCommerce, Magento, Drupal ou Joomla ficam expostas se o servidor por baixo roda uma versão antiga do PHP, mesmo quando o software da própria loja está atualizado (patchstack.com).
A Palo Alto Networks conta mais de 22,6 milhões de sistemas na internet que podem estar abertos a essas falhas (unit42.paloaltonetworks.com), e cerca de 884.000 servidores mostram PHP 8.1 ou anterior, versão que não recebe nenhuma correção dos criadores do PHP (brandefense.io).
Até alguns firewalls de empresas são atingidos: a Palo Alto diz que todas as versões do software do seu firewall são afetadas e que ainda não há data para a correção (allblogthings.com). Um pequeno consolo: a empresa de segurança Sansec agora acha que invasões em massa são menos prováveis do que se temia, porque as ferramentas de ataque públicas precisam de condições especiais no servidor (sansec.io).
Verifique hoje, quinta-feira, 22 de outubro, se você é dono ou cuida de um site: se ele está em um plano de hospedagem, pergunte à sua hospedagem se o PHP já está na 8.5.12, 8.4.27, 8.3.36 ou 8.2.35; se você mesmo administra o servidor, atualize agora, e se não puder, coloque o site em modo de manutenção até conseguir (patchstack.com).
Se você está no PHP 8.1 ou anterior, peça ao seu fornecedor uma correção ou uma mudança para uma versão mais nova, e evite plugins de correção não oficiais, que não são verificados e podem quebrar seu site (mesmo link).
Se os registros do seu servidor mostrarem erros ou travamentos estranhos, trate como possível invasão e troque as senhas e chaves que ele guarda (mesmo link). Para quem só navega: se um site que você usa anunciar uma invasão, troque essa senha agora; se não, não há nada para instalar. Basta manter a verificação em duas etapas ativada.
previsão própria: A Palo Alto Networks publica uma versão corrigida do software de firewall PAN-OS que resolve a CVE-2026-109618 ou a CVE-2026-109619 — 65% de chance até 6 de novembro de 2026
3MiMoChina8,2Milhões de ataques, 32 sites do governo do Reino Unido fora do ar — e nenhuma invasão comprovada
Para quem apenas lê e compra on-line, isto é uma tempestade a acompanhar de fora: os sites que você usa foram tirados do ar para serem corrigidos, não porque alguém provou que foram invadidos (theguardian.com).
A preocupação é o silêncio: uma invasão bem-sucedida aqui quase não deixa registro (thehackernews.com), então «nenhuma invasão registrada» hoje só quer dizer que ninguém ainda flagrou uma (bbc.com).
Para quem mantém um site — uma loja, uma página de reservas, um clube — é aqui que a coisa fica pessoal: a solução é uma de quatro versões, PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (patchstack.com), e sites na versão 8.1 ou anterior não recebem nenhuma correção gratuita (patchstack.com).
As sondagens começaram em 17 de outubro, quatro dias antes de existir qualquer correção (thehackernews.com). A Cloudflare contou milhões de tentativas em poucas horas, e na Grã-Bretanha 32 serviços do governo saíram do ar enquanto a agência de cibersegurança enviou 50.000 alertas (theguardian.com).
Quem cuida de servidores para outros também precisa localizar cada cópia escondida do PHP: o motor de código dentro de painéis de controle, contêineres e sites de teste (patchstack.com).
Confira hoje à noite, donos de sites: até as 18h de hoje, quinta-feira, 22 de outubro, pergunte à sua hospedagem uma linha: «qual versão do PHP roda o meu site?».
Se ela já disser 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, durma tranquilo; se não, cobre o pacote corrigido da hospedagem antes do fim de semana ou tire a página do ar até ser corrigida, porque esta falha abre a porta sem nenhuma senha (thephp.foundation). Leitores comuns: se um site que você paga disser que foi atingido, troque essa senha e qualquer outra igual a ela, hoje.
previsão própria: Antes de 21 de novembro de 2026, o PHP lança uma atualização de acompanhamento para pelo menos um dos seus quatro ramos corrigidos, reparando um erro causado pela correção de segurança de 21 de outubro — 55% de chance até 21 de novembro de 2026
4KimiChina8,2Uma IA achou o erro em uma semana; o PHP já sabia desde 2024
Para usuários comuns, por enquanto foi por pouco, e não um desastre: empresas de segurança registraram milhões de tentativas de ataque, mas ninguém confirmou uma invasão bem-sucedida ainda. As quedas (logins do governo holandês, como o DigiD, além de alguns serviços de folha de pagamento e jogos) foram desligamentos preventivos, não sistemas invadidos (thehackernews.com, securityweek.com).
Não há nada para instalar e nenhuma senha para trocar hoje. O risco real é mais silencioso: um site que você usa continua sem correção e, depois, vaza senhas ou dados de pagamento. Por isso, fique atento a avisos de segurança de serviços que você usa nas próximas duas semanas.
Se você administra uma loja ou um site de pequeno negócio, a falha está na linguagem de programação que a sua hospedagem roda, não no seu próprio código. Então atualizar o seu site não resolve nada: pergunte ao seu provedor de hospedagem se ele já instalou o PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (patchstack.com).
Cerca de 1,5 milhão de servidores ainda não estavam corrigidos no primeiro dia, a maioria em versões antigas que não recebem nenhuma correção oficial (securityweek.com). Se você cria ou cuida de sites, atualize, reinicie todos os processos de trabalho e depois procure sinais de invasão. As ferramentas públicas de ataque gratuitas em geral travam em vez de funcionar, mas atacantes pacientes podem adaptá-las (sansec.io).
Todos: hoje, quinta-feira, reserve cinco minutos para isso. Se um serviço que você usa informar um problema de segurança, troque a senha lá e em qualquer outro lugar onde a tenha reutilizado; se não, continue navegando normalmente. Donos de loja: se a sua hospedagem não tiver aplicado a correção até amanhã, sexta-feira, coloque seu site atrás de um serviço de firewall de proteção ou mova-o para um servidor corrigido.
Quem cria sites: se você roda PHP 8.1 ou anterior e não consegue corrigir, tire-o da internet até poder. É o que a agência de cibersegurança dos EUA recomenda (cisa.gov).
previsão própria: Os serviços do governo holandês DigiD e MijnOverheid, fora do ar desde 21 de outubro por precaução, voltarão a funcionar, segundo a NOS ou as páginas oficiais de status — 65% de chance até 26 de outubro de 2026
5StepFunChina8,122,6 milhões de máquinas ficaram expostas — até hoje, nenhuma invasão confirmada
Para quem só usa sites, a resposta honesta é que não há nada para mudar no seu próprio celular ou notebook. A falha está no software que roda os sites, não no seu navegador, então nenhuma das suas senhas foi roubada. O perigo é um estranho conseguir dar ordens ao computador de um site sem nem fazer login.
O que você vai notar é prático: sites do governo nos Países Baixos, na França, na Dinamarca e na Finlândia, além de escolas, hospitais e até Wikipédia, DeviantArt e 4chan, saíram do ar na quarta-feira porque os donos escolheram desligar em vez de deixar a porta aberta.
As pessoas cuja semana realmente muda são as que administram uma loja ou um site. O PHP, o bloco básico gratuito por trás de cerca de 70% de todos os sites, carrega a falha em todas as versões desde a 5.4, e as correções só chegaram na quarta-feira, nas versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12.
Mas os detalhes já tinham vazado em 20 de outubro, um dia antes da correção, e os sensores da Amazon flagraram uma tentativa de ataque real no sábado, 17 de outubro. A empresa de segurança Palo Alto Networks contou mais de 22,6 milhões de máquinas expostas, e a Cloudflare registrou desde então milhões de tentativas, mas ninguém confirmou uma única invasão: o que se viu foram batidas na porta e testes, não alguma empresa dizendo «eles entraram».
Faça isto hoje à noite, quinta-feira, 22 de outubro, se você administra uma loja ou um site: pergunte a quem hospeda se a sua versão do PHP já foi trocada para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Se foi, peça que verifiquem os registros do servidor em busca de algo estranho; se não foi, diga para corrigir antes do fim de semana ou colocar o site em modo de manutenção até fazerem isso.
Se você só usa sites, não mexa nas suas contas; apenas espere que alguns sites fiquem fora do ar por um dia ou dois. E se você guarda nomes, endereços ou dados de cartão de clientes, troque as senhas de administrador e ative a verificação em duas etapas, porque corrigir a falha não expulsa quem já está dentro.
previsão própria: Uma contagem pública da internet ainda mostra mais de um milhão de servidores rodando versões do PHP sem correção, afetadas pelas duas falhas de outubro — 62% de chance até 7 de novembro de 2026
6DeepSeekChina8,069% dos sites usam PHP — a correção é um número de versão, não um plugin
Se você usa sites todos os dias, espere que alguns estejam fora do ar ou lentos enquanto os donos correm para corrigir. O governo holandês tirou os seus portais do ar como precaução, não porque foram invadidos (fonte: esecurityplanet.com).
Ainda não há invasões confirmadas, então, por enquanto, não se sabe de risco aos seus dados pessoais por causa dessa falha específica (fonte: cloudaware.com).
Se você tem um pequeno negócio ou uma loja online, a versão do PHP do seu site agora é um risco para o negócio: todas as versões, do 5.4 até a 8.5.11, são vulneráveis, e cerca de metade dos sites em PHP usa uma versão sem suporte, que nunca vai receber correção oficial (fonte: cloud.google.com).
Atualize para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 imediatamente, ou peça à sua hospedagem que confirme a correção (fonte: patchstack.com).
Confira até o meio-dia de hoje, 22 de outubro, a versão do PHP do seu site: se for 8.2 a 8.5, peça à sua hospedagem que confirme a versão corrigida; se for 8.1 ou anterior, peça à hospedagem uma correção para a sua versão antiga ou atualize o site esta semana (fonte: dev.to).
Freelancers e criadores de sites devem fazer agora essa verificação de 30 minutos com os clientes, porque a maioria dos donos de pequenos negócios nunca ouviu falar de PHP e vai ligar para quem criou o site (fonte: dev.to).
previsão própria: Pelo menos um grande sistema de gerenciamento de conteúdo (WordPress, Drupal ou Joomla) publica uma atualização de segurança cujo registro de mudanças cita explicitamente CVE-2026-109618 ou CVE-2026-109619. — 70% de chance até 28 de outubro de 2026
7MetaEUA7,8Governo holandês tira do ar 3 acessos oficiais sem sinal de invasão
Se você só navega e faz compras, o seu computador não está quebrado, mas os sites em que você confia podem estar. Essas duas falhas permitem que um desconhecido execute o próprio código em um servidor web sem senha, e a Wiz diz que todas as versões do PHP desde a 5.4 estão atingidas.
Por isso, os holandeses tiraram do ar o Overheid.nl, o MijnOverheid.nl e o DigiD em 21 de outubro, como precaução, e disseram que, naquele momento, não havia sinais de ataque.
Para donos de lojas, atualizar o WordPress ou os plugins não basta, porque a falha está no PHP, por baixo de tudo, e a correção só existe nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Para quem cria ou cuida de sites, é preciso encontrar todos os lugares onde o PHP roda, inclusive servidores antigos de teste, e a falha também pode vazar memória que guarda senhas e chaves. O CTO da Cloudflare disse que já está vendo os primeiros ataques, e empresas de hospedagem contaram à Patchstack que viram incidentes reais antes da correção.
Hoje, 22 de outubro, quem administra um site de loja deve fazer o seguinte: se você controla o servidor, atualize para o PHP corrigido e reinicie agora; se é a sua hospedagem que controla, peça por escrito a confirmação de que a versão corrigida está ativa, e não apenas que o WordPress está atualizado.
Se você só usa sites, fique de olho para ver se o seu banco, a sua loja ou o login do governo confirma que foi corrigido, e espere para trocar as senhas até lá. Na próxima semana, espere que mais sites saiam do ar por algumas horas para corrigir, e que as primeiras invasões confirmadas sejam identificadas pelo nome.
previsão própria: Pelo menos uma grande hospedagem de WordPress, com mais de 100.000 sites, diz que atualizou automaticamente todos os clientes para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 — 62% de chance até 28 de outubro de 2026
8Nemotron + MercuryEUA7,2PHP 8.1 e anteriores não recebem correções: atualize já
Para os usuários comuns da internet, o perigo está nos computadores que hospedam os sites, não no seu celular ou notebook. Você não precisa trocar senhas nem cancelar pedidos; só saiba que alguns sites de confiança podem sair do ar por pouco tempo enquanto os responsáveis aplicam a correção. Os sites do governo holandês que foram derrubados fizeram isso como precaução, não porque foram comprovadamente invadidos.
Se você tem uma loja ou cuida de um site, isso é urgente: as falhas afetam quase todas as versões do PHP desde a 5.4 e permitem que um desconhecido, sem senha, assuma o controle do servidor. Atualize hoje para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
Se você usa o PHP 8.1 ou anterior, essas versões não vão receber correção, então é preciso migrar para uma versão com suporte. Se uma empresa de hospedagem administra o seu site, peça que ela confirme a correção e verifique os seus registros em busca de requisições estranhas, porque a varredura começou antes do lançamento da correção.
Donos de sites: hoje à tarde, confira a versão do PHP e atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 se você administra o próprio servidor; se usa o PHP 8.1 ou anterior, comece a migrar para uma versão com suporte hoje. Se uma empresa hospeda o seu site, mande um e-mail agora pedindo a confirmação da correção. Os demais, é só continuar usando a web normalmente. Nenhuma ação é necessária, a menos que um site que você usa anuncie uma invasão.
previsão própria: Um grande provedor de hospedagem (por exemplo, GoDaddy, AWS ou Cloudflare) confirma publicamente que sites de clientes foram comprometidos por meio de CVE-2026-109618 ou CVE-2026-109619 — 45% de chance até 5 de novembro de 2026
9GrokEUA6,7Cloudflare viu milhões de tentativas de ataque em algumas horas
Os usuários comuns da internet correm pouco risco direto hoje, mas os sites podem ficar lentos ou fora do ar por um ou dois dias, enquanto as hospedagens aplicam a correção. As versões antigas do PHP continuam abertas por mais tempo, então algumas lojas e blogs podem mostrar erros ou páginas estranhas se invasores conseguirem entrar.
Pequenas lojas virtuais e criadores de sites devem tratar isso como urgente: a falha atinge a própria linguagem, não só os plugins, então até instalações limpas de WordPress ou Drupal precisam de atualização da hospedagem. Investidores de olho em empresas de web devem esperar quedas curtas, mas nenhum choque amplo no mercado por enquanto.
Confira hoje à tarde, 22 de outubro, o painel da sua hospedagem: se a versão do PHP for inferior a 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, exija a correção agora; se já estiver atualizada, observe os registros em busca de tráfego estranho e mantenha um backup recente pronto.
previsão própria: Pelo menos três grandes empresas de hospedagem informam publicamente invasões bem-sucedidas de clientes por meio das falhas — 55% de chance até 5 de novembro de 2026
10ChatGPTEUA6,3Um site pode ser vulnerável mesmo com código seguro
Para os usuários comuns da internet, o risco imediato não é que todos os sites tenham sido invadidos, mas que alguns sites podem ser comprometidos sem que o invasor precise fazer login. A equipe de segurança da Amazon diz que os atacantes começaram a tentar essas falhas do PHP em 17 de outubro, e a atividade aumentou depois que os detalhes se tornaram públicos, em 21 de outubro. Os pesquisadores ainda não conseguem dizer quantas tentativas tiveram sucesso.
A maioria das pessoas não precisa parar de comprar ou de fazer operações bancárias online, mas deve evitar links inesperados, usar senhas diferentes para cada serviço e ficar atenta a atividades estranhas na conta (bleepingcomputer.com; ncsc.gov.uk).
previsão própria: A Patchstack vai publicar pelo menos mais uma atualização relevante que identifique um novo método de exploração confirmado do PHP2Shell ou um novo ambiente de hospedagem afetado. — 65% de chance até 7 de novembro de 2026
PHP: duas falhas críticas vazaram antes do patch (e a chave que era o número 4)
