Em resumo: Depois do PHP2Shell são prováveis mais avisos sobre o PHP, porque dois dias após o patch surgiu um terceiro aviso, um aviso completo ainda está por publicar e as distribuições vão entregando os seus pacotes de forma escalonada. Quem montar agora um procedimento fixo de observação, avaliação, atualização e reinício reage à próxima nova vulnerabilidade PHP em horas e não em dias.
O patch não foi o fim da história
A 21 de outubro de 2026, o projeto PHP fechou as duas vulnerabilidades críticas CVE-2026-109618 e CVE-2026-109619 com as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Muitos responsáveis puseram depois um visto. Dois dias mais tarde, a 23 de outubro, seguiu-se, porém, outro aviso do php.net sobre a CVE-2026-115560.
Este terceiro aviso diz respeito apenas a uma configuração de sessão invulgar. Mostra, no entanto, um padrão conhecido dos grandes casos de segurança: quando um componente fica de repente sob os holofotes, muitos especialistas olham ao mesmo tempo com mais atenção. Se daí surgirão mais vulnerabilidades, ninguém o sabe hoje. É provável, porém, que o fluxo de notícias não pare.
Para si, como operador, isto significa: preveja avisos posteriores, em vez de ser surpreendido por cada um. O desenrolar dos acontecimentos até agora é resumido na nossa cronologia do PHP2Shell.
Porque são prováveis mais avisos
A avaliação seguinte baseia-se em factos publicamente conhecidos. Não é uma previsão de vulnerabilidades concretas.
- Um aviso ainda está pendente. O php.net trata a CVE-2026-115560 no ciclo regular de lançamentos e anunciou que o aviso completo será publicado com o próximo lançamento. Até lá,
session.upload_progress.enabled=0vale como medida de atenuação. - Os pormenores foram públicos cedo. Segundo várias notícias, houve pormenores que se tornaram conhecidos antes do fim do embargo. Segundo notícias, a watchTowr reproduziu a CVE-2026-109618, segundo as suas próprias declarações. Tais trabalhos levam muitas vezes a perguntas posteriores sobre partes de código vizinhas.
- As distribuições entregam de forma escalonada. O Ubuntu abasteceu os lançamentos atuais a 21 de outubro com a USN-8948-1 e entregou depois, com a USN-8948-2, correções para 14.04 a 20.04 através do Ubuntu Pro. A Red Hat escreveu no seu boletim que algumas atualizações estavam disponíveis e outras em curso.
- A versão de desenvolvimento está afetada. Segundo o php.net, também o PHP 8.6.0 RC4 contém as correções. Quem testa pré-versões tem de atualizar também esses ambientes.
- As versões antigas continuam em aberto. Para o PHP 8.1 e anteriores existem apenas backports mínimos do código-fonte. Cada fornecedor que entrega tais versões comunica o seu estado de forma autónoma e em datas próprias.
Como chega até si uma nova vulnerabilidade PHP
Os avisos chegam por vias diferentes e com fiabilidade diferente. A ordem é quase sempre a mesma: primeiro o projeto PHP, depois distribuições e fornecedores de alojamento, a seguir autoridades e media.
| Fonte | O que aí encontra | Fiabilidade |
|---|---|---|
| php.net | Ramos afetados, versões corrigidas, medidas provisórias | Fonte primária |
| Ubuntu, Debian, Red Hat | Estado dos pacotes por lançamento, data de entrega | Fonte primária para o seu sistema |
| Fornecedores de alojamento e de painéis | Estado das suas próprias compilações PHP | Só vinculativo se por escrito |
| BSI, CERT-Bund | Avaliação da situação, nível de alerta, recomendações | Enquadramento oficial |
| Imprensa especializada e empresas de segurança | Observações de ataques, números, contexto | Útil, identificar como notícia |
Importante é a diferença entre “há um patch” e “o meu sistema tem o patch”. A primeira afirmação consta do php.net. A segunda tem de a comprovar você, para cada servidor.
Subscreva os avisos do php.net e da sua distribuição por RSS ou lista de correio e encaminhe-os para uma caixa de correio ou canal comum que seja lido por mais de uma pessoa. Férias e doença são as razões mais frequentes para atualizações tardias.
O que deve preparar antes do próximo aviso
A experiência do PHP2Shell mostra onde se perde tempo: na procura de servidores, no esclarecimento de responsabilidades e no reinício esquecido. Tudo isso pode ser resolvido antes.
- Inventário: Uma lista de todos os servidores e sites com ramo do PHP, modo de operação (PHP-FPM, mod_php, LiteSpeed) e origem dos pacotes. Sem esta lista, cada aviso começa por procurar. Como o conseguir é descrito no artigo Inventário de todos os sites e servidores.
- Responsabilidade: Para cada sistema está definido quem aplica o patch, quem reinicia e quem autoriza. Com fornecedores de alojamento e agências, isto pertence ao contrato.
- Grelha de avaliação: Três perguntas bastam para a primeira classificação. O nosso ramo está afetado? Usamos a funcionalidade ou o modo de operação afetado? Existe um patch ou apenas medidas provisórias?
- Via de teste: Um ambiente de staging em que uma atualização do PHP possa ser verificada em pouco tempo.
- Comprovativo: Um formato fixo em que ficam registados o estado dos pacotes, a correspondência no registo de alterações e a hora do reinício.
Como um procedimento destes funciona como rotina em vez de intervenção de bombeiros é descrito em Gestão de patches como processo. Antecedentes sobre a forma como o projeto PHP lida com vulnerabilidades são fornecidos pela página Como o projeto PHP trata as vulnerabilidades de segurança.
A própria configuração como sistema de alerta precoce
Parte dos avisos posteriores diz respeito apenas a determinadas definições. A CVE-2026-115560 é um exemplo: o php.net indica como pressuposto que uma aplicação altere o serializador de sessões em tempo de execução enquanto o upload progress está ativo. As aplicações que nunca o fazem não estão, segundo o php.net, afetadas.
Quem conhece a sua configuração efetiva consegue classificar mais depressa tais avisos. Registe por isso, para cada ramo, que valores estão definidos no servidor e que aplicações os podem sobrepor. Já ajuda uma comparação simples das definições ativas:
# Valores efetivos da linha de comandos (a configuração web pode divergir)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Valores definidos nos pools FPM (caminho diferente consoante a distribuição)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
A linha de comandos não mostra necessariamente o que vale no contexto web. A clareza vem da configuração do pool ou do VirtualHost e, por breve tempo e de forma protegida, de uma página phpinfo.
Outra vantagem: quem sabe que valores provisórios ainda estão definidos desde a semana do PHP2Shell pode verificá-los de forma consciente depois do próximo lançamento regular. Algumas definições, como o upload progress desativado, podem continuar a fazer sentido de forma duradoura. Outras, como limites de upload muito apertados, devem ser ajustadas de novo às necessidades reais, depois de consultar os departamentos especializados.
Como ajuda concretamente a PHP SOS?
- Acompanhamos os avisos do php.net, das distribuições e do BSI e avaliamos as novas indicações para os seus sistemas concretos.
- Elaboramos consigo o inventário de todas as instalações PHP e definimos responsabilidades por servidor.
- No âmbito de um contrato de manutenção de segurança, aplicamos atualizações, reiniciamos todos os processos e documentamos o estado.
- Perante avisos sem patch, aplicamos medidas provisórias que não podem ser sobrepostas e verificamo-las depois.
Perguntas frequentes
Já há uma nova vulnerabilidade PHP depois do PHP2Shell?
A 23 de outubro de 2026, o php.net publicou um aviso sobre a CVE-2026-115560. Segundo este, a execução de código só é possível com uma configuração de sessão invulgar. Um aviso completo deverá seguir-se com o próximo lançamento regular.
Tenho de agir de imediato a cada novo aviso?
Nem todos os avisos exigem a mesma urgência. Decisivos são a gravidade, o impacto na sua configuração e se existe um patch disponível. Um procedimento definido ajuda a avaliá-lo em minutos e não em dias.
Onde sei primeiro de novas vulnerabilidades PHP?
As fontes primárias são os avisos do php.net e as indicações de segurança da sua distribuição, por exemplo os Ubuntu Security Notices, o Debian Security Tracker ou a Red Hat. O BSI (Gabinete Federal Alemão para a Segurança da Informação) informa através de alertas. As notícias dos media são úteis, mas muitas vezes mais tardias e menos exatas.
Porque é que as distribuições por vezes avisam dias depois do php.net?
As distribuições têm de incorporar a correção nos seus próprios pacotes, compilá-los e testá-los. Para versões mais antigas, isto pode demorar mais ou só ser feito através de ofertas adicionais. Por isso vale a pena acompanhar as duas fontes em separado.