Falha no PHP o que sites no Brasil precisam saber

A falha no PHP divulgada em 21 de outubro de 2026 pode permitir que alguém na internet execute comandos no servidor sem login. As falhas receberam os códigos CVE-2026-109618 e CVE-2026-109619. A comunidade de segurança as apelidou de php2shell. Por isso a imprensa e órgãos oficiais pediram ação no mesmo dia.

Se você é dono de site, gestor ou responsável por um serviço online e não programa, a pergunta prática é outra. Seu site corre risco, quem precisa agir e o que pedir por escrito à hospedagem ou ao desenvolvedor. Além disso, este texto usa datas absolutas e separa o que a imprensa reportou do que as fontes oficiais confirmam. Também aponta o que ainda não há confirmação pública até 21 de outubro de 2026.

O passo a passo técnico de correção já está no guia técnico de correção do php2shell do Basilisk. Aqui o foco é contexto, prioridade e decisão para quem precisa cobrar o fornecedor sem virar administrador de servidor.

O que aconteceu com o PHP e por que virou notícia#

Virou notícia porque a falha não está em um plugin isolado. Ela está no motor do PHP que processa pedidos na web. Em linguagem simples, execução remota de código sem autenticação significa que alguém pode tentar fazer o servidor rodar comandos como se fosse o próprio sistema. Porém não precisa de usuário e senha do site.

O que as fontes técnicas descrevem#

O projeto PHP descreveu duas fraquezas. Uma lida com falta de memória. A outra lida com estado interno que sobra entre pedidos. O aviso oficial está no arquivo de notícias de 2026 do php.net. A gravidade oficial no CVSS versão 4.0 é 9,2 em 10 para as duas falhas. Algumas bases e reportagens citam notas em outras versões do CVSS, como 9,8 ou até 10,0. No entanto, o número que o aviso de 20 e 21 de outubro de 2026 do PHP e o registro CVE enfatizam é o 9,2.

O que a imprensa destacou no mesmo dia#

Segundo a BBC News Brasil, governos e organismos em vários países orientaram correção urgente. Quando a correção não cabia no prazo, pediram suspensão temporária de páginas. A matéria cita desligamentos ou precaução na Finlândia, na prefeitura de Edimburgo e em plataformas da própria BBC. Também há menções a órgãos nos Países Baixos e medidas da Wikimedia em torno da Wikipedia. A BBC registrou ainda a estimativa de que cerca de 70% da internet usaria PHP. Porém deixou claro que não conseguiu verificar esse percentual.

Na prática, o que eu vejo com mais frequência é o gestor achar que atualizou o WordPress no painel e já está protegido. Nesta falha a proteção completa passa pela versão do PHP no servidor, não só pelo sistema de conteúdo. Quem trata o assunto como problema de plugin atrasa o único remédio que o próprio projeto PHP descreve como seguro.

Linha do tempo da falha no PHP#

A linha do tempo pública começa meses antes da manchete. Depois disso, fecha em 21 de outubro de 2026.

Da descoberta em agosto de 2026 ao aviso prévio#

Em agosto de 2026, pesquisadores da Calif, da OpenAI e depois da Wiz identificaram e aprofundaram as falhas. Eles trabalharam em divulgação coordenada e sigilosa enquanto as correções eram preparadas, segundo relatos técnicos dessas empresas e da cobertura que cruzou o processo. Em 20 de outubro de 2026 o projeto PHP avisou que haveria lançamento de segurança no dia seguinte, às 14h00 UTC. A Fundação PHP também registrou que IDs das CVEs circularam com nota errada de 10,0 e horário incorreto, o que antecipou o aviso público.

O dia 21 de outubro de 2026 e as versões corrigidas#

Em 21 de outubro de 2026 as versões corrigidas saíram e as falhas passaram a ser discutidas em aberto. As versões oficiais corrigidas, segundo o php.net, a CISA e a Recomendação 19/2026 do CTIR Gov, são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e anteriores não recebem atualização regular do projeto. Há menção pública a backports mínimos de código-fonte para 7.4, 8.0 e 8.1 para quem compila do zero ou tem fornecedor LTS. Assim, a orientação oficial é falar com o fornecedor da distribuição ou migrar para uma linha suportada.

Há um ponto em que as fontes divergem e precisa ficar transparente. Empresas como Google Cloud, Cloudflare e Wiz falaram em risco desde versões muito antigas, inclusive a partir do PHP 5.4. O registro CVE e o anúncio do time de segurança do PHP listam de forma explícita as linhas 8.2 a 8.5 corrigidas. Além disso, tratam 8.1 e mais antigos como fora do suporte oficial. Para o dono de site, a leitura prudente é a mais restritiva. Se o seu ambiente ainda roda PHP antigo, não assuma que está fora do escopo só porque a tabela CVE destaca 8.2 em diante.

O erro que mais custa caro aqui é esperar a próxima janela de manutenção do mês como se fosse um upgrade cosmético. Em 21 de outubro de 2026 as agências pediram ação imediata. Por isso o atraso vira exposição enquanto provas de conceito e tentativas já circulam em relatos abertos.

O que se sabe sobre a falha PHP sites brasileiros#

Até 21 de outubro de 2026 há confirmação pública de resposta institucional brasileira. Porém não há, nas matérias conferidas nesta redação, inventário oficial de sites brasileiros derrubados ou de hospedagens nacionais nomeadas como comprometidas por causa desta falha. O CTIR Gov, ligado ao Gabinete de Segurança Institucional, publicou a Recomendação 19/2026 pedindo identificação de sistemas com PHP e atualização imediata. O Alerta 93/2026 reforçou a mesma linha com referência às duas CVEs. O CISC GOV.BR também registrou alerta sobre as mesmas vulnerabilidades. Isso mostra mobilização do governo federal. Ainda assim não prova por si só quantos portais brasileiros saíram do ar.

Na cobertura jornalística em português, a matéria do UOL Cotidiano e a peça da BBC News Brasil tratam sobretudo do quadro internacional e da pressão para tirar serviços do ar. França, Países Baixos, Finlândia e outros exemplos europeus aparecem com desligamento preventivo. Portanto, impacto no Brasil em número de sites fora do ar, empresas atingidas ou hospedagens específicas permanece sem confirmação pública nomeada até a data desta matéria. O tema php2shell Brasil, nesta data, aparece como alerta e orientação, não como inventário de incidentes locais.

Isso não significa risco baixo para o país. Significa que a evidência pública, nesta data, é de alerta e orientação. Muitos sites brasileiros usam PHP por meio de WordPress, Joomla, Drupal, Magento e sistemas sob medida. O risco existe onde houver instalação vulnerável exposta à internet. A prova de que já foi explorado no Brasil é outra afirmação, e ela ainda não aparece confirmada nas fontes oficiais abertas consultadas.

Muita gente acha que ausência de manchete local equivale a ausência de risco, e quase sempre está enganada, porque o atacante não precisa de notícia nacional para varrer a internet. O critério útil é a versão do PHP do seu servidor e a exposição pública, não o volume de reportagens com a palavra Brasil no título.

Quem corre risco de verdade e quem provavelmente não#

Corre risco de verdade quem tem site ou sistema web rodando PHP em versão anterior às corrigidas e acessível pela internet.

Sites e sistemas expostos na internet#

O aviso do PHP inclui instalações que atendem pedidos web em PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O próprio projeto avalia risco mais alto no mod_php, com exploração demonstrada por pedido sem login antes mesmo do código do site rodar. A CISA e o NCSC do Reino Unido alinharam a mesma urgência para organizações com PHP voltado à web.

Quem fica em prioridade mais baixa e as armadilhas#

Provavelmente não está no mesmo nível de urgência quem não usa PHP no servidor público. Exemplos são sites estáticos sem motor PHP, ou aplicações em outras linguagens sem componente PHP embutido. Ainda assim há armadilha. Produtos, painéis, appliances e imagens de contêiner podem trazer PHP embutido sem o gestor perceber. A CISA lembrou que o PHP muitas vezes é componente de outro software e a presença dele pode não ser óbvia no inventário.

Outra nuance importa. Atualizar o tema do WordPress ou instalar um plugin de segurança não fecha esta falha. A correção completa é atualizar o PHP do servidor para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou receber backport confiável do fornecedor quando a linha for antiga. Firewall de aplicação web pode reduzir exposição em alguns caminhos. A Cloudflare comunicou proteções no WAF. Porém o projeto PHP e a CISA tratam atualização como único remédio completo. Mitigação temporária não vira certificado de segurança.

Na prática, o que eu vejo com mais frequência em empresas médias é o site institucional em hospedagem compartilhada e o ERP interno em outro servidor, e só o marketing é cobrado. Os dois precisam de inventário. Se o ERP fala PHP e tem interface web, ele entra na fila de prioridade junto com o blog.

O que o dono do site deve fazer hoje#

Hoje, 21 de outubro de 2026, a resposta prática de PHP vulnerabilidade o que fazer para o leigo é cobrar evidência. Não é improvisar comando no servidor. Os passos abaixo são de gestão e prioridade. O detalhe técnico de patch está no guia técnico de correção do php2shell.

Inventário e versão exata#

1. Liste onde há site ou sistema web sob sua responsabilidade, inclusive loja, área do aluno, intranet exposta, formulário de ouvidoria e painel de afiliados. Inclua o que um fornecedor hospeda por você.
2. Pergunte por escrito à hospedagem ou ao time de TI qual versão exata do PHP roda em cada ambiente, no formato maior.menor.patch, por exemplo 8.3.36. A resposta “PHP 8” sem o patch não basta.
3. Peça confirmação de que a versão já está em 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou que o fornecedor aplicou correção backport documentada para linha antiga. Peça prazo e horário previstos se ainda não aplicou.

Prioridade, monitoramento e o que recusar#

1. Priorize o que está na internet pública. A CISA recomenda colocar offline o que não puder ser corrigido de imediato, sobretudo em PHP 8.1 ou anterior sem patch do fornecedor. Essa decisão tem custo de negócio e precisa ser consciente, não teatral.
2. Peça que o fornecedor descreva o que monitorará nas próximas horas e dias, como processos estranhos do PHP, arquivos novos e conexões de saída inesperadas. Monitorar não substitui patch, e ajuda a detectar abuso se alguém chegou antes.
3. Recuse limpeza milagrosa vendida por mensagem fria ou anúncio. Sem diagnóstico e sem evidência, isso costuma ser golpe ou gasto inútil. O caminho legítimo é o fornecedor contratado, a equipe interna ou um profissional com contrato e responsabilidade definidos.
4. Se a sua organização já tem ou deveria ter um programa de gestão de vulnerabilidades, use este incidente para testar se o inventário de software existe de verdade. Se ninguém sabe onde roda PHP, o problema é maior que esta CVE.

Cada recomendação acima tem limite. Pedir a versão não garante resposta honesta. Colocar o site offline pode interromper serviço público ou venda. Monitoramento só funciona se alguém olhar o alerta. O benefício é reduzir a janela em que um atacante encontra o servidor ainda vulnerável. O risco de não agir é manter a porta aberta enquanto provas de conceito circulam.

O caminho que eu recomendo à maioria dos gestores sem equipe própria é um e-mail curto no mesmo dia, com cópia para o comercial da hospedagem e para quem paga a fatura, pedindo versão, status do patch e prazo. Cobrança documentada muda a prioridade do fornecedor mais depressa do que um chamado genérico de verificar segurança.

O que perguntar à hospedagem ou ao desenvolvedor#

Pergunte de forma que a resposta seja verificável. Assim você evita o “está tudo bem” sem número.

Checklist por escrito para a hospedagem PHP atualizar#

Peça a versão atual do PHP em cada site. Peça o horário em que a correção foi ou será aplicada. Pergunte se houve reinício dos processos PHP depois da atualização. Pergunte se existe WAF e se ele foi ajustado só como camada extra. Pergunte se há plano caso a atualização quebre um sistema legado. Depois disso, peça de novo o número da versão no formato completo.

Peça também o que acontece com PHP 8.1, 8.0, 7.4 ou mais antigo no seu contrato. O projeto PHP não mantém essas linhas no fluxo normal. Ou o fornecedor tem backport, ou a migração para linha suportada precisa de prazo e teste. Uma resposta do tipo “vamos avaliar” sem data é fraca para uma falha desta classe.

Como unir hospedagem e desenvolvedor#

Para órgão público e empresa com fornecedor de software sob medida, inclua a pergunta sobre produtos que embutem PHP sem parecer um site WordPress. Painéis, portais de protocolo e sistemas de inscrição muitas vezes escondem a linguagem. O CTIR Gov pediu justamente que as instituições identifiquem sistemas, servidores, aplicações e serviços que utilizam PHP, não só a home institucional.

Uma armadilha comum é aceitar print do painel dizendo servidor seguro sem número de versão. Outra é confundir atualização do painel de hospedagem com atualização do PHP do site. Se a resposta vier vaga, peça reabrir o chamado com o identificador das CVEs CVE-2026-109618 e CVE-2026-109619, para a equipe técnica saber exatamente qual aviso atender.

Na prática, o que eu vejo com mais frequência é o desenvolvedor da aplicação dizer que o código dele está ok e a hospedagem dizer que o cliente precisa autorizar o upgrade. Os dois podem estar parcialmente certos e o site continuar vulnerável no meio. Sua pergunta precisa unir as pontas e nomear quem aplica o binário do PHP.

O que ainda não se sabe#

Ainda não está pacificado, em fonte oficial única, o alcance real de exploração bem-sucedida em produção em 21 de outubro de 2026. A CISA escreveu que, no momento da publicação do alerta, não havia observado exploração dessas vulnerabilidades. Ainda assim classificou o risco como urgente se o patch não for aplicado. O Centro Cibernético do Canadá registrou relatos abertos de prova de conceito e afirmou não ter identificado exploração ativa naquele momento, com a ressalva de que isso pode mudar rápido. A Cloudflare, por outro lado, comunicou proteções no WAF e disse ter observado tráfego de ataque cedo no dia, tratando a proteção como paliativo enquanto o patch não chega.

Também não há, até esta data, confirmação pública consolidada de quantos sites brasileiros foram comprometidos ou quantas hospedagens nacionais já fecharam 100% da base. Não há lista oficial simples de todos os produtos afetados no Brasil, porque PHP aparece embutido em pilhas diferentes. E não está resolvida de forma idêntica a situação de cada versão antiga. Fornecedores LTS e distribuições podem publicar pacotes em ritmos distintos.

Essa incerteza não autoriza esperar. Significa que o gestor deve tratar o patch como prioridade alta mesmo sem ter visto o nome da sua empresa no jornal. O que muda a resposta é a evidência nova de exploração em massa ou o comunicado do seu fornecedor de que o ambiente já está nas versões corrigidas.

O erro que mais custa caro aqui é transformar “ainda não confirmado” em “então estou seguro”. Na segurança, ausência de confirmação pública de abuso não é atestado negativo. É só o estado do conhecimento naquele horário.

O que dizem as fontes oficiais e onde acompanhar#

As fontes que importam para fato técnico são o aviso do php.net, os advisories GHSA do repositório php-src, os registros CVE e os alertas de agências. No Brasil, acompanhe CTIR Gov, CISC GOV.BR e comunicações do seu setor. Nos Estados Unidos, a CISA publicou alerta em 21 de outubro de 2026 pedindo patch imediato e, se necessário, tirar de linha sistemas em PHP sem correção. No Reino Unido, o NCSC descreveu o problema de corrupção ligada a falta de memória e o risco de execução remota sem autenticação.

Para o gestor, a regra prática é simples. Manchete explica o clima. Aviso oficial define versão corrigida e o que conta como remédio completo. Se uma rede social disser que já tem exploit universal para qualquer site, confira no php.net e na agência antes de pagar qualquer serviço emergencial de desconhecido.

Acompanhar também significa pedir ao fornecedor um retorno depois do patch, não só a promessa. Versão instalada, data e hora, e se houve regressão em alguma aplicação. Atualização apressada pode quebrar sistema antigo. Quebra controlada em horário combinado ainda é melhor do que invasão silenciosa.

Muita gente acha que basta salvar o link da notícia no WhatsApp da equipe, e quase sempre está enganada, porque o link não muda a versão do servidor. O acompanhamento útil fecha com evidência do ambiente de vocês.

Perguntas frequentes sobre a falha no PHP#

Estas perguntas reúnem as dúvidas mais comuns de donos de site e gestores sem formação técnica. As respostas são curtas de propósito, para você usar no e-mail à hospedagem ou na reunião com o desenvolvedor ainda hoje.

Meu site usa WordPress. Atualizar o WordPress resolve?#

Não por si só. WordPress roda sobre o PHP do servidor. A correção completa exige que a hospedagem ou o administrador atualize o PHP para uma das versões corrigidas ou aplique backport do fornecedor. Atualizar só o núcleo, tema ou plugin do WordPress não substitui isso.

Se a hospedagem tem firewall, posso esperar?#

Firewall de aplicação pode reduzir alguns caminhos de ataque e compradores de proteção como a Cloudflare comunicaram regras específicas. O projeto PHP e a CISA tratam a atualização do PHP como única solução completa. Esperar só no firewall deixa risco residual e pode falhar quando o atacante muda a forma do pedido.

Órgãos e empresas no Brasil já foram atingidos?#

Até 21 de outubro de 2026 há alertas e recomendações do CTIR Gov e do CISC, e não há, nas fontes conferidas para esta matéria, confirmação pública nomeada de comprometimento em massa de sites brasileiros por esta falha. Ausência de lista pública não elimina o risco do seu ambiente se ele ainda estiver vulnerável.

PHP antigo, como 7.4 ou 8.1, está fora de perigo?#

Não. O projeto PHP não entrega patch regular nessas linhas e recomenda falar com o fornecedor LTS ou migrar. Há backports mínimos de código-fonte para quem compila, e distribuições podem publicar pacotes próprios. Enquanto não houver correção aplicada no seu servidor, o risco permanece.

Pagar uma empresa que aparece oferecendo limpeza php2shell é boa ideia?#

Em geral, não, se a abordagem for fria, sem contrato prévio e sem diagnóstico. O caminho seguro é o fornecedor que já opera o servidor, a equipe interna ou um profissional contratado com escopo escrito. Desligar o site e aplicar o patch oficial resolve a vulnerabilidade. Limpeza sem evidência de invasão costuma ser gasto ou golpe.

Onde confiro a informação oficial sem depender de rede social?#

Comece pelo aviso no php.net, pelos registros CVE-2026-109618 e CVE-2026-109619, pelo alerta da CISA e, no Brasil, pelas publicações do CTIR Gov. Para o seu caso concreto, a confirmação que importa é a versão do PHP informada por escrito pela hospedagem ou pela TI.

Conclusao#

A falha no PHP divulgada em 21 de outubro de 2026 é grave o bastante para tirar páginas do ar em vários países e para acionar alertas oficiais no Brasil, e ainda assim o gesto que protege o seu site continua prosaico. Descobrir a versão exata do PHP, cobrar a atualização para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou o backport do fornecedor, e não confundir isso com atualizar só o sistema de conteúdo.

Para a maioria dos donos de site e gestores sem time de segurança, o primeiro passo é o e-mail documentado à hospedagem e ao desenvolvedor ainda hoje, com as duas CVEs no assunto e pedido de versão completa depois do patch. A resposta muda se o sistema for legado sem suporte, se houver obrigação de continuidade de serviço público ou se já existir indício de abuso. Nestes casos a decisão pode incluir isolamento temporário e apoio especializado, sempre com o custo e o risco explícitos.

Ignore quem vende milagre e ignore também a tentação de achar que a ausência de manchete com o nome da sua empresa é um escudo. A proteção real aparece quando a versão corrigida está instalada e alguém responsável confirma isso por escrito.

Este texto tem caráter informativo e educativo sobre a falha no PHP e o impacto potencial em sites no Brasil. Não substitui avaliação do seu fornecedor de hospedagem, da sua equipe de segurança ou de profissional contratado para o seu ambiente específico.