# WAF ou atualização: porque precisa de ambas

> WAF em vez de atualização no PHP2Shell? O que faz uma WAF, onde acaba e porque só a atualização do PHP com reinício fecha a vulnerabilidade.

Fonte: https://phpsos.de/pt/blog/waf-oder-update/  
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:** WAF em vez de atualização não funciona no PHP2Shell. Uma firewall de aplicações web, isto é, um filtro à frente do site, examina pedidos e pode bloquear padrões de ataque conhecidos. A vulnerabilidade em si está, porém, no interpretador PHP e só desaparece com a atualização e o reinício de todos os processos PHP. Uma WAF é uma camada adicional sensata e uma ponte de poucos dias, não a solução.

## Porque é que esta pergunta é agora tão frequente

Na semana do PHP2Shell, muitos operadores leram uma notícia aparentemente boa: segundo declarações próprias, a Cloudflare tem regras de proteção ativas desde 21/10/2026, 03:02 UTC, também para clientes do plano gratuito. Quem de qualquer modo está atrás da Cloudflare ou de outra WAF pergunta-se, compreensivelmente, se a atualização ainda é urgente.

A resposta honesta é sim. A própria Cloudflare faz uma ressalva: regras baseadas apenas nos dados do pedido não bastam, por isso o serviço examina também a resposta do servidor. A Cloudflare observou além disso padrões de ataque alterados. E a proteção só atua sobre o tráfego que de facto passa pela Cloudflare. Os pormenores deste fornecedor descreve-os [Regras de proteção da Cloudflare contra o PHP2Shell](https://phpsos.de/pt/blog/cloudflare-waf-php2shell/). Aqui trata-se da ponderação de princípio, independente do fornecedor.

## O que uma WAF vê e o que uma atualização altera

Uma WAF fica à frente da aplicação. Vê cada pedido, compara-o com regras e deixa-o passar, bloqueia-o ou regista-o. Não sabe como o PHP processa internamente o pedido. As duas vulnerabilidades do PHP2Shell surgem, porém, precisamente aí: a CVE-2026-109618 num estado de falta de memória (out of memory) enquanto os dados do pedido estão apenas parcialmente inicializados, a CVE-2026-109619 por um estado interno que permanece depois de um pedido no mesmo worker.

A atualização corrige esse código. Depois, a causa está eliminada, seja qual for o aspeto do pedido. Quem quiser compreender em que ponto do decurso de um pedido isto acontece encontra as bases em [O ciclo de vida do pedido no PHP](https://phpsos.de/pt/php/request-lebenszyklus/).

## WAF em vez de atualização: a comparação honesta

| Critério | Firewall de aplicações web | Atualização do PHP com reinício |
|---|---|---|
| O que é resolvido? | Nada, padrões conhecidos são travados | A causa no interpretador PHP |
| Proteção contra novas variantes de ataque | Só se as regras forem ajustadas a tempo | Sim, a vulnerabilidade deixa de existir |
| É possível contornar? | Sim, por exemplo através da acessibilidade direta do servidor de origem | Não, desde que todos os processos PHP tenham sido reiniciados |
| Rapidez | Muitas vezes ativa de imediato | Depende da versão, do acesso e da janela de manutenção |
| Efeitos secundários | Falsos alarmes, formulários ou uploads perturbados | Raros, em saltos de versão são precisos testes de compatibilidade |
| Utilidade na próxima vulnerabilidade | Elevada, se mantida | Nenhuma, cada vulnerabilidade precisa da sua atualização |
| Ajuda no PHP 8.1 e anteriores? | Como transição | Só através de backport ou migração |

A tabela mostra porque é que as duas medidas andam juntas. A WAF é rápida e abrangente, mas nunca completa. A atualização é completa, mas só para uma vulnerabilidade concreta e nem sempre possível de imediato.

Um ponto é muitas vezes ignorado na prática: uma WAF altera o comportamento do site. Regras rigorosas podem bloquear encomendas legítimas, formulários de contacto ou uploads de ficheiros sem que alguém o note de imediato. Quem ativa uma WAF em modo rigoroso numa crise deve, por isso, percorrer uma vez os processos mais importantes do site e verificar os registos dos primeiros dias quanto a pedidos bloqueados, mas legítimos.

## Como combinar ambas com sentido

1. **De imediato:** verificar se existe uma WAF e se as regras adequadas estão ativas. Na Cloudflare, nos planos pagos, pôr o Managed Ruleset em Block, segundo o fornecedor.
2. **De imediato:** garantir que o servidor de origem só é acessível através da WAF, por exemplo com uma liberação na firewall apenas para os seus intervalos de endereços. Caso contrário, a proteção cai no vazio.
3. **Na próxima janela de manutenção:** atualizar o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou instalar o backport confirmado da distribuição.
4. **Logo a seguir:** reiniciar todos os workers e processos PHP e verificar que já não corre nenhum processo antigo. Ficheiros novos, por si só, não bastam; mais sobre isto em [Depois da atualização: reiniciar o PHP-FPM e todos os workers](https://phpsos.de/pt/php2shell/php-fpm-neustart/).
5. **Depois:** manter as regras da WAF, avaliar os falsos alarmes e definir exceções de forma direcionada, em vez de desligar regras em bloco.

Com uma WAF própria, baseada no ModSecurity e no OWASP Core Rule Set, consegue-se algo semelhante; as bases descreve-as [Usar o ModSecurity e o OWASP Core Rule Set](https://phpsos.de/pt/blog/modsecurity-owasp-crs/). Uma forma particular é a filtragem de pedidos de upload fora dos caminhos de upload verdadeiros, sugerida por autores especializados. É não oficial, pode quebrar formulários e só deve entrar em produção após testes.

> **Importante:**
> Nem a WAF nem a atualização removem software malicioso introduzido antes. Verifique, depois do patch, se desde 17/10/2026 surgiram anomalias.

## Quando não precisa de WAF e quando não precisa de prestador de serviços

Uma WAF não é obrigatória para todos os sites. Um pequeno site de empresa num fornecedor de alojamento que aplica o patch do PHP atempadamente e o confirma fica muitas vezes suficientemente protegido sem WAF própria, se o CMS e os plugins estiverem atualizados. Também quem consegue atualizar ele próprio o seu servidor em pouco tempo não precisa da WAF como ponte.

Passa a fazer sentido em lojas, portais e aplicações com muitos formulários, em sistemas antigos que não podem ser atualizados de imediato e onde vários sites devem ser protegidos de forma centralizada. Só precisa de um prestador de serviços para isso se a configuração, os testes e a manutenção contínua não estiverem cobertos internamente.

## Como ajuda concretamente a PHP SOS?

- Verificamos se a sua WAF está de facto à frente de todos os acessos e se o servidor de origem é acessível diretamente.
- Configuramos regras ou ajustamo-las e testamos formulários, uploads e interfaces quanto a efeitos secundários.
- Instalamos a atualização do PHP, reiniciamos todos os processos e documentamos o estado.
- Onde a atualização demora, fazemos a ponte com [WAF e patching virtual](https://phpsos.de/pt/leistungen/waf-virtuelles-patching/) e uma data fixa para o patch verdadeiro.

## Conclusão

A pergunta «WAF ou atualização» está mal colocada. A atualização fecha a vulnerabilidade, a WAF ganha tempo e trava muito do resto. Quem confia só na WAF fia-se em regras que os atacantes podem contornar. Quem só aplica patches fica, na próxima vulnerabilidade, de novo sem ponte.


## Perguntas frequentes

**Uma WAF basta como proteção contra o PHP2Shell?**  
Não. Uma WAF examina o tráfego e pode bloquear padrões de ataque conhecidos. A vulnerabilidade em si está no interpretador PHP e mantém-se até o PHP ser atualizado e reiniciado. A Cloudflare salienta expressamente que as suas regras não substituem a atualização.

**Estou automaticamente protegido por estar atrás da Cloudflare?**  
Só para o tráfego que de facto passa pela Cloudflare. Se o servidor de origem for acessível diretamente a partir da Internet, a proteção é contornada. Nos planos pagos, deve verificar, segundo a Cloudflare, que o Managed Ruleset está em Block.

**Compensa uma WAF depois da atualização?**  
Muitas vezes sim. Uma WAF pode travar análises em massa, ataques conhecidos a plugins e o abuso de páginas de início de sessão e ganha tempo na próxima vulnerabilidade. Precisa, porém, de manutenção e de testes, caso contrário os falsos alarmes perturbam a operação.

**O que é o patching virtual?**  
Significa proteger temporariamente uma vulnerabilidade com regras à frente da aplicação, em vez de alterar o código. É uma ponte até à verdadeira atualização, não um substituto.

## Fontes

- [Blogue da Cloudflare](https://blog.cloudflare.com/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)