Em resumo: um workaround para a vulnerabilidade de segurança PHP2Shell pode reduzir o risco, mas não substitui a atualização. O php.net indica para isso limites fixos de memória e de upload, a desativação do session upload progress e, no PHP 8.5, fatal_error_backtraces=0. Se nem isso for possível a curto prazo, o BSI recomenda desligar temporariamente o servidor web da rede.
O que um workaround pode fazer e o que não pode
As medidas provisórias do php.net destinam-se a dificultar as condições em que as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 são exploráveis. Expressamente, não são uma proteção completa. As vulnerabilidades só estão corrigidas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 ou num backport confirmado do seu fornecedor.
As medidas fazem sentido quando a atualização ainda não é possível por um motivo concreto: falta uma janela de manutenção, uma aplicação tem de ser testada primeiro ou opera PHP 8.1 ou anterior, para o qual já não existe atualização oficial. São então uma ponte, não um destino.
Por isso, planeie a atualização ao mesmo tempo que o workaround: quem a executa, em que janela de manutenção e quem verifica depois que todos os workers foram reiniciados? Uma transição sem data de fim corre o risco de se tornar um estado permanente.
Opção 1: desligar o servidor temporariamente da rede
O BSI declarou o nível de alerta 3 (laranja) e recomenda desligar temporariamente da rede os servidores web afetados quando a atualização não for possível de imediato. Alguns fornecedores fizeram-no por precaução; isso não significa que esses sites tenham sido comprometidos.
Para muitas empresas, uma indisponibilidade da loja ou do portal é cara. Pode fazer sentido uma ponderação: acesso apenas por VPN ou por endereços IP autorizados, uma página de manutenção estática em vez da aplicação PHP ou a desativação de sites individuais desnecessários no servidor. Quanto menos PHP estiver acessível do exterior, menor é a superfície de ataque.
É importante tomar a decisão de forma consciente e registá-la: quem decidiu, quando, manter o servidor online e com que medidas de proteção? Isso ajuda mais tarde perante a seguradora, a proteção de dados e a administração.
As medidas provisórias do php.net
| Medida | Valor | Nota |
|---|---|---|
memory_limit |
-1, sem poder ser sobreposto |
definir depois o limite de memória através de contentor ou cgroup |
post_max_size |
8M sem uploads, 32M com uploads |
upload_max_filesize abaixo disso |
| Limite de memória | através de contentor/cgroup | não através de RLIMIT_AS ou RLIMIT_DATA |
session.upload_progress.enabled |
0 |
no php.ini, no pool ou na configuração do servidor, não através de ini_set() ou .user.ini |
fatal_error_backtraces |
0 |
apenas PHP 8.5 |
A definição session.upload_progress.enabled=0 é, ao mesmo tempo, a solução para a vulnerabilidade comunicada a 23 de outubro, a CVE-2026-115560.
Aplicar corretamente o workaround para a vulnerabilidade do PHP
O decisivo é o local. Os valores têm de ser definidos de modo que uma aplicação não os possa sobrepor. Os caminhos e os nomes de serviços variam conforme a distribuição; os exemplos partem do PHP 8.3.
PHP-FPM, no pool (p. ex. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; apenas PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache com mod_php, na configuração do servidor ou no VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Limite de memória através de cgroup, aqui com systemd para o serviço FPM. O valor, ajuste-o ao seu servidor:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Depois, reinicie todos os workers, caso contrário nada disto produz efeito: systemctl restart php8.3-fpm ou, no caso do mod_php, o Apache. Como verificar que já não corre nenhum processo antigo, consta de Reiniciar o PHP-FPM e todos os workers. O hardening geral da configuração descreve-o Configurar o php.ini de forma segura.
Teste uploads e formulários grandes após a mudança. Um post_max_size demasiado curto pode bloquear encomendas, formulários de candidatura ou uploads de multimédia. É um motivo para não adiar muito a atualização.
Camadas de proteção adicionais
Uma Web Application Firewall ou o patching virtual podem ajudar como camada adicional. A Cloudflare disponibilizou regras de proteção, mas avisa ela própria que regras baseadas apenas nos dados do pedido não bastam. Uma WAF é, por isso, um complemento e não um substituto. Mais informação em WAF e patching virtual.
Guarde também os registos do servidor desde 20 de outubro. Segundo notícias dos meios de comunicação, foi observada uma primeira tentativa de ataque já a 17 de outubro; os registos são a base, caso mais tarde tenha de esclarecer se algo aconteceu antes do patch.
Como ajuda concretamente a PHP SOS?
- Esclarecer a situação: verificamos se uma atualização é possível a curto prazo ou se é necessária uma transição e discutimos consigo a opção de desligar partes da rede.
- Aplicar as medidas: inserimos os valores do php.net no local certo, definimos o limite de cgroup e reiniciamos todos os workers.
- Testar o funcionamento: formulários, uploads e processos de encomenda são verificados após a mudança.
- Conduzir ao patch: através do serviço de patches PHP, planeamos a atualização e revertemos depois, de forma controlada, os valores provisórios onde incomodem.
Perguntas frequentes
O workaround protege totalmente contra o PHP2Shell?
Não. O php.net designa expressamente as medidas como provisórias e não como proteção completa. Reduzem o risco até a atualização estar instalada. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda desligar temporariamente da rede os servidores sem patch.
Posso definir as definições através de .htaccess ou .user.ini?
Para session.upload_progress.enabled, o php.net exclui expressamente ini_set() e .user.ini. Também para o memory_limit vale: o valor tem de ser definido de modo que a aplicação não o possa sobrepor. Isso consegue-se no php.ini, no pool FPM com php_admin_value ou na configuração do servidor Apache.
Uma Web Application Firewall chega como workaround?
Como camada adicional, pode ajudar. A Cloudflare disponibilizou regras de proteção, mas ela própria chama a atenção para o facto de regras baseadas apenas nos dados do pedido não bastarem. Uma WAF não substitui nem a atualização nem as medidas provisórias no servidor.
O que faço se só tenho alojamento partilhado?
Então o php.ini e o reinício estão com o fornecedor de alojamento. Pergunte concretamente se a atualização foi instalada ou as medidas provisórias aplicadas e se todos os processos PHP foram reiniciados.