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:
- Comunicação: Investigadores encontram uma vulnerabilidade e comunicam-na em confidencialidade ao projeto.
- Análise e correção: O projeto analisa a comunicação, desenvolve uma correção e atribui números CVE.
- 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.
- 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.
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.
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.
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.
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.
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.
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.