# Porque é que a vulnerabilidade PHP foi conhecida antes do patch

> Porque a vulnerabilidade PHP foi conhecida antes do patch: como funcionam os embargos, o que aconteceu a 20 de outubro e o que os operadores aprendem.

Fonte: https://phpsos.de/pt/blog/php-luecke-vorzeitig-bekannt/  
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:** A vulnerabilidade PHP foi conhecida antes do tempo porque, segundo várias notícias, pormenores se tornaram públicos antes de terminar o embargo acordado, entre outras vias através de uma publicação num fórum a 20 de outubro de 2026. O php.net anunciou então a versão de segurança para 21 de outubro, às 14:00 UTC. Para os operadores, ficou pouco tempo de preparação. A lição: um processo de patches tem de funcionar mesmo sem aviso prévio.

## O ponto de partida: um anúncio com poucas horas de antecedência

Normalmente, os administradores só tomam conhecimento de uma vulnerabilidade crítica no momento em que a atualização também está disponível. No PHP2Shell foi diferente. A 20 de outubro de 2026, o php.net publicou um pré-aviso: uma versão de segurança crítica no dia seguinte, às 14:00 UTC, ou seja, às 16h hora alemã, para duas vulnerabilidades com CVSS v4.0 9,2.

Uma frase da comunicação foi invulgar. A equipa do PHP reservou-se o direito de publicar mais cedo se os pormenores de uma das vulnerabilidades se tornassem públicos ou surgissem indícios de exploração ativa. Segundo várias notícias, entre outras da SOC Prime e da BleepingComputer, foi exatamente esse o contexto: já havia informação em circulação antes da data prevista.

## Como decorre normalmente uma divulgação coordenada

Por trás das grandes atualizações de segurança há quase sempre um processo a que os especialistas chamam “Coordinated Disclosure”, ou seja, divulgação coordenada. De forma simplificada, decorre assim:

1. **Comunicação:** Investigadores encontram uma vulnerabilidade e comunicam-na em confidencialidade ao projeto.
2. **Análise e correção:** O projeto analisa a comunicação, desenvolve uma correção e atribui números CVE.
3. **Informação prévia:** Parceiros selecionados, por exemplo distribuições Linux, recebem a correção sob embargo, para que os seus pacotes estejam prontos na data marcada.
4. **Publicação:** Numa data fixa são lançados em simultâneo o patch, o aviso de segurança e os pacotes.

O embargo é um acordo para reter os pormenores até essa data. Destina-se a impedir que os atacantes ganhem vantagem enquanto ainda não existe atualização. Como o projeto PHP trata os avisos de segurança em geral é explicado no artigo sobre o [processo de segurança do PHP](https://phpsos.de/pt/php/php-sicherheitsprozess/).

## Como a vulnerabilidade PHP foi conhecida antes do tempo: 20 de outubro

Segundo notícias concordantes dos media, os números CVE apareceram a 20 de outubro numa publicação pública num fórum, juntamente com a alegação de que ambas as vulnerabilidades estavam classificadas com a pontuação máxima de 10,0. Segundo notícias, a publicação foi mais tarde apagada. A equipa do PHP confirmou as vulnerabilidades, mas indicou a classificação 9,2 e a data de publicação de 21 de outubro.

Nas horas seguintes circularam, segundo notícias, capturas de ecrã e um vídeo que pretendiam mostrar um ataque. A empresa de segurança watchTowr declarou ter reproduzido a CVE-2026-109618. A Cloudflare tinha, segundo as suas próprias declarações, regras de proteção próprias ativas desde o início da manhã de 21 de outubro.

Independentemente da fuga de informação, os media noticiam, com base na Amazon, uma primeira tentativa de ataque observada a 17 de outubro. Não está publicamente comprovado se esta tem relação com a fuga posterior. A sequência completa das datas é apresentada na [cronologia do PHP2Shell](https://phpsos.de/pt/ratgeber/php2shell-chronologie/).

## O que muda para os operadores quando algo é conhecido antes do tempo

Para as empresas, a fuga teve três consequências práticas:

- **Menos antecedência:** Entre o pré-aviso e o patch passou cerca de um dia. Quem só reagiu depois da publicação não teve tempo para combinar janelas de manutenção.
- **Situação informativa pouco clara:** Nas primeiras horas, havia boatos ao lado de informação oficial. A classificação errada de 10,0 manteve-se durante dias.
- **Ponto de partida mais cedo para os atacantes:** Quem conhece os pormenores cedo pode procurar cedo. Segundo a experiência, as análises automáticas à procura de servidores vulneráveis começam depressa, como descreve o artigo sobre [varrimentos em massa à procura de PHP sem patch](https://phpsos.de/pt/blog/automatisierte-massenscans/).

Ao mesmo tempo, o pré-aviso mostrou que o processo funcionou apesar da fuga: as atualizações para todos os ramos suportados saíram na data anunciada e as distribuições entregaram, em parte, backports no mesmo dia.

### Porque é que um projeto não publica simplesmente de imediato

Poderia perguntar-se porque é que a equipa do PHP não publicou logo tudo depois da fuga. A resposta está na ponderação que qualquer projeto enfrenta nesta situação. Uma versão sem pacotes prontos das distribuições só ajuda quem compila o PHP a partir do código-fonte. A grande maioria dos servidores obtém o PHP através do Debian, do Ubuntu, da Red Hat, de fornecedores de alojamento ou de imagens de contentores. Uma data demasiado cedo teria tornado públicos os pormenores sem que a maioria dos operadores pudesse já aplicar o que quer que fosse.

O pré-aviso com data fixa e a reserva de publicar mais cedo, se necessário, foi uma solução intermédia. Os operadores puderam preparar-se e as distribuições concluir os seus pacotes. Para si, como operador, isto significa: um pré-aviso destes é um sinal para planear de imediato pessoal e janelas de manutenção, e não só no dia do patch.

> **Dica:**
> Subscreva diretamente os avisos de segurança do php.net e da sua distribuição, por exemplo por RSS ou lista de correio. Um pré-aviso só serve se alguém na empresa o ler.

## O que deve retirar para o seu processo de patches

Se uma vulnerabilidade se torna conhecida conforme o planeado ou antes do tempo não depende de si. A rapidez com que pode agir depois, sim. Estes pontos revelaram-se decisivos no PHP2Shell:

| Elemento | Pergunta a que deve ter respondido antes |
|---|---|
| Inventário | Que servidores e sites usam PHP, em que versão e modo de operação? |
| Responsabilidade | Quem aplica o patch: a TI interna, um prestador de serviços ou o fornecedor de alojamento? Quem decide sobre uma desativação? |
| Via de atualização | O PHP vem da distribuição, de um repositório de terceiros ou de uma imagem de contentor? |
| Reinício | Como se reiniciam de forma fiável todos os processos PHP? |
| Comprovativo | Como se comprova o nível de patch quando o número de versão se mantém igual? |
| Funcionamento de emergência | Existe uma página de emergência para o caso de um servidor ter de sair temporariamente da rede? |

Quem já respondeu a estas perguntas só precisa, no próximo pré-aviso, da data. Como é um processo destes a longo prazo é descrito no artigo sobre o [processo de gestão de patches](https://phpsos.de/pt/blog/patch-management-prozess/).

## Como ajuda concretamente a PHP SOS?

- **Levantamento rápido:** Registamos todos os sistemas PHP com versão, modo de operação e origem dos pacotes.
- **Patch na data marcada:** Aplicamos as atualizações, reiniciamos todos os processos PHP e comprovamos o estado de cada servidor.
- **Transição em caso de atraso:** Onde uma atualização não é possível de imediato, aplicamos as medidas provisórias do php.net e acertamos consigo uma desativação temporária.
- **Preparação para a próxima vez:** Definimos consigo responsabilidades, canais de comunicação e funcionamento de emergência.

Encontra pormenores sobre o procedimento no [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/).

## Conclusão

O facto de o PHP2Shell ter sido conhecido antes do tempo não foi uma falha dos operadores, mas foi um teste à sua preparação. Um embargo pode quebrar-se. Um processo que já clarifica inventário, responsabilidade, via de atualização e comprovativo aguenta-se mesmo assim.


## Perguntas frequentes

**O que é um embargo no caso de vulnerabilidades de segurança?**  
Um embargo é um acordo para só publicar os pormenores de uma vulnerabilidade numa data fixa, normalmente em conjunto com o patch. Até lá, só quem a descobriu, o fabricante e parceiros selecionados conhecem os pormenores, para que as atualizações possam ser preparadas.

**O patch do PHP foi publicado mais cedo por causa da fuga de informação?**  
O php.net anunciou a 20 de outubro a versão de segurança para 21 de outubro, às 14:00 UTC, e reservou-se o direito de publicar mais cedo se os pormenores se tornassem públicos ou surgissem ataques. Segundo várias notícias, o anúncio foi feito porque os pormenores já circulavam antes de terminar o embargo.

**Uma vulnerabilidade conhecida antes do tempo é mais perigosa?**  
Encurta o tempo de que os operadores dispõem para se preparar e dá aos atacantes um ponto de partida mais cedo. Segundo notícias dos media, uma primeira tentativa de ataque foi observada logo a 17 de outubro, ou seja, antes dos patches.

**O que pode uma empresa fazer contra surpresas destas?**  
Não pode impedir que as vulnerabilidades sejam conhecidas cedo. Pode, no entanto, estar preparada: com uma lista de todos os sistemas PHP, responsabilidades definidas, vias de atualização testadas e uma página de emergência para o caso de um servidor ter de sair temporariamente da rede.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)