# Medidas imediatas quando ainda não pode aplicar o patch

> Workaround para a vulnerabilidade PHP2Shell: as medidas provisórias do php.net, bem aplicadas, com limites e indicações para o caminho até ao patch.

Fonte: https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-patch/  
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:** 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](https://phpsos.de/pt/php2shell/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`):

```ini
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:

```apache
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:

```ini
# 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](https://phpsos.de/pt/php2shell/php-fpm-neustart/). O hardening geral da configuração descreve-o [Configurar o php.ini de forma segura](https://phpsos.de/pt/ratgeber/php-ini-sicher-konfigurieren/).

> **Importante:**
> 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](https://phpsos.de/pt/leistungen/waf-virtuelles-patching/).

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](https://phpsos.de/pt/leistungen/php-patch-service/), 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.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)