Vulnerabilidade de PHP de 21 de outubro: o que aconteceu e qual é a situação atual

Na quarta-feira, dia 21 de outubro, tornaram-se públicas duas falhas de segurança graves no PHP, a linguagem de programação na qual assenta a grande maioria dos sites, incluindo o WordPress. É possível que tenha reparado nisso, pois durante parte do dia os sites alojados por nós estiveram offline. Neste artigo, resumimos o que aconteceu, como atuámos e qual é a situação atual.

O que se passou?

As falhas (CVE-2026-109618 e CVE-2026-109619) permitiam que pessoas não autorizadas executassem código num servidor web. Este é praticamente o pior tipo de falha que existe: um atacante não precisa de palavra-passe e afeta praticamente toda a internet.

Como atuámos

1. Medida temporáriaquarta-feira, 21 de outubro, 10:00

   Nessa altura, sabia-se apenas que existiam duas falhas graves em todas as versões do PHP, com uma pontuação CVE de 9,2. Ainda não havia detalhes conhecidos nem se tinha conhecimento de ataques bem-sucedidos, embora, por exemplo, a Cloudflare registasse cada vez mais tentativas. Como os detalhes da falha ainda não eram conhecidos, ninguém sabia exatamente como funcionava nem o que podia ser feito para reduzir o risco. Foram, no entanto, surgindo cada vez mais mitigações e possíveis ações para limitar o risco. Implementámo-las sempre de imediato, como a desativação de determinadas funções do PHP e a atualização da firewall várias vezes.
   A partir das 10:00 também passámos a executar continuamente verificações de malware muito rigorosas, de modo a detetarmos imediatamente caso fosse colocado algum script nos nossos servidores ou nas contas dos nossos clientes. Isso não aconteceu.

2. Sites offlinequarta-feira, 21 de outubro, 15:15

   Embora não tivéssemos detetado tentativas de utilização indevida nos nossos servidores, decidimos optar pela solução mais segura: colocar tudo offline. A principal razão para isso foi o facto de termos dúvidas quanto à eficácia das mitigações (soluções temporárias) que circulavam na internet, uma vez que ninguém conseguia confirmar que estas ofereciam proteção suficiente.
   Numa situação com tanta incerteza e com consequências potencialmente enormes, algumas horas de indisponibilidade são justificáveis; correr o risco não.

3. Solução oficialquarta-feira, 21 de outubro, 16:00

   Os criadores do PHP lançaram a atualização oficial com a correção para as versões 8.3, 8.4 e 8.5. Depois disso, foi preciso aguardar pelos pacotes atualizados da CloudLinux, o fornecedor das versões de PHP utilizadas nos nossos servidores.
   Ao publicar a atualização, foram também divulgados os detalhes das vulnerabilidades, o que confirmou a nossa suspeita: as mitigações conhecidas e as regras adicionais da firewall reduziam de facto o risco de um ataque, mas não eram suficientes para proteger o servidor.

4. Solução temporáriaquarta-feira, 21 de outubro, 19:00

   Infelizmente, demorou bastante mais tempo do que esperávamos até que a CloudLinux tivesse as atualizações prontas. Através do contacto com outros fornecedores, percebemos que não fomos os únicos a ser apanhados de surpresa. Como verificámos que já tinham falhado várias vezes os seus próprios prazos definidos, trabalhámos numa solução temporária.
   Instalámos nós próprios a versão 8.3.36 do PHP em todos os nossos servidores e colocámos temporariamente todos os nossos clientes nessa versão. 90% dos sites voltaram a ficar online entre as 19:00 e as 20:30. Os únicos sites que não voltaram a ficar online eram sites desatualizados, incompatíveis com uma versão moderna do PHP.

5. Atualizaçãoquinta-feira, 22 de outubro, 00:30

   As atualizações ficaram disponíveis e começámos de imediato a instalá-las e a verificá-las, servidor a servidor.

6. Resolvidoquinta-feira, 22 de outubro, 02:30

   Todos os servidores tinham sido atualizados e todos os sites voltaram a ficar online, com a versão de PHP que utilizavam anteriormente.

Compreendemos perfeitamente que é incómodo quando o seu site fica inacessível durante uma tarde e uma noite. No entanto, este incómodo não se compara às possíveis consequências. Nunca antes tínhamos tido de decidir colocar tudo offline por precaução, mas se a mesma situação voltar a ocorrer, faremos exatamente o mesmo.

Qual é a situação atual?

• Todas as versões de PHP que disponibilizamos, da 5.2 até à 8.5, incluem as correções de segurança para ambas as falhas.
• Os poucos sites que utilizavam uma versão de PHP ainda mais antiga, para a qual não existe correção, foram colocados numa versão corrigida.
• Verificámos os servidores durante e após a ocorrência da falha, à procura de sinais de utilização indevida, como processos PHP bloqueados, processos suspeitos, ficheiros carregados e pedidos compatíveis com o ataque conhecido. Não encontrámos quaisquer indícios de que a falha tenha sido explorada nos nossos servidores e, antes de colocarmos tudo offline, também não foram encontradas tentativas nesse sentido.

O meu site está separado dos de outros clientes?

Sim. Cada pacote de alojamento funciona, na nossa infraestrutura, num ambiente próprio e isolado. O PHP é executado sob o utilizador do seu pacote, sem direitos de administração no servidor, e não tem acesso aos ficheiros ou bases de dados de outros clientes. Também a utilização de processador e memória é limitada por pacote. Optamos deliberadamente por não divulgar mais detalhes sobre a nossa segurança: quanto menos um atacante souber, melhor.