Em resumo: o patching virtual para PHP cobre o tempo até a atualização verdadeira estar instalada. Para isso, combinamos regras de uma Web Application Firewall com as medidas provisórias que o php.net publicou sobre o PHP2Shell e definimos logo o caminho para o patch regular. Não oferece proteção completa, mas reduz o risco durante o período de transição.
Quando faz sentido o patching virtual para PHP
No caso do PHP2Shell, o BSI recomenda a atualização imediata e, se esta não for possível, desligar temporariamente os servidores web da rede. Para muitas empresas, nenhuma das duas coisas é exequível de imediato: uma loja tem de continuar acessível, um desenvolvimento próprio precisa de um teste antes da atualização ou o servidor corre com PHP 8.1 ou anterior, para o qual já não existem atualizações oficiais.
Nestes casos, o patching virtual é uma ponte. Não substitui a decisão sobre se uma operação offline seria mais adequada. Essa ponderação é sua; nós fornecemos a avaliação técnica.
Porque é que uma WAF, por si só, não basta
A Cloudflare comunicou tentativas de ataque observadas e disponibilizou regras de proteção, mas avisa que regras baseadas apenas nos dados do pedido não bastam. A razão está na natureza das vulnerabilidades. Na CVE-2026-109618, um estado de falta de memória (out of memory) pode interromper o PHP enquanto os dados do pedido estão apenas parcialmente inicializados. Na CVE-2026-109619, o estado interno pode persistir após a libertação da memória e ser usado por um pedido posterior no mesmo worker. Estes erros dependem do estado do servidor, e não apenas do conteúdo de um único pedido.
Por isso, apostamos em várias camadas: regras de WAF à frente do servidor, medidas provisórias no próprio PHP e uma vigilância reforçada do servidor. Cada camada intercepta uma parte, nenhuma chega sozinha. Em conjunto, dão-lhe o tempo para instalar a atualização de forma ordenada.
As medidas provisórias segundo o php.net
O php.net indica várias definições que reduzem o risco, expressamente sem proteção completa. É importante que as aplicações não possam sobrepor estes valores. Um exemplo para um pool PHP-FPM com uploads:
; medidas provisórias PHP2Shell (sem proteção completa), depois reiniciar todos os workers
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; apenas PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Sem uploads, o php.net recomenda post_max_size = 8M. Como o memory_limit é suspenso, faz parte um limite de memória ao nível do contentor ou do cgroup, e não através de RLIMIT_AS ou RLIMIT_DATA. A definição session.upload_progress.enabled=0 pertence ao php.ini, ao pool FPM ou à configuração do servidor, e não a ini_set() ou .user.ini. É, ao mesmo tempo, a solução para o aviso sobre a CVE-2026-115560. Todas as medidas num só lugar constam de Medidas imediatas quando ainda não pode aplicar o patch.
As medidas provisórias só produzem efeito depois de reiniciar todos os workers do PHP. E protegem apenas contra ataques futuros: não respondem se alguém já tinha entrado antes.
Quando a operação offline é a melhor escolha
O patching virtual não é a resposta certa em todas as situações. Em algumas constelações, aconselhamos seguir o BSI e desligar temporariamente o servidor web da rede até ser aplicado o patch:
- o servidor corre com Apache e mod_php, onde a equipa do PHP classifica o risco como o mais elevado e foi demonstrado um exploit antes sequer de o código da aplicação ser executado
- no servidor encontram-se dados particularmente sensíveis, por exemplo dados de saúde, de clientes sob sigilo ou de pagamento
- não há possibilidade de fixar as medidas provisórias na configuração do servidor, por exemplo em certos pacotes de alojamento partilhado
- já existem sinais de que o servidor foi atacado
Uma operação offline temporária não significa que o seu site tenha sido comprometido. Alguns fornecedores colocaram sites offline por precaução. Uma página de aviso breve e objetiva para os visitantes é então, em regra, melhor solução do que uma indisponibilidade sem explicação.
Como ajuda concretamente a PHP SOS?
- Verificar a situação: registamos as versões do PHP, os modos de operação e as camadas de proteção existentes, como CDN, WAF ou proxy inverso. No mod_php, chamamos a atenção para o risco acrescido que a equipa do PHP vê aí.
- Construir camadas: ativamos ou completamos regras de WAF, fixamos as medidas provisórias na configuração do servidor e limitamos a memória através de contentor ou cgroup. Para configurações com Nginx, orientamo-nos por Proteger o Nginx com PHP-FPM.
- Reinício e teste: todos os processos PHP são reiniciados e depois verificamos uploads, formulários, início de sessão e checkout.
- Observar: durante o período de transição, prestamos atenção reforçada a falhas de workers, picos de memória e processos invulgares.
- Planear o patch: definimos quando e como chega a atualização regular e executamo-la através do serviço de patches PHP.
O que recebe, o que precisamos e o que não prometemos
Recebe uma documentação de todas as regras e definições aplicadas, com fundamentação, os resultados dos testes e um plano de datas e medidas para o patch verdadeiro. De si, precisamos de acesso ao servidor ou ao painel, de acesso à CDN ou à WAF, se existirem, de um interlocutor técnico e de indicações sobre as funções de upload das suas aplicações.
Não prometemos que o patching virtual impeça um ataque. Reduz o risco durante um período limitado. No PHP 8.1 e anteriores, não é um estado permanente; aqui, a migração para uma versão suportada faz parte do plano.
Perguntas frequentes
O que é o patching virtual?
O patching virtual significa proteger uma vulnerabilidade conhecida antes da aplicação, em vez de alterar o próprio código. Faz-se normalmente através de uma Web Application Firewall ou de alterações de configuração. É uma solução de ponte, não um substituto da atualização.
A WAF do meu fornecedor de CDN chega contra o PHP2Shell?
Por si só, em regra não. A Cloudflare disponibilizou regras de proteção, mas avisa ela própria que regras baseadas apenas nos dados do pedido não bastam. A WAF é uma camada adicional ao lado das medidas provisórias e do patch.
Durante quanto tempo posso confiar no patching virtual?
O menos possível. Deve cobrir o tempo até à atualização regular, por exemplo até haver uma janela de manutenção livre ou uma aplicação ter sido testada. No PHP 8.1 e anteriores, faz parte um plano de migração.
As medidas provisórias podem perturbar o meu site?
Sim, é possível. Limites de upload mais baixos podem impedir uploads de ficheiros grandes, e desativar o session upload progress afeta os indicadores de progresso durante o envio. Testamos as funções mais importantes após cada alteração.