# WAF e patching virtual para PHP

> Patching virtual para PHP: combinamos regras de WAF com as medidas provisórias do php.net até a atualização ser possível e planeamos o patch verdadeiro.

Fonte: https://phpsos.de/pt/leistungen/waf-virtuelles-patching/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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:

```ini
; 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](https://phpsos.de/pt/php2shell/cve-2026-115560/). Todas as medidas num só lugar constam de [Medidas imediatas quando ainda não pode aplicar o patch](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-patch/).

> **Importante:**
> 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?

1. **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í.
2. **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](https://phpsos.de/pt/server/nginx-php-fpm/).
3. **Reinício e teste:** todos os processos PHP são reiniciados e depois verificamos uploads, formulários, início de sessão e checkout.
4. **Observar:** durante o período de transição, prestamos atenção reforçada a falhas de workers, picos de memória e processos invulgares.
5. **Planear o patch:** definimos quando e como chega a atualização regular e executamo-la através do [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/).

## 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](https://phpsos.de/pt/leistungen/php-migration-legacy/) 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.

## Fontes

- [php.net: avisos de segurança e medidas provisórias](https://www.php.net/)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)