# Depois do PHP2Shell: porque são prováveis mais avisos

> Depois do PHP2Shell, são prováveis mais avisos sobre o PHP. Como o reconhecer, que fontes acompanhar e como a sua equipa reage de forma preparada.

Fonte: https://phpsos.de/pt/blog/weitere-php-meldungen/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/ratgeber/php2shell-chronologie/).

## 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.

1. **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=0` vale como medida de atenuação.
2. **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.
3. **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.
4. **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.
5. **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.

> **Dica:**
> 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](https://phpsos.de/pt/blog/inventar-websites-server/).
- **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](https://phpsos.de/pt/blog/patch-management-prozess/). 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](https://phpsos.de/pt/php/php-sicherheitsprozess/).

## 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:

```bash
# 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](https://phpsos.de/pt/leistungen/security-wartungsvertrag/), 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.

## Fontes

- [php.net: avisos e indicações de segurança](https://www.php.net/)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [BSI](https://www.bsi.bund.de/)