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. 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.
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
- 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.
- 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.
- 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.
- 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.
- 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. 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.
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 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.