Em 21 de outubro de 2026 o PHP publicou quatro versões de emergência: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Não foi uma atualização de rotina. Fecham duas vulnerabilidades batizadas php2shell, registadas como CVE-2026-109618 e CVE-2026-109619, que permitem executar código no servidor sem autenticação prévia. A agência federal americana de cibersegurança pediu no mesmo dia que o patch fosse aplicado sem espera (CISA, 2026).
A execução remota de código sem autenticação é, na lista das coisas que podem acontecer a um site, a combinação que ninguém quer ver. Sem credenciais roubadas. Sem sessões desviadas. Sem conhecimento interno da aplicação. Se o servidor expõe uma versão afetada, o atacante envia instruções e o servidor executa-as. Não há credenciais para roubar nem defesas para forçar à entrada.
Este artigo não repete o noticiário. Responde ao que o noticiário não responde: como saber se está exposto, o que fazer esta semana e quem ocupa cada parte do trabalho. Se dirige uma equipa técnica com sites em PHP, seus, de clientes ou herdados, é isso que tem à frente, com a diferença de que desta vez não foi o seu plano trimestral a fixar o calendário, mas alguém que publicou duas CVEs numa terça-feira de manhã.
php2shell é um par de vulnerabilidades do PHP, CVE-2026-109618 e CVE-2026-109619, que permitem executar código no servidor sem autenticação. Foram divulgadas em 20 e 21 de outubro de 2026 e o patch saiu no próprio dia 21: as versões seguras são 8.5.12, 8.4.27, 8.3.36 e 8.2.35 em cada ramo (Huntress, 2026). A CISA pediu aplicação imediata porque a exploração começou em horas, não em semanas. Em baixo: como auditar que superfícies correm PHP, em que ordem corrigir, o que verificar depois (credenciais, logs, webshells) e o que tem a NIS2 a ver com isto.
O que é php2shell e porque o patch saiu em 24 horas
A sequência foi rápida mesmo para os padrões deste tipo de falha. Em 20 de outubro o projeto PHP anunciou uma publicação fora de calendário para o dia seguinte; no dia 21, às 14:00 UTC, os detalhes técnicos e as versões corrigidas saíram quase ao mesmo tempo (Huntress, 2026). A margem para inventariar o que estava exposto antes de existir exploit público foi praticamente nula, e não porque o projeto PHP tenha feito algo mal, mas porque o inventário de superfícies de uma organização média, repartido por equipas de plataforma, desenvolvimento e um ou dois fornecedores externos, não se faz numa tarde nem à força de boas intenções.
Quase todas as versões do PHP estão afetadas, incluindo as que remontam à 5.4, e a Wiz estima a superfície exposta em cerca de 70% da web (Wiz, 2026). O patch existe para os ramos sob suporte ativo, de 8.2 a 8.5, e as versões que fecham as duas CVE são as quatro da tabela. Se algum ambiente corre uma versão entre a 8.2 e a 8.5 anterior à versão corrigida do seu ramo, está em zona de risco, e está mesmo que ninguém o tenha documentado, porque o mapa do que corre em produção e o mapa que a equipa julga que corre em produção divergem há anos em qualquer empresa que herdou sistemas, absorveu projetos ou integrou equipas alheias.
| Ramo do PHP | Versão corrigida (21 de outubro de 2026) |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
A diferença entre uma execução de código que exige credenciais e uma que não as exige é a diferença entre um incidente e uma campanha. A primeira é explorada por quem já entrou. A segunda por qualquer um. Chegam um script e uma lista de endereços. No mesmo dia, à escala. Por isso o alerta da CISA (2026) não fala de risco potencial, e por isso tentativas de exploração em massa contra sites sem corrigir eram registadas nas horas seguintes à publicação dos detalhes (Help Net Security, 2026).
A falha foi encontrada por IA: o que muda para o seu calendário
As vulnerabilidades foram localizadas a 19 de agosto de 2026 pela equipa de investigação da Wiz, com modelos de IA a fazer parte do trabalho de descoberta, segundo a sua própria análise técnica (Wiz, 2026). Estavam ali há anos. Uma semana antes do patch, a CNBC (2026) contava a outra metade do mesmo padrão: a Mythos, o modelo da Anthropic dedicado a localizar falhas de software, tinha exposto no Bank of America defeitos suficientes para o banco anunciar a contratação de 1 000 profissionais externos a apoiar a equipa interna de correção. Tradução para o seu calendário: a descoberta industrializou-se, a correção continua humana, e um aviso de vinte e quatro horas torna-se semanas de trabalho assim que as janelas de manutenção não dependem da sua equipa.
A Black Kite (2026) contou 7 551 organizações publicadas como vítimas de ransomware em 2026, mais 24,9% do que no ano anterior. Cada falha exposta alimenta essa máquina, e a máquina não distingue quem corrigiu a tempo de quem contava fazê-lo no fim do sprint.
Como saber se o seu site está exposto
O inventário é metade do trabalho. Cinco perguntas para o ordenar.
- Que versão do PHP serve cada ambiente. Não a que a documentação diz: a que o servidor responde. Ambientes públicos, staging esquecidos, contentores antigos e aquele CMS que ninguém toca desde 2023.
- Se alguma está entre 8.2 e 8.5 abaixo da versão corrigida do seu ramo. 8.2.35, 8.3.36, 8.4.27 e 8.5.12 são o corte (Huntress, 2026). Abaixo disso, exposto.
- O que é gerido pelo alojamento e o que é gerido pela sua equipa. Em alojamento partilhado ou gerido, o motor PHP é atualizado pelo fornecedor. A questão não é se o patch existe, mas quando o aplica e se avisa os clientes, porque o calendário do fornecedor e a sua política de avisos decidem aqui mais do que a documentação de infraestrutura interna.
- O que se passa com o WordPress e os restantes CMS. A vulnerabilidade está no motor PHP, não no CMS nem nos plugins: atualizar plugins não corrige o php2shell. O site fica coberto quando o servidor serve uma versão corrigida, nem um minuto antes, e vale a pena pedir por escrito ao fornecedor a versão servida hoje e a data prevista de atualização.
- O que corre em ramos sem suporte, como o PHP 7. Essas versões nunca vão receber este patch. O risco acumulado não tem data de validade e a saída razoável é planear a migração.
O que fazer esta semana
- Atualizar para as versões corrigidas em todas as superfícies inventariadas, começando pelas expostas à internet. A CISA (2026) não dá margem para dúvidas: pede imediatismo. Sem período de tolerância.
- Se alguma superfície não pode ser tocada já, reduzi-la ou isolá-la à espera do patch, e vigiar o que lhe chega.
- Uma vez corrigido, rodar credenciais, chaves de API e segredos que viviam no servidor, e rever os logs de acesso e de execução à procura de webshells: quando a execução foi possível sem autenticação, o patch fecha a porta mas não olha quem entrou antes. É o passo que a maioria das equipas salta, e o que separa um fecho limpo de um incidente latente que ressuscita em janeiro.
- Verificar com um teste externo. Um patch aplicado é uma afirmação; um teste que tenta explorar a superfície e não consegue é um facto, e convém que o execute outra pessoa que não quem aplicou o patch, porque auditar o próprio trabalho com as próprias mãos continua a ser a maneira mais confortável de não encontrar nada.
E se a sua organização está sujeita a regulação, a gestão destas vulnerabilidades não é uma boa prática voluntária mas uma obrigação com nome, como estabelece a diretiva NIS2 para quem opera na União Europeia.
O estrangulamento não é o patch, é quem o aplica
O patch é gratuito. O tempo não. Está publicado há dias, e o que escasseia é o tempo de quem consegue inventariar ambientes, atualizar motores, reler logs e assinar que a superfície está fechada. Quando esse trabalho se acumula, aparece a conta que ninguém orçamentou: horas de plataforma, horas de desenvolvimento e horas de revisão, todas a competir com o roadmap já comprometido antes de terça-feira.
O mercado português também já sentia a tensão antes do evento. Segundo a análise de mercado de Shakers, 327 das 29 398 ofertas tech ativas em Portugal em 26 de outubro de 2026 mencionam cibersegurança, e não como responsabilidade lateral de perfis vizinhos mas como requisito explícito da descrição. O peso é menor que nos mercados vizinhos, mas a lógica é a mesma: quando duas CVE com patch urgente caem numa terça-feira, a resposta não espera o ciclo anual de contratação, cobre-se com capacidade que comece esta semana.
Para o inventário e a correção, juntar à equipa um PHP developer sénior que já atravessou atualizações de versão massivas é o caminho rápido. Para o que vem a seguir, colaborar com um especialista em cibersegurança que audite a superfície e assine o que ficou fechado. Integrar esta capacidade através de uma infraestrutura de contratação, com condições validadas e sem alargar a estrutura permanente, é a diferença entre cobrir uma emergência de duas semanas e carregar um custo fixo de janeiro a dezembro.
Perguntas frequentes sobre php2shell
- Que versões do PHP são seguras depois do php2shell?
As publicadas em 21 de outubro de 2026: 8.5.12, 8.4.27, 8.3.36 e 8.2.35, cada uma no seu ramo. O patch só existe de 8.2 a 8.5: qualquer ambiente anterior fica exposto, e as versões sem suporte, do PHP 5.4 ao 8.1, não têm remédio.
- O WordPress é afetado pelo php2shell?
A vulnerabilidade está no motor PHP, não no WordPress nem nos seus plugins. Um site em WordPress fica coberto quando o alojamento ou o servidor serve uma versão corrigida do PHP. Atualizar plugins e temas não substitui esse patch.
- O que significa um RCE sem autenticação?
Que um atacante consegue que o servidor execute o seu código sem utilizador, sem password e sem sessão prévia. Não exige credenciais roubadas nem acesso inicial: basta alcançar o URL exposto, e por isso este tipo de falha presta-se a campanhas automáticas e massivas.
- Já está a ser explorado?
Sim. A CISA pediu aplicação imediata do patch em 21 de outubro de 2026, e tentativas de exploração em massa contra sites sem corrigir eram registadas nas horas seguintes à publicação dos detalhes (Help Net Security, 2026).
- E se não puder atualizar esta semana?
Reduza a superfície exposta enquanto espera: restrinja o acesso aos endpoints afetados, vigie o que lhes chega e dê uma data certa ao patch. E se o sistema corre num ramo sem suporte, o patch nunca chega: a saída é planear a migração de versão.
. 