Já atualizou o PHP? Há uma nova falha que o patch de emergência não corrige

Dois dias depois de ter lançado atualizações de emergência para as falhas críticas conhecidas como PHP2Shell, a equipa de segurança do PHP publicou um novo alerta. Desta vez, o problema é a vulnerabilidade CVE-2026-115560, que pode permitir a execução remota de código num servidor web. Os servidores já atualizados continuam expostos, porque as versões de 21 de outubro (8.5.12, 8.4.27, 8.3.36 e 8.2.35) não corrigem esta falha. A boa notícia é que o risco está limitado a configurações pouco comuns e que a mitigação se resume a uma única linha de configuração.

O que diz o aviso do PHP

O alerta saiu a 23 de outubro com o título “Informational advisory: Session upload progress”. Segundo o registo público da alteração no site oficial do PHP, foi adicionado por Jakub Zelenka, da equipa do projeto. No texto, o PHP recomenda definir session.upload_progress.enabled=0 até à próxima versão regular de correções, para proteção total contra um vetor de RCE considerado improvável.

O projeto não vai lançar uma correção de emergência para este caso. A justificação é que a configuração é improvável na prática, pelo que o problema será tratado no ciclo regular de versões, com um aviso completo sobre a CVE-2026-115560 a publicar com a próxima versão. Por agora, ainda faltam dados essenciais: o PHP não indicou as versões afetadas, a versão que trará a correção nem a pontuação CVSS.

Que configurações estão em risco

O aviso deixa claro que o problema só pode ocorrer numa combinação invulgar de configuração e de código da aplicação. Uma aplicação só fica exposta se cumprir as três condições ao mesmo tempo:

Se uma destas condições falhar, a falha não pode ser explorada por esta via. O PHP acrescenta que as aplicações que nunca mudam o serialize handler durante a execução podem manter a funcionalidade ativa.

A funcionalidade em causa, o session upload progress, serve para acompanhar o progresso dos carregamentos de ficheiros. É usada, por exemplo, para mostrar barras de progresso em formulários. Vem ligada por omissão. Muitos sítios web não a usam, mas pode ser ativada em qualquer pedido do tipo multipart.

O contexto: uma semana agitada para o PHP

Este alerta surge logo a seguir ao episódio PHP2Shell, nome dado a duas vulnerabilidades críticas no motor do PHP. O aviso 2026-018 do CERT-EU descreve a CVE-2026-109618 como uma falha que, com uma pontuação CVSS de 9.2, permite a execução remota de código através de corrupção de memória durante o tratamento de falta de memória (OOM). A segunda, a CVE-2026-109619, tem a mesma pontuação e resulta de estado interno que sobrevive entre pedidos tratados pelo mesmo processo.

A CISA, agência norte-americana de cibersegurança, também emitiu um alerta. Afirmou que estas falhas permitem execução remota de código sem autenticação e afetam todas as instalações PHP que servem pedidos web.

Há uma ligação direta entre os dois casos. A mitigação agora recomendada já constava das orientações de 21 de outubro para a CVE-2026-109619. Nessa altura, o próprio PHP avisou que desativar o session upload progress bloqueava apenas parte dos caminhos de ataque e não dispensava a atualização. Sobre a exploração do PHP2Shell, as fontes não coincidem. A CISA disse que não tinha observado exploração à data da publicação, mas o CERT-EU notou que já circulavam provas de conceito, o que aumenta a probabilidade de exploração ativa. Quanto à CVE-2026-115560, o aviso do PHP não refere qualquer exploração.

Passos concretos de mitigação

Para administradores de sistemas, programadores e prestadores de alojamento, recomenda-se o seguinte:

• Confirmar primeiro o PHP2Shell. Verifique com php -v e com a página de diagnóstico do servidor web que está a correr a 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou uma versão posterior). O CERT-EU lembra que os ramos PHP 8.1 e anteriores já não recebem atualizações do projeto.
• Desativar o upload progress ao nível do servidor. Defina session.upload_progress.enabled=0 no php.ini, no pool do PHP-FPM ou na configuração do servidor web. Nas orientações para a CVE-2026-109619, o PHP desaconselhou ini_set() e .user.ini, porque a opção tem de estar em vigor antes de o pedido ser processado.
• Reiniciar todos os processos PHP (PHP-FPM, Apache com mod_php e outros) e confirmar que o valor efetivo é Off, por exemplo com php -i | grep upload_progress ou com phpinfo() no contexto web.
• Auditar o código. Procure chamadas como ini_set('session.serialize_handler' no código das aplicações e das dependências. Verifique também se a configuração define php_binary ou php_serialize.
• Testar as funcionalidades de carregamento depois da alteração, sobretudo nas aplicações que mostram barras de progresso.
• Acompanhar a próxima versão regular do PHP e as atualizações da distribuição ou do painel de alojamento, e aplicá-la logo que esteja disponível.

Por enquanto, não há indicadores de comprometimento (IOCs) públicos específicos para a CVE-2026-115560. Os detalhes técnicos só deverão ser conhecidos com o aviso completo.

Porque é que isto importa em Portugal

O PHP está na base de uma grande parte da web, incluindo sistemas de gestão de conteúdos como WordPress, Drupal e Joomla e muitas lojas online. Em Portugal, muitas PME têm sítios web em alojamento partilhado e não sabem que versão de PHP usam nem como está configurada. Para estas empresas, o mais prático é perguntar diretamente ao fornecedor de alojamento se as atualizações de 21 de outubro foram aplicadas e se o session upload progress foi desativado.

Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2), a gestão de vulnerabilidades faz parte das medidas de gestão de risco obrigatórias. Um incidente significativo tem de ser notificado ao CNCS, através do CERT.PT, dentro dos prazos legais. Nesse contexto, convém registar que a mitigação foi aplicada e quando.

Se uma vulnerabilidade de execução remota for explorada, o atacante pode chegar a bases de dados de clientes e a credenciais. Nesse caso, um incidente técnico passa a ser também uma violação de dados pessoais ao abrigo do RGPD, com a obrigação de notificar a CNPD no prazo de 72 horas quando houver risco para os titulares. Neste caso, a mitigação é simples e barata, e já tinha sido recomendada a propósito do PHP2Shell.

Perguntas frequentes

Se já atualizei o PHP por causa do PHP2Shell, estou protegido contra a CVE-2026-115560?

Não totalmente. As versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 não corrigem esta nova falha. Para ficar protegido, é preciso também desativar session.upload_progress.enabled ou confirmar que a aplicação não muda o serialize handler durante a execução.

Como sei se a minha aplicação é vulnerável?

Só é vulnerável se tiver session.serialize_handler definido como php_binary ou php_serialize na configuração, se o mudar para php com ini_set() antes de session_start() e se tiver o upload progress ativo. Uma pesquisa no código por serialize_handler ajuda a esclarecer.

Desativar o session upload progress estraga o meu sítio web?

Na maioria dos casos, não. A funcionalidade só serve para acompanhar o progresso de carregamentos de ficheiros. As aplicações que usam essas barras de progresso podem perder essa informação, por isso convém testar os formulários de carregamento depois da alteração.

Quando sai a correção definitiva?

O PHP diz que a correção vem na próxima versão regular de correções, acompanhada de um aviso completo, mas ainda não anunciou a data nem as versões afetadas.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelo projeto PHP, pelo CERT-EU e pela CISA.