Falha crítica no PHP: o que aconteceu e como se proteger
Na quarta-feira (21), duas vulnerabilidades críticas no PHP viraram um dos assuntos de segurança digital mais comentados do ano. Sites de governos saíram do ar em vários países, tribunais brasileiros suspenderam sistemas e a Anatel retirou o seu Sistema Eletrônico de Informações (SEI) do ar. O motivo: uma falha no próprio PHP, a linguagem que roda por trás de quase 70% dos sites cuja tecnologia de servidor é conhecida.
Se você tem um site, uma loja virtual ou um blog, a pergunta útil é uma só: o meu está exposto e o que preciso fazer hoje? Esta matéria reúne o que se sabe até agora a partir dos alertas oficiais do projeto PHP, do comunicado da PHP Foundation e da cobertura da imprensa, explica o que um ataque desse tipo pode causar na prática (com exemplos) e traz um passo a passo para quem não é da área de tecnologia.
O que você vai encontrar aqui
O que aconteceu
As falhas receberam os códigos CVE-2026-109618 e CVE-2026-109619 e nota 9,2 em 10 na escala de gravidade (CVSS v4). Em termos práticos, ambas podem permitir execução remota de código sem autenticação: alguém na internet envia requisições a um servidor vulnerável e, em determinadas condições, consegue fazer o servidor executar comandos, sem precisar de login. A Cloudflare apelidou o conjunto de php2shell, segundo o Tecnoblog.
O projeto PHP publicou correções na quarta-feira, nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. De acordo com o TecMundo e o Tecnoblog, as falhas afetam instalações do PHP da versão 5.4 até a 8.5.11. A PHP Foundation, que financia desenvolvedores da linguagem, foi direta: quem usa PHP precisa atualizar imediatamente, e não existe solução alternativa totalmente segura.
O assunto explodiu por dois motivos. Primeiro, a falha está no núcleo do PHP, e não em um plugin ou em um sistema específico. Segundo, os detalhes escaparam antes da data prevista, o que acelerou a reação de governos e empresas. Os dois pontos explicam por que órgãos tiraram serviços do ar mesmo sem confirmação de invasões.
O que é o PHP e por que a falha atinge tanta gente
O PHP é uma linguagem de programação gratuita e de código aberto, criada para a web. Ela roda no servidor, e não no navegador do visitante: quando você abre uma página, é o PHP que monta o conteúdo antes de enviá-lo. Segundo a W3Techs, citada pelo Canaltech, 69,3% dos sites com linguagem de servidor conhecida usam PHP.
Isso inclui os sistemas de gestão de conteúdo mais usados do mundo. Entre eles estão o WordPress (cerca de 40% dos sites da internet, segundo o Olhar Digital), o Drupal, o Joomla e o Magento. Em muitos casos, o dono do site nem sabe que usa PHP: contratou um site pronto, uma loja virtual ou um blog, e a tecnologia fica escondida por baixo.
Há um detalhe que ajuda a entender o tamanho do problema. De acordo com o TecMundo, 65,2% dos sites em PHP usam a versão 8. Fazendo a conta, cerca de um terço roda versões mais antigas, algumas delas já sem suporte oficial. Para esses, a correção não é um clique: é uma migração.
Como as falhas funcionam, em linguagem simples
Os alertas oficiais do projeto no GitHub são técnicos, mas a ideia central pode ser explicada sem jargão. As duas falhas têm a mesma raiz: o PHP deixa a memória do servidor em um estado inconsistente quando algo dá errado, e depois usa essa memória como se estivesse em ordem. Um atacante habilidoso consegue transformar essa confusão em controle do servidor.
Falha 1 (CVE-2026-109618): estouro de memória que corrompe o processamento
O PHP tem um limite de memória por requisição. Quando uma requisição estoura esse limite, o PHP interrompe o trabalho de forma abrupta. O alerta oficial explica que, em alguns pontos do processo, a memória da requisição ainda está parcialmente preparada. Se a interrupção acontece ali, o PHP não percebe e deixa os dados em estado inválido; mais tarde, na rotina de encerramento da requisição, ele lê esses dados e decide o que fazer com base neles. É esse comportamento que pode ser transformado em execução de código.
Segundo o alerta, o atacante consegue provocar o estouro de memória enviando pedidos montados de forma especial, por exemplo formulários com muitas partes ou cabeçalhos que consomem muito mais memória dentro do PHP do que o tamanho que ocupam no envio. A Fundação destaca um ponto grave: no Apache com mod_php, uma requisição sem login pode acionar o problema antes de qualquer código da aplicação rodar, e a execução remota foi demonstrada com as configurações padrão.
Falha 2 (CVE-2026-109619): memória "do passado" sendo reaproveitada
O PHP mantém alguns estados globais que apontam para a memória de uma requisição. Se um erro fatal interrompe o processo antes da limpeza, esse estado continua apontando para uma memória que já foi liberada. Uma requisição seguinte, atendida pelo mesmo processo, pode então usar essa memória "velha" (o que os especialistas chamam de use-after-free). Com a disposição certa da memória, isso pode levar à execução remota de código. A Fundação diz que a prova de conceito foi demonstrada contra uma aplicação real no Apache com mod_php.
Nota 9,2: por que não é 10, e por que mesmo assim é grave
A pontuação indica ataque pela rede, sem senha e sem interação de ninguém, com impacto alto em confidencialidade, integridade e disponibilidade. O que segura a nota abaixo de 10 é a complexidade alta do ataque: a confiabilidade da exploração depende da versão do PHP, das extensões, do que há na frente do servidor e do desenho da memória. Segundo o alerta, vários processos de atendimento e tráfego de outros usuários podem aumentar o número de tentativas necessárias, mas não eliminam a condição. Ou seja: não é um ataque trivial, mas foi demonstrado e tende a ser automatizado.
Um recado importante: a Fundação afirma que a única mitigação completa é atualizar. As medidas de configuração descritas no alerta (como limitar o tamanho das requisições e bloquear formulários de envio de arquivos que o site não usa) reduzem a exposição, mas não substituem a atualização.
As consequências, com exemplos
"Execução remota de código" soa abstrato. Na prática, significa que alguém passa a mandar no servidor com os mesmos poderes do seu site. Pelo alerta oficial, o impacto confirmado é a execução de código como a conta do servidor web: ela lê os arquivos do site, fala com o banco de dados e usa tudo o que o site usa. O TecMundo acrescenta, citando a Wiz, que é possível ler dados sensíveis da memória, como senhas, tokens de acesso e chaves de API.
Os exemplos abaixo são ilustrativos: mostram o que esse tipo de falha permite, e não relatam ataques específicos que tenham acontecido até agora. As fontes não confirmam invasões bem-sucedidas.
Exemplo 1: a loja virtual que perde os dados dos clientes
Imagine uma loja em WordPress com WooCommerce, rodando em uma hospedagem compartilhada com PHP desatualizado. O atacante executa código e abre o arquivo de configuração do site, onde estão o usuário e a senha do banco de dados. Com isso, copia a tabela de clientes: nome, CPF, e-mail, telefone e endereço. A empresa passa a ter um incidente de dados pessoais. A LGPD prevê multas que podem chegar a 2% do faturamento, limitadas a R$ 50 milhões por infração, além da obrigação de comunicar a ANPD e os titulares. Para uma loja pequena, o custo reputacional costuma pesar mais do que a multa.
Exemplo 2: o "skimmer" escondido na página de pagamento
Em vez de roubar tudo de uma vez, o invasor pode alterar um arquivo da página de checkout para incluir um pequeno script que copia os dados do cartão enquanto o cliente digita. A loja continua funcionando normalmente, ninguém percebe e, semanas depois, bancos e clientes começam a relatar fraudes com origem no seu site. É um dos golpes mais antigos do comércio eletrônico, e uma falha de execução remota é uma das portas de entrada clássicas para ele.
Exemplo 3: o site institucional que vira vitrine de golpe
Um escritório de contabilidade tem um site simples. O invasor não toca no visual: cria páginas escondidas com links para sites de apostas, remédios e cassinos e redireciona visitantes vindos do Google. O Google detecta, marca o site como "possivelmente invadido", a posição nas buscas despenca e o navegador pode exibir um aviso de site perigoso. A empresa perde meses de trabalho de SEO e a confiança de quem tentava contratar. Se o site tem anúncios, uma suspensão pelo AdSense também fica no horizonte.
Exemplo 4: o servidor que vira "ponte" para outros alvos
Os servidores guardam credenciais que dão acesso a outros lugares: contas de e-mail, serviços de pagamento, armazenamento em nuvem, APIs de terceiros. Se o invasor lê essas chaves da memória, ele passa a usar a sua conta para enviar milhares de e-mails de golpe (e o domínio da empresa entra em listas de spam) ou para acessar dados em outros sistemas. Em hospedagens compartilhadas e em agências que mantêm vários sites de clientes na mesma conta, uma invasão pode se espalhar para todos os sites do mesmo lugar.
Exemplo 5: o site "lento" que está minerando criptomoeda
Nem toda invasão é barulhenta. Um programa de mineração de criptomoeda instalado no servidor consome processamento e deixa o site lento. O dono culpa a hospedagem, a hospedagem percebe o consumo anormal e suspende a conta. O resultado é o mesmo: site fora do ar, receita perdida e uma investigação que começa tarde.
Exemplo 6: o sequestro de arquivos
Com acesso ao servidor, o atacante também pode criptografar arquivos e pedir resgate para devolvê-los, o chamado ransomware. Sem backup fora do servidor, o negócio digital pode parar por dias. Por isso, backup é parte do plano de segurança, e não um item opcional.
Por que governos tiraram sistemas do ar
Parece exagero uma instituição inteira desligar sistemas por causa de uma falha que, até aquele momento, ninguém tinha confirmado ser explorada. Mas, para órgãos públicos, a conta de risco é diferente da de um site comum. Os sistemas afetados no Brasil ajudam a entender isso, segundo o Canaltech:
- SEI (Sistema Eletrônico de Informações): usado por empresas, advogados e cidadãos para acompanhar processos administrativos, enviar documentos, apresentar petições e fazer assinaturas eletrônicas. A Anatel confirmou que o retirou do ar por causa das vulnerabilidades no PHP e esclareceu que "o caso não se trata de uma falha ou vulnerabilidade inerente ao SEI". Também informou que outros sistemas em PHP, como Moodle e Joomla, podem ser afetados. A suspensão do SEI não afeta as redes de telefonia e internet.
- TRF1: suspendeu temporariamente o acesso externo ao SEI, seguindo recomendação do TRF4, sem previsão de retorno.
- Justiça Federal da 4ª Região (RS, SC e PR): interrompeu o acesso externo aos sistemas a partir das 11h. As ferramentas continuaram funcionando dentro das dependências.
- TRF6 (Minas Gerais): suspendeu o expediente e os prazos processuais em toda a Justiça Federal do estado, segundo o portal O Fator.
- Entre os sistemas citados com problemas estão o eproc (tramitação de processos judiciais), o SEI, o Moodle e os portais e intranets.
O raciocínio é o seguinte. Um sistema de processos guarda documentos sigilosos, peças judiciais, dados de empresas e de pessoas, e assinaturas eletrônicas. Se alguém invadir e alterar um documento, a confiança no processo inteiro fica comprometida, e refazer isso custa muito mais do que alguns dias de indisponibilidade. Um exemplo ilustrativo: um invasor com acesso a um sistema de tramitação poderia ler petições sigilosas antes de serem protocoladas ou adulterar documentos anexados, o que contamina decisões e abre disputas jurídicas. Por isso a escolha foi a mais conservadora: suspender o acesso externo, atualizar e só então reabrir. Em um caso, isso incluiu parar prazos processuais, para que ninguém seja prejudicado por não conseguir acessar o sistema.
O movimento foi internacional. Segundo o TecMundo, o CERT-EU, a equipe de resposta a incidentes da União Europeia, emitiu um alerta severo recomendando aplicar a correção imediatamente ou, se isso fosse impossível, desconectar temporariamente servidores expostos à internet. Na Holanda, portais de previdência, de ministérios, a agência de cibersegurança do país e até sites de partidos políticos saíram do ar de forma preventiva. Na Finlândia, o provedor estatal de TI isolou redes públicas. Alemanha, Bélgica e França também retiraram serviços digitais do ar, de acordo com o Canaltech.
Nos Estados Unidos, o Olhar Digital relata, com base na Reuters, que a CISA recomendou a atualização imediata e informou não ter observado exploração das falhas até aquele momento, enquanto a NSA alertou que vulnerabilidades desse tipo podem abrir caminho para arquivos e bancos de dados dos servidores. No Brasil, o CTIR Gov, ligado ao Gabinete de Segurança Institucional, publicou um alerta oficial pedindo que as instituições identifiquem os sistemas em PHP e instalem as versões corrigidas, ou avaliem suspender o acesso externo às aplicações vulneráveis.
A linha do tempo: da primeira pista à correção
A história por trás da falha ajuda a entender por que ela chegou a esse ponto. Segundo a PHP Foundation, a primeira pista veio em 2024, e a divulgação foi tumultuada.
| Quando | O que aconteceu |
|---|
| 2024 | Uma auditoria de segurança da Quarkslab, financiada pela Sovereign Tech Agency e organizada pela OSTIF, leva um desenvolvedor do PHP a encontrar os primeiros sinais do problema de memória. Teoricamente havia uma forma de explorá-lo, mas ninguém tinha demonstrado um ataque concreto. |
| 2024 a 2026 | A equipe de segurança do PHP discute várias soluções, e cada uma tinha custo: quebra de compatibilidade, risco de negação de serviço ou mudanças em muitas extensões de terceiros. A decisão travou várias vezes ao longo de meses. |
| Maio de 2026 | A PHP Foundation cria uma equipe de segurança do ecossistema para ajudar na triagem, na coordenação e no reforço da linguagem. |
| 30 de julho | A empresa Calif começa uma auditoria do PHP, dentro do programa Patch the Planet. |
| 11 de agosto | A Calif reporta uma execução remota de código sem condições especiais, com a mesma causa do problema de 2024. No mesmo dia, a OpenAI reporta a mesma causa de forma independente. A partir daí, corrigir vira prioridade total. |
| 24 de agosto | A Wiz Research reporta outros vetores de ataque. Em 18 de setembro, a OpenAI envia novos vetores. |
| 20 de outubro, ~15h UTC | Os códigos das falhas começam a circular em fóruns e redes, com horário de divulgação e nota de gravidade (10,0) errados. O projeto antecipa o pré-aviso para as 19h30 UTC e muda a liberação para 21 de outubro. |
| 20 de outubro, noite | A Calif publica por engano um vídeo mostrando a sua prova de conceito funcionando contra vários alvos. Cópias circulam e aceleram a criação de ataques de teste. |
| 21 de outubro, 07h41 UTC | A Chainguard, que recebera a correção com antecedência, rompe o embargo e publica imagens com o conserto antes da liberação oficial, segundo a Fundação. |
| 21 de outubro | Liberação das versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Governos e empresas retiram sistemas do ar. A Cloudflare já havia ativado proteções cerca de nove horas antes, segundo o Tecnoblog. |
A própria Fundação reconheceu, no comunicado, que "o atraso foi uma falha estrutural", causada pelo processo de decisão da equipe e pela falta de recursos. Segundo o texto, o processo está sendo mudado para permitir decisões por maioria e incentivar acordos. Também afirmou que, desde 1º de julho, a equipe publicou 15 CVEs e analisou mais de 100 relatos que se mostraram inválidos, duplicados ou irreproduzíveis.
Linha do tempo das falhas do PHP, de 2024 até a divulgação e as correções em 21 de outubro de 2026
A inteligência artificial entrou nos dois lados
Segundo o Canaltech, pesquisadores da Wiz e da Calif usaram modelos de inteligência artificial do Google e da OpenAI para analisar o funcionamento interno do PHP e demonstrar os ataques. A Wiz afirma que as ferramentas ajudaram a fazer em cerca de uma semana uma investigação que poderia exigir meses de especialistas. A mesma reportagem registra a preocupação dos especialistas: as ferramentas que ajudam defensores a achar falhas também podem acelerar o trabalho de criminosos contra servidores que ainda não foram atualizados. O especialista da Sophos Don Smith, ouvido pelo Olhar Digital, alerta que essas vulnerabilidades tendem a virar alvo prioritário nas horas e nos dias seguintes à divulgação das correções, incluindo ataques assistidos por IA.
Quem está mais exposto
O alerta oficial é detalhado sobre quais ambientes são mais vulneráveis, e a diferença importa para o seu caso:
- Apache com mod_php: é o cenário mais exposto. A execução remota foi demonstrada com configurações padrão, e a primeira falha pode ser acionada antes de qualquer código do site rodar.
- PHP-FPM (comum com nginx): a Fundação diz que a execução remota também foi confirmada, por caminhos dentro do código da aplicação. É um cenário que depende mais de condições específicas do site.
- Outros modelos de execução (como o FrankenPHP e o LSAPI) também são citados como possivelmente suscetíveis em certas condições.
Na prática, você não precisa saber qual desses a sua hospedagem usa. Precisa saber que o servidor roda uma versão afetada e que ela deve ser atualizada. Pelo TecMundo, as falhas atingem o PHP desde a versão 5.4, e sites que parecem simples também podem ser explorados: "até mesmo um aplicativo simples em uma versão vulnerável do PHP pode ser explorado", segundo a Wiz.
Uma regra de ouro vinda dos especialistas em WordPress, citados pelo TecMundo: a Patchstack e a Wordfence lembraram que atualizar o site pelo painel do WordPress não resolve o problema. A responsabilidade é de quem administra o servidor ou da hospedagem.
O que fazer agora
A ordem abaixo foi pensada para quem não é técnico. Cada passo é possível de fazer hoje, e o primeiro pode ser só uma mensagem.
- Descubra onde seus sites rodam. O primeiro desafio, como disse o especialista da Sophos, é saber onde o PHP está sendo executado. Liste os sites e sistemas da empresa: site institucional, loja, blog, intranet, sistema de agendamento, área de clientes. Muitos rodam em PHP sem que ninguém lembre.
- Pergunte à hospedagem e peça a atualização. Muitas hospedagens já estão aplicando a correção (a GoDaddy, por exemplo, corrigiu o PHP da hospedagem gerenciada de WordPress, segundo o TecMundo). Use o modelo de mensagem mais abaixo.
- Confira a versão do PHP no painel. Na maioria das hospedagens há uma opção "versão do PHP". As versões corrigidas são 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Se o seu site está em 7.x, 8.0 ou 8.1, o caminho é migrar para uma versão corrigida e testar o site.
- Faça backup antes de mudar. Guarde uma cópia do site e do banco de dados fora do servidor. Se algo quebrar na atualização ou se houver invasão, é a sua saída.
- Atualize também o WordPress, o tema e os plugins. Não resolve esta falha, mas é outra camada de proteção que você deve manter.
- Ative a proteção na frente do site. A Cloudflare ativou proteções automáticas contra as falhas no seu firewall de aplicações web, inclusive para o plano gratuito de quem tem o recurso ativo. Segundo a empresa, é uma medida provisória, e o diretor de tecnologia Dane Knecht foi claro: "isso é apenas um paliativo; atualizem assim que a equipe do PHP lançar a correção".
- Troque senhas e chaves se houver qualquer dúvida. Isso inclui banco de dados, painel da hospedagem, FTP e chaves de APIs. Use senhas longas e únicas (veja como criar uma senha segura e gere as suas na ferramenta de gerador de senhas) e ative a verificação em duas etapas onde existir.
- Se a atualização não for possível agora, a orientação oficial é isolar o sistema. O CTIR Gov e o CERT-EU recomendam avaliar a suspensão temporária do acesso externo às aplicações vulneráveis até a correção.
Infográfico com 5 passos para proteger o site contra as falhas do PHP
E para quem administra o servidor?
O alerta oficial traz medidas que reduzem a exposição enquanto a atualização não acontece, mas deixa claro que atualizar é a única mitigação completa. Entre elas: manter o tamanho máximo de envio conservador e conferi-lo também na frente do servidor, reduzir o nível de aninhamento de campos, limitar o número de variáveis, partes de formulário, cabeçalhos e uploads, e bloquear antes do PHP os formulários de envio de arquivos quando o site não os usa. A orientação inclui ainda um alerta técnico: não usar limites do sistema (RLIMIT_AS ou RLIMIT_DATA) como proteção, porque eles podem acionar justamente o caminho vulnerável. Se você não tem certeza do que isso significa, passe o trecho para o seu técnico ou para a hospedagem.
Modelo de mensagem para a sua hospedagem
Se você não sabe por onde começar, copie e envie ao suporte da hospedagem ou ao freelancer que cuida do seu site:
Olá! Soube das vulnerabilidades críticas no PHP (CVE-2026-109618 e CVE-2026-109619). Podem me informar: 1) qual versão do PHP o meu site usa hoje; 2) se o servidor já recebeu a correção (PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12); 3) se há proteção ativa na frente do servidor (firewall); e 4) se existe algum sinal de acesso suspeito ao meu site. Se ainda não atualizaram, preciso saber o prazo. Obrigado!
Guarde a resposta. Se algum dia houver incidente, o registro de que você perguntou e quando foi respondido ajuda em qualquer discussão de responsabilidade.
Como saber se o site já foi invadido
Um dos pontos mais importantes das recomendações dos especialistas é este: atualizar não basta, é preciso verificar se alguém já entrou. As falhas podem ser exploradas logo depois da divulgação, e quem estava de olho pode ter agido antes de você atualizar. Sinais comuns, quando algo está errado:
- Usuários administradores novos no WordPress que você não criou.
- Arquivos desconhecidos nas pastas do site, principalmente arquivos .php na pasta de uploads ou com nomes aleatórios.
- Páginas ou links que você não publicou, especialmente sobre apostas, remédios ou produtos. Pesquise no Google por site:seudominio.com.br e olhe os títulos que aparecem.
- Lentidão repentina ou aviso da hospedagem sobre consumo anormal de processamento.
- E-mails de spam saindo do seu domínio ou avisos de que o domínio entrou em lista de bloqueio.
- Avisos de segurança do navegador ou do Google ao abrir o site.
- Alterações nas configurações do banco de dados ou do e-mail que ninguém fez.
Peça à hospedagem uma varredura de arquivos suspeitos e consulte os registros de acesso. Plugins de segurança, como os da Wordfence e da Patchstack (citadas pelo TecMundo), ajudam a detectar alterações em sites WordPress. Se você encontrar algo, tire o site do ar, preserve os registros, troque todas as credenciais e peça ajuda profissional. Se houver dados pessoais envolvidos, trate como incidente de segurança sob a LGPD.
O que o caso ensina sobre risco digital
Passado o susto, vale transformar o episódio em rotina. O PHP é só o exemplo da vez: toda empresa depende de componentes que ela não escreveu e que ficam "escondidos" sob o site, o sistema de gestão ou o e-mail. Cinco hábitos reduzem muito o risco:
- Tenha um inventário simples. Uma planilha com os sistemas da empresa, onde cada um está hospedado, quem é o responsável e qual versão usa. Sem isso, você descobre o problema só quando a notícia sai.
- Defina um responsável. Segurança "de todo mundo" costuma ser de ninguém. Alguém precisa receber os alertas e agir.
- Atualize com rotina, e não só em crise. Versões sem suporte são o terreno mais fácil para um ataque. Migrar com calma sai bem mais barato do que migrar na emergência.
- Mantenha backups fora do servidor e teste a restauração. Backup que nunca foi restaurado é uma esperança, não um plano.
- Escolha a hospedagem pela segurança, não só pelo preço. Pergunte como é a política de atualização, se há firewall e como são avisados os clientes em incidentes. Foi a hospedagem quem aplicou a correção rápido em muitos casos.
Para quem toma decisões com base em dados, vale ainda uma observação: um site invadido contamina as métricas. Tráfego falso, páginas de spam e redirecionamentos distorcem os relatórios de análise e as campanhas pagas. Quando a confiança nos números cai, as decisões que dependem deles também ficam comprometidas.
O que ainda não sabemos
- Se houve exploração real. As reportagens brasileiras dizem que não há confirmação de invasões nos órgãos que suspenderam sistemas; as suspensões foram preventivas. A CISA informou não ter observado exploração até a publicação da Reuters. A PHP Foundation disse ter monitorado as provas de conceito que apareceram depois do vazamento e não ter identificado ataques funcionais no momento da liberação. Isso pode mudar.
- Quando os sistemas públicos voltam. Anatel e TRF1 não informaram previsão de retorno.
- Quantos sites seguem vulneráveis. A atualização depende de cada administrador e de cada hospedagem, e ninguém tem esse número hoje.
- Como a vulnerabilidade se comportará em versões antigas. As correções oficiais saíram apenas para quatro versões. Para ramificações mais antigas, a recomendação prática é migrar.
- Os detalhes técnicos completos. A Fundação não divulgou toda a técnica de exploração, e o alerta oficial indica que algumas condições são específicas de cada ambiente.
A recomendação é acompanhar os comunicados da PHP Foundation e do php.net, os avisos do CTIR Gov e as mensagens da sua hospedagem nos próximos dias. Este texto é informativo e não substitui a avaliação de um profissional de segurança: se o seu negócio depende do site, vale chamar um especialista para uma verificação completa.
Fontes consultadas
Mais artigos no blog