Vulnerabilidades críticas no PHP (CVE-2026-109618 e CVE-2026-109619): o que fizemos

A 21 de outubro, a equipa do PHP publicou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, que corrigem duas vulnerabilidades críticas conhecidas como PHP2Shell: CVE-2026-109618 e CVE-2026-109619, ambas com uma pontuação de 9,2 em 10. Permitem que alguém execute código num servidor com um simples pedido ao site, sem utilizador nem palavra-passe, e afetam praticamente qualquer instalação de PHP, seja qual for a aplicação: WordPress, PrestaShop, Laravel ou um site feito à mão.

Não tem de fazer nada: todas as versões do PHP dos nossos servidores, da 5.2 à 8.5, estão corrigidas desde a madrugada de 22 de outubro.

A 23 de outubro, o PHP avisou de uma terceira via, CVE-2026-115560, que ainda não tem correção. Nos nossos servidores estava fechada desde dia 21: explicamos mais abaixo.

Se o seu site usa PHP 8.2, 8.3, 8.4 ou 8.5, verá o mesmo número que o PHP publicou, por exemplo 8.5.12. Com uma versão anterior verá o de sempre, por exemplo 7.4.33, e é normal: o PHP não publica versões novas desses ramos, e a CloudLinux, que mantém as versões do PHP que usamos, incorpora-lhes a correção sem mudar o número. A tabela mais abaixo indica a versão corrigida de cada ramo. Explicamos o que fizemos.

Antes de a correção sair

O PHP avisou na véspera que publicaria a correção no dia 21 às 16:00, hora de Espanha, e os detalhes foram divulgados antes do tempo. Não esperámos pelo patch: acompanhamos os avisos de segurança por todas as vias, não só as oficiais, e assim que começaram a circular os primeiros relatos não oficiais:

• Desativámos em todos os servidores a funcionalidade do PHP por onde entrava a parte confirmada do ataque: o acompanhamento do progresso dos envios de ficheiros na sessão. Fizemo-lo em todas as versões do PHP que oferecemos, da 5.2 à 8.5, e verificámos conta a conta que tinha ficado desativada.
• Acrescentámos regras próprias à firewall web de todos os servidores, que rejeitam as tentativas conhecidas antes de chegarem ao PHP. Somam-se às que a CloudLinux implementou no Imunify360.

Nenhuma destas medidas muda nada no seu site. A única coisa que deixa de funcionar é a barra de progresso das aplicações que a calculavam com essa funcionalidade do PHP, algo muito pouco habitual: a maioria calcula-a no navegador.

São medidas que reduzem o risco, mas não substituem a atualização. É o que diz a própria equipa do PHP, e é por isso que a instalámos assim que ficou disponível.

A atualização

Os nossos servidores usam as versões do PHP mantidas pela CloudLinux. Fomos instalando as versões corrigidas à medida que eram publicadas, e desde a madrugada de 22 de outubro a correção está aplicada em todos os servidores, em todas as versões que oferecemos: da 5.2 à 8.5.

Da 8.2 à 8.5, o número já é o que o PHP publicou com a correção: 8.5.12, por exemplo. Nas anteriores, a CloudLinux incorpora a correção sem mudar o número de versão, por isso o PHP continua a mostrar o de sempre: 7.4.33, por exemplo.

Na 8.2, na 8.3, na 8.4 e na 8.5, a CloudLinux publicou primeiro a correção sem mudar o número, e foi o que instalámos nos dias 21 e 22: se nesses dias viu 8.5.11 no seu site, já estava corrigido. Depois publicou as mesmas correções com o número do PHP, e também as instalámos: mudam o número, não a proteção, que já existia desde o dia 22. Nas palavras da CloudLinux: «If you have already installed the fixed packages from our earlier updates (for example alt-php85 8.5.11-5), your servers are already protected against CVE-2026-109618 and CVE-2026-109619. This update only brings the version numbers in line with PHP.net». Ou seja: quem já tinha os pacotes anteriores, como o 8.5.11-5, estava protegido, e os novos apenas igualam o número ao do PHP. Explica-o no seu aviso sobre estas vulnerabilidades.

A atualização não precisou de nenhuma ação da sua parte nem interrompeu o serviço.

O aviso de 23 de outubro: CVE-2026-115560

A 23 de outubro, a equipa do PHP avisou de outra via para executar código no servidor, CVE-2026-115560. As versões de dia 21 não a corrigem: a correção chegará com a próxima versão do PHP. É uma via diferente, e o que essas versões corrigem, CVE-2026-109618 e CVE-2026-109619, continua corrigido.

Só pode ser aproveitada numa combinação pouco habitual: a aplicação muda, no seu próprio código, o formato em que o PHP guarda a sessão e, além disso, está ativado o acompanhamento do progresso dos envios de ficheiros na sessão. Enquanto a correção não chega, o PHP recomenda desativar essa funcionalidade, e esclarece que quem já o fez com o seu aviso de dia 21 não tem de fazer mais nada.

É o nosso caso: é a mesma funcionalidade que desativámos a 21 de outubro em todos os servidores e em todas as versões do PHP, da 5.2 à 8.5, e continua desativada. As regras da firewall web que acrescentámos nesse dia rejeitam, além disso, os pedidos que tentam usá-la antes de chegarem ao PHP. Não tem de fazer nada. Quando o PHP e a CloudLinux publicarem a correção, instalá-la-emos tal como esta.

E se o meu site usa uma versão antiga do PHP?

O projeto PHP só corrige as versões que mantém: da 8.2 em diante. Para a 8.1, a 7.x e a 5.x não publica versões novas. Na maioria dos alojamentos, um site com PHP 7.4 fica hoje sem proteção.

Na Hostsuar não. A CloudLinux mantém patches de segurança para todas as versões que oferecemos, da 5.2 à 8.5, e também corrigiu estas duas vulnerabilidades nas antigas. A correção já está instalada nelas, tal como nas restantes: o seu site está protegido sem mudar de versão.

Manter atualizada a versão que usa é trabalho nosso, por isso não tem de mudar de versão do PHP por causa destas vulnerabilidades. Se um dia quiser passar para uma mais recente, por desempenho ou porque um plugin novo o exige, pode ver que versões há em Versões de PHP disponíveis em todos os serviços de alojamento e mudar a do seu site em Mudar a versão de PHP de um site com verificação e reversão: verificamos que o site continua a responder com a versão nova e, se não, volta à anterior. Se o seu site precisar de alterações para funcionar numa versão atual, escreva-nos e vemos isso.

Se tem PHP noutro sítio

Se gere por conta própria algum servidor com PHP fora da Hostsuar, atualize-o para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou instale o pacote corrigido da sua distribuição, e reinicie o PHP. Para a CVE-2026-115560, defina também session.upload_progress.enabled = 0 no php.ini ou na configuração do PHP-FPM antes de o reiniciar: com ini_set() a partir da aplicação não serve. Se tiver dúvidas sobre como o fazer, escreva-nos.