Atualização de Segurança PHP 2026: Guia de Correção do PHP2Shell CVSS 9.2

A própria divulgação foi invulgar. Em 20 de outubro, a equipa de segurança do PHP publicou um aviso prévio, agendou o lançamento para 21 de outubro às 14:00 UTC e reservou-se o direito de o lançar mais cedo. Os identificadores CVE vazaram um dia antes da divulgação, acompanhados de alegações exageradas sobre a gravidade e as versões afetadas. Os fabricantes das distribuições já tinham recebido os patches, e os CERT nacionais começaram a publicar orientações antes mesmo de o código ser tornado público. Por outras palavras: ninguém tinha uma desculpa legítima para demorar depois de o lançamento ter saído.

Duas Falhas, Um Lançamento de Emergência

Nenhuma das duas falhas é um erro de lógica numa aplicação. Ambas residem na forma como o PHP prepara e desmonta um pedido, e é por isso que nenhuma atualização de framework, de plugin ou regra de WAF substitui a atualização do interpretador.

CVE-2026-109618 — RCE por corrupção no esgotamento de memória. Quando a memória do PHP esgota, o pedido é abortado em vez de continuar. O aviso descreve um caminho em que esse aborto interrompe o PHP enquanto os dados internos do pedido estão apenas parcialmente inicializados, pelo que a etapa de limpeza do pedido acaba por tratar dados inválidos como válidos. Um atacante que consiga empurrar a utilização de memória até ao limite pode, assim, orientar o que acontece a seguir. É esta a falha que torna a orientação de mitigação tão contraintuitiva: o fornecedor pede aos administradores que impeçam o PHP de atingir o seu próprio teto de memória, não que o apertem.

CVE-2026-109619 — RCE por estado global obsoleto. O estado interno pertencente a um pedido pode sobreviver depois de a memória que o suporta ter sido libertada. O pedido seguinte tratado pelo mesmo processo worker pode consumir esse estado obsoleto antes de a inicialização normal o repor. Num worker de longa duração — exatamente o que são o PHP-FPM, o mod_php e o LiteSpeed — a reutilização de memória é uma condição normal e permanente, e é por isso que isto não é um caso raro reservado a configurações exóticas.

O nome PHP2Shell não é uma designação oficial do projeto PHP; surgiu de investigadores e empresas de segurança e acabou por ficar, por isso vai encontrá-lo em resultados de scanners, boletins de fornecedores de alojamento e avisos de CERT, sempre a referir-se exatamente a estas duas CVE.

Quem Está Realmente Exposto

O aviso não dá voltas: todas as instalações PHP que servem pedidos web estão em risco. Isso inclui PHP-FPM atrás de nginx ou Apache, Apache com mod_php, php-cgi, LiteSpeed e FrankenPHP. A diferença entre elas está no trabalho que um atacante tem de fazer.

Se aloja WordPress, WooCommerce, Laravel, Magento, ERPs adjacentes ao Magento ou qualquer portal de reservas em PHP da sua atividade comercial, está abrangido pelas primeiras três linhas mesmo quando o código da aplicação está impecável. Para uma perspetiva mais ampla sobre quem deve, à partida, ter a seu cargo o runtime, consulte o nosso guia sobre externalização de TI na Turquia.

Verifique a Sua Versão em Dois Minutos

A armadilha aqui é a aritmética das versões. As distribuições fornecem o PHP 8.3.6 ou 8.2.x durante anos e fazem backport das correções de segurança para dentro do mesmo número de versão visível, por isso php -v por si só não diz se está protegido. Compare três coisas.

1. A versão visível do PHP e a SAPI que serve o tráfego.

2. A versão do pacote da distribuição, não a upstream. Em Debian e Ubuntu, o changelog é a resposta honesta; em sistemas RPM, consulte o changelog do pacote.

Se o changelog mencionar ambas as CVE na versão instalada, está corrigido, ainda que php -v continue a dizer 8.3.6. Está aqui a diferença entre uma resposta de segurança a sério e uma superstição de número de versão.

3. Se o processo em execução recarregou o binário corrigido. Uma atualização de pacote que nunca é seguida de um reinício deixa o código antigo em memória. Compare a hora de arranque do serviço com a hora de instalação do pacote:

Em cPanel, Plesk, DirectAdmin ou numa plataforma gerida, o equivalente é o seletor de PHP e o boletim de segurança do próprio fornecedor de alojamento: identifique a versão incorporada realmente atribuída ao seu site, não a mais recente anunciada no painel. Se o seu fornecedor de alojamento não conseguir indicar uma data de patch, considere o site não corrigido. Os nossos serviços de infraestrutura digital cobrem esta auditoria e a própria atualização; também pode simplesmente contactar-nos com a sua stack e dizemos-lhe o que verificaríamos.

Versões Corrigidas e o Precipício do EOL

O PHP dá a um ramo dois anos de desenvolvimento ativo e mais dois anos de correções de segurança. Foi essa política que produziu quatro correções simultâneas em 21 de outubro — e é também ela que deixa os ramos mais antigos órfãos.

Dois avisos práticos do próprio comunicado. Primeiro, se instala o PHP a partir de um repositório da comunidade em vez da sua distribuição, esse repositório pode ficar atrás da janela de segurança: os responsáveis pelos amplamente usados pacotes Remi declararam que não teriam atualizações no próprio dia, por isso o caminho seguro são os pacotes da sua distribuição ou uma compilação a partir do código-fonte. Segundo, se está no PHP 8.1 ou anterior, «esperar pelo nosso fornecedor de alojamento» é uma decisão de segurança que está a tomar em nome dos seus clientes — documente-a ou mude-a.

Corrigir um Servidor em Produção Sem Provocar um Incidente

As atualizações de segurança dentro da mesma minor raramente quebram uma aplicação; o que quebra são os reinícios não testados. A ordem abaixo é a que usamos em plataformas comerciais em produção, e mantém a janela de risco curta sem arriscar o site.

1. Primeiro, o snapshot. Um snapshot de hipervisor ou de volume que tenha realmente testado restaura em minutos, e torna barata a decisão de corrigir.
2. Reproduza a versão em staging. O mesmo ramo, as mesmas extensões, os mesmos ficheiros de configuração do PHP, uma cópia dos dados de produção. Percorra os fluxos de checkout, de pedido de orçamento e de pagamento, não apenas a página inicial.
3. Atualize o conjunto de pacotes como um todo. Misturar um CLI atualizado com um binário FPM antigo é a receita para acabar com um php -v corrigido e um caminho web por corrigir: apt-get update && apt-get install --only-upgrade 'php8.3-*', ou dnf update --security 'php*' em servidores RPM.
4. Reinicie o processo que serve os pedidos e depois verifique que reiniciou. systemctl restart php8.3-fpm (ou recarregue o Apache / reinicie o LiteSpeed), depois volte a verificar a hora de arranque do serviço e execute novamente as consultas de versão e de changelog.
5. Vigie o registo de erros durante uma hora. Mensagens de OOM, novas assinaturas de erros fatais e taxas de 5xx invulgares são os sinais de que as definições de mitigação abaixo podem precisar de ajuste — não razões para adiar a atualização.
6. Registe as evidências. Versão do pacote, linha do changelog que menciona ambas as CVE, hora exata do reinício. Clientes, auditores e revisões de controlos ao estilo ISO 27001 pedem exatamente isto, e guardá-lo demora dez segundos.

Onde a atualização tem de esperar — uma integração de ERP validada, um calendário de lançamentos bloqueado por embargo, um circuito de aprovação pelo cliente — coloque nesse mesmo dia um controlo compensatório à sua frente, em vez de deixar a porta aberta e ficar à espera. Foi isso que os avisos dos CERT nacionais recomendaram exatamente para esta situação: isolar da rede pública as aplicações PHP expostas à internet nos casos em que a correção imediata não é possível.

Mitigações Temporárias: Estreitar a Janela, Não Fechá-la

O aviso do PHP afirma claramente que não existe mitigação completa e que a atualização é a única opção segura. Encare o que se segue como uma cobertura de dias, não de semanas, aplicada a um nível ao qual a aplicação não se possa sobrepor, com todos os workers reiniciados depois.

Contra a CVE-2026-109618 (o caminho do esgotamento de memória)

• Deixe o PHP esgotar a memória da máquina em vez do seu próprio limite: memory_limit = -1, idealmente como php_admin_value memory_limit = -1, para que o código da aplicação não possa repor o teto.
• Mantenha pequenos os corpos dos pedidos ao nível do interpretador: a orientação do aviso aponta para cerca de 8 MB quando não há uploads e cerca de 32 MB quando há, com upload_max_filesize abaixo de post_max_size.
• Imponha os limites dispendiosos no proxy, porque o estrago está no pedido descodificado, não no tamanho transmitido: tamanho total do corpo descodificado, número de campos de entrada, número de partes multipart, número de cabeçalhos, profundidade de aninhamento — e cubra os pedidos que chegam sem um Content-Length utilizável.
• Contenha o raio de impacto com um limite de memória de container ou cgroup dimensionado de modo a que um worker morto seja um incidente de disponibilidade, não um incidente do servidor. Não os substitua por RLIMIT_AS ou RLIMIT_DATA: estes despoletam precisamente a falha de alocação que está no caminho vulnerável.

Contra a CVE-2026-109619 (o caminho do estado obsoleto)

• Desative o progresso de upload de sessão com session.upload_progress.enabled = 0, definido no php.ini, no pool do FPM ou na configuração do servidor — num local que se aplique antes da análise do pedido. Depois reinicie todos os workers, porque o FPM partilha entre pedidos o estado de módulos já inicializado. O ini_set() e o .user.ini chegam tarde demais para ajudar.
• No PHP 8.5, defina fatal_error_backtraces = 0 e reinicie.
• Remova as definições por pedido que sejam inválidas ou obsoletas e que, por isso, emitem diagnósticos logo na inicialização. Suprimir a mensagem com error_reporting, display_errors ou @ não remove o caminho de código.
• Cace erros fatais alcançáveis por um atacante e timeouts de longa duração nos tratadores de uploads e importações, no código de callbacks e nas rotinas de limpeza — os mesmos sítios onde ambas as falhas vivem.

Uma CDN ou um WAF à frente da origem ainda justifica o custo: a limitação de tráfego por taxa, o bloqueio de pedidos com formatos anómalos e a correção virtual reduzem o ruído e atrasam a sondagem oportunista. São uma lombada para um atacante direcionado, não um controlo que possa dar como remediação.

O Que Perguntar Hoje ao Seu Fornecedor de Alojamento

Os guiões do suporte respondem a esta pergunta com um «estamos sempre atualizados». Peça antes evidências que possa arquivar:

• A versão de PHP incorporada atribuída à nossa conta, e se se trata de um pacote da distribuição ou de uma compilação do fabricante.
• A data em que as correções da CVE-2026-109618 e da CVE-2026-109619 chegaram ao vosso parque de servidores, com a string da versão interna do pacote.
• Se a correção se aplica à SAPI que serve o nosso site (FPM, LiteSpeed, mod_php) e a qualquer nó de staging ou de cópia de segurança que venhamos a restaurar.
• Se a plataforma ainda não estiver corrigida: que controlo compensatório está em vigor e até quando.
• A vossa política permanente para ramos em fim de vida (EOL) — o que acontece ao meu site a 1 de janeiro de 2027, quando termina o suporte de segurança do PHP 8.2.

Um fornecedor que responda a essas cinco perguntas num único e-mail é um fornecedor que vale a pena manter. Um que volte com texto de marketing é uma conversa de migração; aplica-se aqui a mesma diligência do nosso trabalho de avaliação de lacunas ISO 27001, em que o entregável é evidência, não tranquilização.

Deve Assumir Que Foi Comprometido?

Não automaticamente — mas verifique em vez de conjecturar, sobretudo se o servidor esteve exposto à internet pública durante a janela anterior à aplicação do seu patch.

• Procure processos, portas à escuta e entradas de cron que não tenha criado, bem como ligações de saída do utilizador do worker do PHP.
• Compare, por diferenças, os diretórios com permissão de escrita da aplicação face a uma fonte fidedigna de deployment: ficheiros PHP novos, diretórios de upload modificados, pastas temporárias executáveis sem explicação.
• Pesquise nos registos web tempestades de pedidos nas horas da divulgação, corpos multipart invulgarmente grandes ou pedidos que devolveram 500 com assinaturas de OOM no registo de erros do PHP.
• Confirme que o binário corrigido está de facto a correr — a comparação da hora de reinício acima responde a isso.
• Se algo parecer estar errado, trate-o como um incidente: preserve o disco e os registos, renove todas as credenciais que a aplicação consiga ler e reconstrua a partir de uma imagem conhecida como boa. Reinstalar o pacote PHP por cima de um servidor comprometido não é remediação.

Um Exemplo Prático da Nossa Própria Infraestrutura

O worldwidetradex.com corre em Ubuntu 24.04 LTS com nginx e PHP-FPM, por isso aplicámos a nós próprios as verificações acima em 22 de outubro. Os resultados ilustram bem por que razão a aritmética das versões importa:

A lição aplica-se a qualquer stack: a sua postura de segurança é a versão do pacote, mais o changelog, mais o reinício — não a string de versão de marketing no painel do alojamento.

Torne a Correção Rotina, Não Heroísmo

O PHP2Shell não é memorável por ser exótico; é memorável porque o interpretador em que corre a maior parte da web tinha uma falha crítica, explorável antes da autenticação, e milhares de servidores tiveram de reagir em poucas horas. As equipas que atravessaram o episódio a dormir não tiveram sorte — tinham automatização.

• Atualizações de segurança automáticas e sem supervisão para o interpretador, com a versão e o reinício registados automaticamente.
• Um inventário que saiba que SAPI e que ramo de PHP cada site utiliza, incluindo staging, cópias de segurança e aquele WordPress de 2019.
• Um caminho de restauro ensaiado, para que «corrigir já» nunca seja posto na balança contra «não conseguimos voltar atrás».
• Um plano de ramos: nada num lançamento de PHP cujo suporte de segurança termine nos próximos doze meses.
• Um responsável nomeado por servidor e uma via de escalonamento escrita para os dias em que um patch surge às 14:00 UTC numa quarta-feira.

Se preferir comprar essa capacidade a contratá-la internamente, nós assumimos a responsabilidade de plataformas PHP em produção — cadência de patches, monitorização, cópias de segurança e restauros documentados — no âmbito do nosso trabalho de infraestrutura gerida. Comece com um resumo breve e as quantidades: peça um orçamento.

Perguntas Frequentes

Fontes

• PHP — aviso de segurança «Critical remote code execution vulnerabilities, update now» e os anúncios de lançamento de 21 de outubro de 2026, incluindo a orientação de mitigação e o calendário de suporte em versões suportadas.
• GitHub Security Advisories do repositório do PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) e GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Security Advisory 2026-018, «Critical Vulnerabilities in PHP», que nomeia ambas as CVE.
• Infosecurity Magazine — «Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches» (21 de outubro de 2026) e «PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure» (22 de outubro de 2026).

Precisa de alguém que trate da atualização por si? Para falar de correção, de uma auditoria de versões, de migração para uma plataforma PHP gerida e corrigida ou da infraestrutura que a envolve, contacte-nos ou ligue para o +90 505 679 78 03.