Em resumo: Entre os factos comprovados sobre o PHP2Shell contam-se os dois números CVE, a classificação CVSS v4.0 9,2, as versões do PHP corrigidas e as medidas provisórias do php.net. Também está comprovado o nível de alerta laranja do BSI. Não estão comprovados uma classificação CVSS 10, ataques bem-sucedidos em larga escala confirmados nem uma lista de indicadores de deteção. Quem separar estes três níveis toma melhores decisões.
Porque é necessária uma verificação de factos sobre o PHP2Shell
Poucas vulnerabilidades de segurança dos últimos anos geraram tantas manchetes em tão pouco tempo. Já antes de a equipa do PHP publicar as atualizações, a 21 de outubro de 2026, circulavam, segundo notícias, publicações em fóruns, capturas de ecrã e alegados pormenores. Seguiram-se avisos de autoridades, blogues de fabricantes, contagens de servidores expostos e uma enxurrada de dicas.
Para os operadores, isto significa que nem todos os números e conselhos têm a mesma qualidade. Uma parte vem de fontes primárias, outra de reportagens sérias, outra de especulação. Este artigo separa o que pode usar como seguro nas suas decisões. Os fundamentos da vulnerabilidade em si são explicados na página O que é o PHP2Shell?.
Que peso tem cada fonte
Uma hierarquia simples ajuda a ler qualquer notícia:
- php.net: O projeto PHP é a fonte primária para os números CVE, as classificações, os modos de operação afetados, as versões corrigidas e as medidas provisórias. Como o projeto trata os avisos de segurança em geral é descrito no nosso artigo sobre o processo de segurança do PHP.
- Autoridades: O BSI (Gabinete Federal Alemão para a Segurança da Informação) fornece a avaliação da situação na Alemanha e recomendações de ação; o CERT-EU e o CERT-Bund (a equipa de resposta a incidentes do governo alemão) complementam.
- Distribuições e fornecedores: O Debian, o Ubuntu, a Red Hat, os fornecedores de alojamento e os serviços de plataforma só se pronunciam de forma vinculativa sobre os seus próprios pacotes e serviços.
- Empresas de segurança: A Cloudflare, a Unit 42, a CybelAngel e outras reportam com base nas suas próprias medições. São valiosas, mas cada uma com o seu método.
- Media e redes sociais: Boas para a rapidez, fracas nos pormenores. As afirmações daí precisam de confirmação numa fonte mais acima.
Comprovado, noticiado, não comprovado: o resumo
A tabela seguinte classifica as afirmações mais frequentes. “Comprovado” significa: fonte primária ou autoridade. “Noticiado” significa: vindo de media ou de declarações de fabricantes, não confirmado de forma independente.
| Afirmação | Classificação | Base |
|---|---|---|
| Duas vulnerabilidades, CVE-2026-109618 e CVE-2026-109619 | comprovado | php.net |
| Classificação CVSS v4.0 9,2, crítica | comprovado | php.net |
| Classificação CVSS 10 | insustentável | segundo notícias, de uma publicação num fórum antes do anúncio |
| Corrigido nas versões 8.5.12, 8.4.27, 8.3.36, 8.2.35 | comprovado | php.net |
| mod_php com o risco mais elevado, exploit demonstrado antes do código da aplicação | comprovado | php.net |
| Quase todas as versões até ao PHP 5.4 afetadas | noticiado | imprensa especializada |
| Primeira tentativa de ataque a 17/10 | noticiado | notícias dos media com base na Amazon |
| Mais de 22,6 milhões de instâncias expostas | noticiado | Unit 42, segundo a TechTarget |
| Ataques bem-sucedidos em larga escala | não comprovado | segundo o BSI, inicialmente desconhecidos |
| Indicators of Compromise confirmados | não existem | sem publicação |
| As medidas provisórias protegem totalmente | falso | o php.net classifica-as expressamente como incompletas |
Chama a atenção a rapidez com que os números ganham vida própria. A classificação 10,0 da publicação no fórum continuava a aparecer em artigos dias depois, embora a equipa do PHP já tivesse publicado há muito o 9,2.
Onde está realmente a incerteza
A maior questão em aberto não é técnica, mas temporal: o que aconteceu entre a primeira tentativa de ataque noticiada e a aplicação do patch em cada servidor? Não há uma resposta geral. A Cloudflare e a Patchstack reportaram tentativas de ataque; a watchTowr reproduziu a CVE-2026-109618, segundo as suas próprias declarações. A Huntress, por sua vez, não viu ataques em ambientes de parceiros à data do seu comunicado.
Estas afirmações não se contradizem. Descrevem recortes diferentes: um grande serviço de proxy, uma empresa de segurança de plugins, uma equipa de investigação e uma empresa com a sua própria base de clientes. Não resulta daí um quadro geral.
O mesmo vale para a questão das versões afetadas. Para as versões 8.2 a 8.5, a situação é clara. Para os ramos mais antigos existem backports mínimos do código-fonte para as versões 7.4, 8.0 e 8.1, mas não há lançamentos oficiais. O que ficar para trás está, segundo a imprensa especializada, quase sempre afetado. Para o seu planeamento, isto faz pouca diferença: um servidor com PHP 8.1 ou mais antigo sem backport confirmado deve ser tratado como vulnerável.
A falta de provas de ataques não é prova de segurança. Como não existem indicadores de deteção confirmados, um ataque a um servidor concreto só pode ser avaliado através de uma verificação do comportamento, não através de uma lista.
O que deve concluir para os seus servidores
Dos factos comprovados resultam poucos passos claros. Dos não comprovados resulta sobretudo prudência.
- Verificar o nível de patch: versão corrigida ou backport confirmado pelo fornecedor. O número de versão apresentado, por si só, não basta.
- Reiniciar todos os processos PHP: Os novos ficheiros só têm efeito quando já não há processos antigos em execução.
- Guardar os registos desde 20/10: A imprensa especializada aconselha-o, para que uma verificação posterior continue possível.
- Procurar vestígios: novos ficheiros PHP em pastas de uploads, tarefas cron desconhecidas, processos do servidor web com shell. A página Será que já fui comprometido? acompanha-o na verificação.
- Confirmar os conselhos: aplicar dicas de fóruns e redes sociais apenas se puderem ser reconduzidas ao php.net ou a uma autoridade. O artigo Falsas dicas perigosas sobre o PHP2Shell reúne as recomendações que neste momento prejudicam.
Para a comunicação interna ajuda a mesma separação. Quem apresentar à direção “comprovado”, “noticiado” e “em aberto” em separado evita tanto o alarmismo como o falso alívio.
Como ajuda concretamente a PHP SOS?
- Situação para os seus sistemas: Aplicamos os factos comprovados aos seus servidores e separamos, na documentação, o que foi medido, o que foi noticiado e o que está em aberto.
- Patch e comprovativo: Verificamos o estado dos pacotes e o reinício de cada serviço PHP e registamo-lo por escrito.
- Verificação de vestígios: Guardamos os registos desde 20 de outubro e procuramos comportamentos invulgares, até o incidente estar concluído e documentado.
- Avaliação contínua: Avaliamos para si as novas notícias antes de delas resultarem medidas.
O procedimento é descrito na ajuda imediata PHP2Shell.
Conclusão
O PHP2Shell é sério, e isso está bem comprovado. É precisamente por isso que vale a pena um olhar sóbrio: as fontes primárias bastam para todas as decisões importantes. O que circula para além delas é muitas vezes mais rápido do que rigoroso. Aplicar o patch, reiniciar, guardar os registos e procurar vestígios continua a ser a resposta, independentemente do número que esteja a circular.
Perguntas frequentes
O PHP2Shell tem classificação CVSS 10?
Não. Segundo notícias, o número 10 vem de uma publicação num fórum que circulou antes do anúncio oficial. A equipa do PHP classifica ambas as vulnerabilidades com CVSS v4.0 9,2. Ainda assim, continua a ser a categoria crítica.
Existe uma lista de indicadores para reconhecer ataques PHP2Shell?
Até agora, não. Não há Indicators of Compromise confirmados e publicados. Quem quer verificar se um servidor foi afetado tem de estar atento a comportamentos invulgares, como processos do servidor web que iniciam uma shell ou novos ficheiros PHP em pastas de uploads.
Qual é a fonte mais fiável sobre o PHP2Shell?
Para os factos técnicos, os avisos no php.net; para a avaliação da situação na Alemanha, o BSI (Gabinete Federal Alemão para a Segurança da Informação). As notícias dos media e os blogues de fabricantes completam o quadro, mas devem ser tratados como notícias e lidos à luz da fonte primária.
Estão mesmo afetadas todas as versões do PHP desde o PHP 5?
A situação está comprovada para os ramos 8.2 a 8.5, para os quais existem atualizações. Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4; segundo notícias, o CERT-EU considerou possíveis versões a partir do PHP 5. Para versões mais antigas não há atualizações oficiais, pelo que deve tratá-las, em qualquer caso, como vulneráveis.