- Ponto da situação: 21 de outubro de 2026, 16h de Lisboa. Duas falhas críticas no PHP (CVE-2026-109618 e CVE-2026-109619, gravidade 9,2 em 10) permitem aos atacantes executar código malicioso em servidores web sem iniciar sessão.
- Desde 21 de outubro de 2026, às 15h de Lisboa, há atualizações: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e versões anteriores já não recebem correção do próprio projeto PHP.
- Um WordPress atualizado ou plugins atualizados não o protegem. O que conta é a versão do PHP no servidor.
- Sites em que o servidor apenas entrega ficheiros HTML, CSS e imagens já prontos não oferecem a esta falha qualquer superfície de ataque.
O que aconteceu? A PHP2Shell em resumo
A 20 de outubro de 2026, surgiu no fórum Hacker News uma publicação que anunciava duas falhas críticas no PHP. A publicação desapareceu rapidamente, mas as capturas de ecrã já circulavam. A empresa de segurança watchTowr confirmou que as falhas são reais e conseguiu reproduzir uma delas. Na verdade, os pormenores só deviam ser publicados mais tarde, juntamente com as atualizações.
A equipa do PHP reagiu na mesma noite e antecipou as atualizações de segurança para quarta-feira, 21 de outubro de 2026, às 15h de Lisboa. As duas falhas têm os identificadores CVE-2026-109618 e CVE-2026-109619, cada uma com uma gravidade de 9,2 numa escala até 10. Os investigadores de segurança chamam-lhes «PHP2Shell», em alusão à famosa falha Log4Shell de 2021.
A autoridade alemã de segurança informática, o BSI, emitiu um alerta de nível 3 (laranja) e conta que os atacantes explorem as falhas em larga escala poucas horas depois da publicação das atualizações. O vice-presidente do BSI, Thomas Caspers, foi claro: é preciso agir de imediato. A equipa europeia de resposta a emergências informáticas CERT-EU e o centro britânico NCSC também recomendam desligar da internet os sistemas que não possam ser atualizados de imediato. Segundo a agência noticiosa alemã dpa, a cidade de Mainz desligou, por precaução, o seu portal mainz.de e outros serviços online.
Explicado de forma simples: o que tem o PHP a ver com o seu site?
Quem não lida com tecnologia todos os dias pergunta, com razão: o que é afinal o PHP, e porque é que isto me afeta? Uma imagem do dia a dia ajuda.
Imagine o seu site como um restaurante. Os seus visitantes estão sentados na sala e só veem o que chega ao prato: textos, imagens, o seu formulário de contacto. Na maioria dos sites, porém, cada página só é preparada no momento em que alguém a abre. Isso acontece na cozinha, e em muitíssimos sites o cozinheiro dessa cozinha chama-se PHP. Quem usa WordPress, Shopware ou um sistema semelhante tem este cozinheiro em casa, muitas vezes sem o saber.
A PHP2Shell é uma falha na formação deste cozinheiro. Com um pedido preparado de propósito, um estranho consegue levá-lo a entregar o controlo da cozinha, sem chave e sem que ninguém na sala dê por nada. Quem controla a cozinha pode servir-se de tudo o que lá está guardado, ou servir aos clientes algo diferente do previsto.
Na prática, isto significa: nem a sua empresa nem os seus conteúdos fizeram algo de errado. O problema está na tecnologia sobre a qual o seu site funciona. Por isso, uma nova palavra-passe não ajuda. Só uma atualização dessa tecnologia resolve, e na maioria dos casos é o seu fornecedor de alojamento ou a sua agência que trata disso.
É precisamente por isso que construo sites, por princípio, como páginas estáticas em HTML e CSS. Para ficar na mesma imagem: cada página é preparada antecipadamente e fica pronta como um bufete já servido. Por trás das páginas não há sistema PHP, nem CMS, nem base de dados, e portanto também não há cozinheiro que alguém possa enganar. Isto não é apenas mais seguro, é também atual e muito mais rápido, porque nada tem de ser preparado no momento em que a página é aberta. Veja como o faço em web design e manutenção.
Porque é que esta falha é tão grave
Falhas de segurança em sites surgem constantemente. A maioria está num único plugin ou tema e só afeta os sites que usam precisamente essa extensão. A PHP2Shell é diferente: os erros estão no núcleo do próprio PHP, ou seja, na tecnologia sobre a qual o site funciona.
Segundo o aviso de segurança oficial do projeto PHP, são afetadas todas as instalações de PHP que processam pedidos da web, seja através de PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP ou LiteSpeed. A variante mais perigosa é o mod_php: aqui ficou demonstrado que um único pedido, sem qualquer início de sessão, pode desencadear o ataque antes mesmo de o código do site ser executado.
Execução remota de código, em inglês remote code execution ou RCE, significa que um atacante consegue executar à distância os seus próprios comandos num servidor alheio. Não precisa de palavra-passe nem de acesso à área de administração. No pior dos casos, assume o controlo total do site e de tudo o que está no servidor.
O que os atacantes podem fazer com um site comprometido é conhecido: roubar dados de clientes, distribuir software malicioso aos visitantes ou criar, sem que ninguém dê por isso, centenas de páginas de spam com links para ofertas alheias. Este último ponto afeta duramente a visibilidade. O Google assinala sites pirateados nos resultados de pesquisa e reporta problemas de segurança na Search Console. Até a confiança e os rankings voltarem, pode demorar.
A isto junta-se a rapidez. O BSI conta que os atacantes analisem as atualizações publicadas com ferramentas apoiadas por IA e construam ataques funcionais muito depressa. Entre a atualização e a vaga de ataques já não passam semanas, mas horas.
O seu site é afetado?
A resposta curta: se o seu site funciona com WordPress, Joomla, Drupal, TYPO3, Shopware, Magento ou outro sistema baseado em PHP, é afetado em princípio, enquanto o servidor não tiver uma versão atualizada do PHP. O mesmo vale para formulários de contacto, ferramentas de marcação ou áreas de cliente que funcionam com PHP.
Um ponto importante, muitas vezes mal compreendido: um WordPress atualizado, plugins atualizados ou um plugin de segurança não o protegem neste caso. A falha está um nível abaixo. O que conta é apenas a versão do PHP que corre no seu servidor.
Estas versões estão corrigidas: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quem ainda usa o PHP 8.1 ou anterior já não recebe atualizações oficiais do próprio projeto PHP. Para o PHP 7.4, 8.0 e 8.1 existem apenas correções de código para especialistas que compilam o PHP por conta própria, além de atualizações de algumas distribuições Linux e fornecedores comerciais. Para versões ainda mais antigas, resta apenas a mudança para uma versão atual.
Se o seu site está alojado num fornecedor, normalmente é o fornecedor que instala as atualizações. Mas não deve partir do princípio de que isso já aconteceu. Verifique.
O que deve fazer já
A boa notícia: para a maioria das empresas, a solução não é um grande projeto. Estes passos têm prioridade hoje:
1. Verificar e atualizar a versão do PHP. Veja na área de cliente do seu alojamento que versão do PHP o seu site usa e mude para uma versão atual. Se não encontrar essa informação, pergunte diretamente ao seu fornecedor se as atualizações de 21 de outubro já foram instaladas. O projeto PHP é claro: só a atualização resolve o problema por completo.
2. Não manter versões desatualizadas. Se o seu site ainda funciona com PHP 7 ou anterior, chegou a altura de mudar. Tenha em conta que também o PHP 8.2 só recebe atualizações de segurança até 31 de dezembro de 2026.
3. Fazer uma cópia de segurança. Uma cópia atual dos ficheiros e da base de dados, guardada fora do servidor, é o seu seguro de vida em caso de problema.
4. Estar atento a sinais estranhos. Ficheiros desconhecidos, novas contas de utilizador, páginas noutras línguas que surgem de repente no Google ou avisos em «Problemas de segurança» na Search Console são sinais de alarme. Nesse caso, chame especialistas de imediato.
5. Se necessário, desligar temporariamente. Se a atualização não puder ser instalada rapidamente, o BSI e a CERT-EU recomendam desligar da internet os sistemas afetados até a proteção estar garantida. Uma camada de proteção adicional, como uma firewall de aplicações web, por exemplo as regras que a Cloudflare disponibilizou para este caso, pode ajudar, mas não substitui a atualização.
O verdadeiro problema: toda a tecnologia precisa de manutenção
As atualizações já estão disponíveis, e muitos fornecedores de alojamento estão a instalá-las neste momento. Mas a verdadeira pergunta mantém-se: de quanta tecnologia precisa realmente o seu site?
Um site clássico com sistema de gestão de conteúdos monta cada página só no momento em que alguém a abre. Para isso, trabalham em segundo plano o PHP, uma base de dados, o próprio sistema, um tema e, normalmente, toda uma série de plugins. Cada uma destas camadas é software, e qualquer software pode ter falhas. Desta vez não foi um plugin, mas a base. Da próxima vez será novamente uma extensão, um formulário ou o próprio sistema.
Para muitas empresas, isto significa que atualizações, alertas de segurança e intervenções de urgência fazem parte do dia a dia, embora os conteúdos do próprio site mudem apenas algumas vezes por mês. Na minha experiência, é precisamente aqui que muitos sites de empresas estão desequilibrados: muita tecnologia em movimento para um site que, no essencial, apresenta informação e deve gerar contactos.
Um site com CMS é como uma loja com entrada principal, porta de serviço, janela da cave e porta das traseiras. Cada porta é útil, mas cada uma tem de ser fechada e verificada regularmente. Um site estático é antes uma montra bem iluminada: todos veem tudo o que devem ver, mas não há porta por onde alguém possa entrar.
Sites estáticos: onde nada é executado, nada pode ser atacado
Num site estático, cada página é construída uma vez com cuidado e depois colocada no servidor como ficheiro pronto: HTML para os conteúdos, CSS para o design, mais imagens e tipos de letra. Quando alguém visita a página, o servidor limita-se a entregar estes ficheiros. Não corre PHP, não há base de dados nem área de início de sessão que alguém possa atacar.
Para uma falha como a PHP2Shell, isto significa: se nenhum pedido é passado ao PHP, não há nada que um atacante possa desencadear. O mesmo vale para as falhas típicas em plugins, temas e bases de dados. Num site puramente estático, simplesmente não existem. Se um site estático precisar mesmo de uma função no servidor, por exemplo para um formulário de contacto, recorro a um único script leve em vez de um sistema inteiro. Nesse caso, a versão do PHP no alojamento também tem de estar atualizada, claro, mas a superfície de ataque e o esforço de manutenção são muitas vezes menores.
O ganho em segurança é apenas parte da conta. As páginas estáticas são também visivelmente mais rápidas, porque o servidor já não precisa de calcular nada. Isso contribui diretamente para as Core Web Vitals, os valores com que o Google avalia a velocidade de carregamento e a usabilidade. Quão rápido um site estático pode ser, vê-se no meu próprio site:
ctseo.de alcança 100 % no Google
A velocidade não é um luxo. O Google considera o tempo de carregamento e os Core Web Vitals como fator de ranking, e sites rápidos retêm visitantes e geram mais contactos. O que faço pelos meus clientes pode ver nesta página, medido oficialmente com o Google PageSpeed Insights. Até os agentes de IA leem e utilizam esta página sem problemas, uma vantagem direta para a sua visibilidade em sistemas de IA.
Melhores pontuações no Google PageSpeed Insights. Os valores podem variar ligeiramente entre medições, verifique por si próprio.
Além disso, as páginas estáticas podem ser construídas de forma especialmente limpa para motores de busca e sistemas de IA. Uma estrutura clara, dados estruturados e tempos de resposta rápidos facilitam ao Google, ao ChatGPT e afins a leitura e a compreensão dos seus conteúdos. É exatamente assim que construo todos os sites para os meus clientes: como site estático em HTML e CSS, sem sistema PHP por trás. Para sites de empresas, este é hoje o caminho atual: tempos de carregamento mais curtos, muito menos superfície de ataque, quase nenhuma manutenção e pensado desde o início para a pesquisa e a IA.
Para quem compensa a mudança e para quem não
Um site estático não é uma solução milagrosa, e não o recomendo de forma generalizada. Encaixa muito bem quando o seu site serve sobretudo para informar e gerar contactos. É o caso da maioria dos sites de empresas: escritórios de advogados, clínicas, empresas de serviços técnicos, prestadores de serviços e consultores.
É menos adequado quando o seu site é, no essencial, uma aplicação: uma grande loja online com carrinho e conta de cliente, uma área de membros ou um portal onde muitas pessoas publicam conteúdos todos os dias. Aí é preciso tecnologia no servidor, e a manutenção consistente é o caminho certo.
Na mudança, é importante manter a visibilidade que já tem. Endereços, conteúdos e redirecionamentos têm de ser bem planeados, caso contrário perde rankings construídos ao longo de anos. Descrevo em pormenor o que importa no artigo sobre o relançamento de website. Um efeito secundário agradável: quem reconstrói o site pode também dispensar plugins de estatística e banners de cookies. Mostro como no artigo sobre cookieless tracking.
Conclusão: atualizar hoje, fazer a pergunta de fundo amanhã
A PHP2Shell é uma das falhas mais graves dos últimos anos, porque afeta a base de milhões de sites. Se o seu site funciona com PHP, hoje só uma coisa tem prioridade: verificar a versão do PHP, mandar instalar a atualização e acompanhar o site nos próximos dias.
Depois, vale a pena olhar com honestidade para a pergunta de fundo: o seu site precisa mesmo de tanta tecnologia? Para muitas empresas, um site estático e leve é a solução mais segura, mais rápida e com menos manutenção. Se quiser saber em que tecnologia funciona hoje o seu site e se uma mudança compensa no seu caso, analiso isso consigo com todo o gosto, sem custos.
Perguntas frequentes
A forma mais simples é a área de cliente do seu alojamento, onde a versão do PHP pode normalmente ser definida por site. No WordPress, a secção «Saúde do site», em «Ferramentas», também mostra a versão em uso. Em caso de dúvida, pergunte diretamente ao seu fornecedor de alojamento ou à sua agência.
No alojamento web clássico, normalmente é o fornecedor que instala as atualizações do PHP. Muitas vezes, porém, é o próprio cliente que escolhe a versão do PHP que o site usa. Se ainda estiver selecionada uma versão antiga, o seu site continua vulnerável, mesmo que o fornecedor já ofereça versões mais recentes há muito tempo.
Não. Segundo o projeto PHP, o ataque pode ser desencadeado antes mesmo de o código do site ser executado. Um plugin que faz parte desse código chega tarde demais. Só uma versão atualizada do PHP o protege.
O valor vem do Common Vulnerability Scoring System, ou CVSS, uma norma internacional para avaliar falhas de segurança. A escala vai até 10. Valores a partir de 9 são considerados críticos, ou seja, falhas que devem ser corrigidas de imediato.
Sinais típicos são ficheiros ou contas de utilizador desconhecidos, páginas estranhas que surgem no Google com o seu domínio, redirecionamentos súbitos e avisos no navegador ou na Google Search Console. Em caso de suspeita, guarde os registos e chame especialistas, em vez de apagar ficheiros por conta própria.
Pode acontecer. O Google pode assinalar sites pirateados nos resultados de pesquisa, e as páginas de spam introduzidas diluem a imagem do seu site. Depois da limpeza, pode pedir uma revisão na Search Console. Ainda assim, costuma demorar até a confiança e os rankings estarem totalmente recuperados.
Segurança absoluta não existe. Também num site estático, os acessos ao alojamento, ao domínio e às contas de e-mail têm de estar bem protegidos. Mas os ataques típicos a sistemas, plugins e bases de dados não têm efeito num site puramente estático, porque essa tecnologia não existe lá.
Depende da solução. Na maioria dos sites de empresas, os conteúdos só mudam de vez em quando. Nos sites estáticos que construo, trato das alterações, se quiser, no âmbito da manutenção. Assim, poupa-se à gestão de um sistema próprio. O que melhor se adapta ao seu dia a dia, esclarecemos juntos antes.
Sim, se forem baseadas em PHP, por exemplo com WooCommerce, Shopware ou Magento. As lojas processam ainda dados de clientes e pagamentos, por isso aqui a pressa é especialmente importante. Uma loja grande normalmente não pode ser feita como site estático, pelo que atualizações rápidas e manutenção consistente são o caminho certo.
O projeto PHP mantém cada versão apenas durante um período limitado. Depois disso, deixa de haver atualizações de segurança, mesmo para falhas graves como a PHP2Shell. Isto aplica-se atualmente ao PHP 8.1 e a todas as versões anteriores. O PHP 8.2 recebe atualizações de segurança até 31 de dezembro de 2026.