Se você atualizou o site da sua empresa para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 depois da falha PHP2Shell, fez a coisa certa, mas isso não cobre tudo. Em 23 de outubro de 2026, o projeto PHP publicou um novo alerta sobre uma terceira falha, a CVE-2026-115560, que a atualização de 21 de outubro não corrige. Ela exige uma configuração incomum e o PHP a considera um vetor improvável, mas a correção temporária é simples: peça hoje à sua equipe ou à sua hospedagem que defina session.upload_progress.enabled como 0 e reinicie o PHP, e depois confirme por escrito que a atualização de 21 de outubro foi realmente aplicada.

O que o PHP anunciou em 23 de outubro?

Dois dias depois da versão de emergência, o projeto publicou um breve alerta informativo sobre o acompanhamento do «progresso de upload» nas sessões, o recurso que mostra ao usuário quanto de um arquivo grande já foi enviado. O alerta diz que esse recurso pode abrir um caminho de execução remota de código em um caso específico, e que a correção virá na próxima versão regular, e não como atualização de emergência, junto com um aviso completo sobre a falha.

Para um empresário, dois pontos importam. Primeiro, é uma falha separada, então rodar uma das quatro versões acima não basta por si só. Segundo, a mesma medida temporária já constava no aviso sobre a CVE-2026-109619 de 21 de outubro. Se sua equipe a aplicou naquela data, nada de novo é necessário: mantenha-a.

Seu site está exposto?

Segundo o alerta do PHP, o problema só aparece quando três condições se juntam:

  • A configuração do PHP define session.serialize_handler como php_binary ou php_serialize.
  • O código da aplicação o troca para php em tempo de execução com ini_set() antes de iniciar a sessão.
  • O acompanhamento do progresso de upload continua ativo, como vem por padrão.

A maioria dos sites não faz isso. O problema é que o dono raramente sabe o que cada linha faz num sistema criado há anos ou num plugin antigo. Por isso, a opção mais segura: se o seu site não mostra barra de progresso no envio de arquivos, desligar o recurso não quebra nada e fecha a porta. Se ele depende disso, pergunte aos seus desenvolvedores se o código muda essa configuração em tempo de execução.

Três dias depois: confira se a atualização de 21 de outubro foi mesmo aplicada

As falhas originais, CVE-2026-109618 e CVE-2026-109619, continuam sendo o maior risco. A Autoridade Nacional de Cibersegurança da Arábia Saudita (NCA) emitiu o alerta nº 2026-7949 sobre elas, e a agência americana CISA recomendou inventariar todos os sistemas PHP, corrigir primeiro os expostos à internet e tirar um sistema do ar se ele não puder ser corrigido de imediato. A CISA disse que não tinha observado exploração bem-sucedida no momento da publicação, o que não significa que o tempo esteja a seu favor.

Três pontos que muita gente esquece:

  • Reiniciar, não recarregar. O boletim da Red Hat afirma que mudanças de configuração exigem reiniciar os processos do PHP e que apenas recarregar não basta.
  • O número da versão pode ser diferente em servidores Linux. O anúncio do PHP diz que as distribuições Linux receberam os patches com antecedência, então você pode ver um número diferente de 8.5.12, por exemplo, mesmo com a correção aplicada. Peça à sua hospedagem uma confirmação por escrito, não só um número. A Red Hat observa que RHEL 8, 9 e 10 são todos afetados.
  • O modo como o PHP roda muda o risco. O projeto PHP considera o risco maior com mod_php no Apache, enquanto a Red Hat diz que a exploração é mais difícil na prática com o PHP-FPM padrão. Mais difícil não é impossível, então a atualização é necessária nos dois casos.

5 perguntas para enviar hoje à sua hospedagem ou equipe

  1. Qual versão do PHP roda em cada um dos nossos sites e sistemas, e ela inclui as correções de 21 de outubro de 2026?
  2. Os processos do PHP foram reiniciados após a atualização, e não apenas recarregados?
  3. Definimos session.upload_progress.enabled como 0? Se não, realmente precisamos do recurso?
  4. O código do nosso site muda session.serialize_handler em tempo de execução?
  5. Temos algum site em 8.1 ou anterior? Essas versões estão fora de suporte, e a tabela de versões suportadas mostra que o suporte de segurança do 8.2 termina em 31 de dezembro de 2026.

A visão da Origami

Três alertas em três dias é normal depois de uma falha grave: quando os pesquisadores vasculham uma parte da linguagem, encontram o que está ao lado. Mas isso também diz algo sobre as empresas. Quem corrigiu no dia 21 e encerrou o assunto vai perder o alerta do dia 23. Aqui, segurança é acompanhamento contínuo, não uma tarefa que se conclui uma vez.

O que vemos nas empresas sauditas é que a pergunta difícil não é «qual é a falha?», e sim «quem do nosso lado lê um alerta do PHP numa sexta de manhã e sabe qual servidor é o nosso?». Na Origami, criamos sites e sistemas e monitoramos suas atualizações desde o primeiro dia. Se quiser verificar seu site, ou aplicar essas configurações sem interromper o serviço, fale conosco.

Conclusão

A atualização de 21 de outubro é essencial e continua sendo a mais importante; o novo alerta não muda isso. Acrescente hoje um passo barato: desligue o acompanhamento do progresso de upload se não precisar dele, reinicie o PHP e obtenha uma confirmação por escrito da sua hospedagem. Depois, fique de olho na próxima versão regular do PHP, que trará a correção definitiva da CVE-2026-115560.

Fontes