Tutorial: Como mitigar PHP2Shell (CVE-2026-109618 / 109619)

Daniel Muñoz · Ontem às 09:50

⚠️ PHP2Shell: o que fazer se você tem hospedagem compartilhada e seu provedor não atualizou

O PHP lançou em 21/10 patches de emergência para duas vulnerabilidades críticas (CVE-2026-109618 e CVE-2026-109619), com pontuação 9.2/10. Elas permitem executar código no servidor sem estar logado, e já existem ataques ativos.

As versões corrigidas são: 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

O detalhe é que muitas hospedagens ainda não compilaram os pacotes, o repositório do Ondřej está colapsado e os provedores não respondem aos tickets. Aqui deixo o que vocês podem fazer enquanto isso e, acima de tudo, o que devem exigir do seu provedor.

Atenção, antes de começar: a única solução completa é atualizar o PHP para a versão corrigida. As mitigações temporárias apenas reduzem a exposição, e na hospedagem compartilhada a maioria delas só pode ser aplicada pelo provedor, porque precisam ser feitas em nível de servidor. Sendo honestos, aqui estamos bastante nas mãos da hospedagem.

🥇 Passo 1: verifique se você já tem a versão corrigida disponível

Isso é o primeiro, porque se existir, o problema acabou.

Se você tem cPanel (Banahosting e a maioria das hospedagens latinas):

Procure por "Select PHP Version" ou "Selecionar versão do PHP" (CloudLinux), ou "MultiPHP Manager".
Veja se na lista aparece a versão corrigida da sua ramificação (por exemplo 8.3.36 se você está na 8.3).
Se aparecer, altere e pronto. Se não, siga para o passo 2.

Se você tem Plesk: vá ao domínio → PHP Settings e veja quais versões são oferecidas.

Se você tem DirectAdmin: Domain Setup / PHP Version Selector, o mesmo.

Os pacotes do CloudLinux (alt-php) e do cPanel (ea-php) costumam sair antes dos do Ondřej, então vale a pena verificar várias vezes ao dia.

🥈 Passo 2: coloque o Cloudflare na frente do seu site (se você ainda não tem)

O Cloudflare já está detectando os ataques. Com seu domínio passando por lá, o tráfego malicioso é filtrado antes de chegar ao PHP. Verifique no painel de Security → WAF se você tem ativas as regras gerenciadas para esses CVEs (no plano gratuito pode variar, então verifique).

Hoje, em hospedagem compartilhada, isso é o mais efetivo que você pode fazer por conta própria.

🥉 Passo 3: mitigações de configuração (aqui quem manda é o provedor)

Importante: O advisory oficial do PHP esclarece que session.upload_progress.enabled = 0 tem que ser aplicado antes de o PHP processar a requisição, ou seja, no php.ini do servidor ou no pool do PHP-FPM, reiniciando os workers. No PHP-FPM não se deve confiar no .user.ini para isso.

Na hospedagem compartilhada isso significa que a mitigação real tem que ser aplicada pelo seu provedor, não por você. Por isso os passos 1 e 2 são a prioridade.

O que a hospedagem tem que fazer (em nível de servidor ou pool):

Inserir CODE, HTML ou PHP:

session.upload_progress.enabled = 0
memory_limit = -1   (con límite de memoria externo por cuenta: LVE/cgroups)
fatal_error_backtraces = 0   (solo PHP 8.5)

e reiniciar todos os workers do PHP.

Texto para o ticket, caso sua hospedagem não responda:

Inserir CODE, HTML ou PHP:

Asunto: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) - solicitud urgente

Mi cuenta sigue en PHP [VERSIÓN], sin el parche publicado el 21/10
(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).

Mientras compilan la versión corregida, solicito aplicar a nivel de
servidor o pool de FPM (no .user.ini) las mitigaciones del advisory
oficial de PHP:

- session.upload_progress.enabled = 0
- memory_limit = -1, con límite de memoria externo por cuenta
- fatal_error_backtraces = 0 (si es PHP 8.5)

y reiniciar los workers. Por favor indíquenme fecha estimada del parche.

E o que eu posso fazer da minha conta?

Pouco, sendo honestos. Você pode deixar isso no seu .user.ini (ou através do cPanel → MultiPHP INI Editor):

Inserir CODE, HTML ou PHP:

session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Se o seu site precisa subir arquivos pesados, use post_max_size = 32M e deixe upload_max_filesize um pouco abaixo.

Mas tenham claro que, no PHP-FPM, isso não te protege desta vulnerabilidade: é aplicado tarde demais. Deixe como uma camada extra, não como solução.

Não coloque php_value / php_flag no .htaccess se seu PHP roda como FPM/CGI. Isso derruba o site com erro 500. Para saber como roda, crie sapi.php com <?php echo php_sapi_name();, abra-o e apague-o. Se aparecer fpm-fcgi, cgi-fcgi ou litespeed, nada de php_value no .htaccess.

Se você tem Plesk: em domínio → PHP Settings → "Additional configuration directives" você pode colar as diretivas do bloco do provedor. Dependendo de como sua hospedagem configurou o Plesk, isso pode ficar em nível de pool, mas confirme com o suporte antes de considerar mitigado.

🤔 Por que memory_limit = -1? Isso não é perigoso?

Boa pergunta. Uma das vulnerabilidades é ativada quando o atacante faz com que o PHP chegue ao seu limite de memória. Ao remover o limite, fecha-se essa via, mas não todas: o PHP deixa claro que não é uma mitigação completa.

E tem seu próprio risco: uma única requisição poderia consumir toda a RAM. Por isso só faz sentido se existir um limite de memória externo por conta (LVE/cgroups no CloudLinux). Não é algo para colocar às cegas, e por isso está na lista do que o provedor deve aplicar.

Quando o PHP estiver atualizado, o memory_limit tem que voltar para um valor normal (256M, por exemplo).

🧹 Passo 4: limpe seus .htaccess e .user.ini antigos (isso sim depende de você)

Um dos dois gatilhos confirmados do ataque são os warnings que geram ajustes de PHP inválidos ou obsoletos aplicados por requisição. Muitos de nós temos .htaccess herdados de anos atrás com diretivas que já não existem.

Verifique todas as pastas, não apenas a raiz (plugins, subdomínios, pastas antigas), e remova coisas como:

Inserir CODE, HTML ou PHP:

magic_quotes_gpc
register_globals
safe_mode
allow_call_time_pass_reference

e qualquer outra diretiva de PHP que você não reconheça ou que seja de versões antigas.

✅ Passo 5: verifique sua configuração (sem se confiar)

Crie check.php na raiz, abra-o no navegador e apague-o assim que o vir:

Inserir CODE, HTML ou PHP:

<?php
header('Content-Type: text/plain');
foreach (['session.upload_progress.enabled','memory_limit','post_max_size','upload_max_filesize'] as $k) {
    echo $k, ' = ', var_export(ini_get($k), true), PHP_EOL;
}
echo 'PHP ', PHP_VERSION, ' / ', php_sapi_name(), PHP_EOL;

Importante: isso apenas confirma qual versão do PHP você tem e que as diretivas estão colocadas sem dar erro. Não prova que a mitigação está ativa no momento do ataque: um .user.ini pode mostrar "0" aqui e ainda assim não proteger nada. O que realmente importa é que a versão seja uma das corrigidas.

Resumo rápido:

Seu painel já tem a versão corrigida? → Altere e pronto.
Não tem? → Cloudflare na frente + ticket ao provedor para que aplique as mitigações em nível de servidor.
Limpe diretivas antigas em todos os seus .htaccess / .user.ini.
.user.ini com upload_progress = 0 como camada extra, sem se confiar.
Quando atualizarem o PHP: confirme a versão com check.php e retorne o memory_limit à normalidade.

Se sua hospedagem demora dias para reagir a algo de 9.2 com ataques ativos, isso também diz bastante sobre ela.

Qualquer dúvida, deixem seu caso aqui abaixo com a versão do PHP que aparece para vocês e eu dou uma ajuda. 🤝

Tronlar · Ontem às 09:58

Boa contribuição. Só faria uma ressalva sobre uma coisa do passo 3 pelo que o PHP indica no advisory oficial. Para session.upload_progress.enabled = 0, o PHP alerta que no PHP-FPM não se deve confiar no .user.ini como mitigação, porque essa configuração tem que ser aplicada antes do processamento da requisição. Recomendam fazê-lo a partir do php.ini, da configuração do pool de FPM ou da configuração do servidor e reiniciar os workers. Por isso, embora um check.php mostre session.upload_progress.enabled = 0, não confirma necessariamente que essa mitigação esteja atuando no momento necessário para bloquear essa vulnerabilidade. Também indicam que memory_limit = -1 reduz uma das vias de exploração, mas não é uma mitigação completa e pode ter seus próprios riscos se não existir um limite de memória externo. Em hospedagem compartilhada, no final, estamos bastante nas mãos do provedor. As medidas temporais podem ajudar, mas o PHP deixa claro que a solução completa é atualizar para as versões corrigidas.

Daniel Muñoz · Ontem às 10:08

Tronlar disse:
Boa contribuição. Só faria uma ressalva sobre uma coisa do passo 3 pelo que o PHP indica no advisory oficial. Para session.upload_progress.enabled = 0, o PHP alerta que no PHP-FPM não se deve confiar no .user.ini como mitigação, porque essa configuração tem que ser aplicada antes do processamento da requisição. Recomendam fazê-lo a partir do php.ini, da configuração do pool de FPM ou da configuração do servidor e reiniciar os workers. Por isso, embora um check.php mostre session.upload_progress.enabled = 0, não confirma necessariamente que essa mitigação esteja atuando no momento necessário para bloquear essa vulnerabilidade. Também indicam que memory_limit = -1 reduz uma das vias de exploração, mas não é uma mitigação completa e pode ter seus próprios riscos se não existir um limite de memória externo. Em hospedagem compartilhada, no final, estamos bastante nas mãos do provedor. As medidas temporais podem ajudar, mas o PHP deixa claro que a solução completa é atualizar para as versões corrigidas.

Obrigado pela ressalva. É importante e corrijo o post. O ponto chave é este: com PHP-FPM, o .user.ini é aplicado tarde demais para esta vulnerabilidade. O upload multipart é processado antes de que essa configuração entre em jogo, então, embora o check.php diga session.upload_progress.enabled = 0, isso só confirma que o valor está definido quando seu script roda, não que estivesse ativo no momento do ataque. O check serve para ver que a diretiva não dá erro, nada mais. O mesmo com memory_limit = -1: fecha uma via, não todas. E sem um limite de memória externo (LVE/cgroups da hospedagem) você troca um risco por outro. Em resumo, para hospedagem compartilhada com FPM, o que realmente serve hoje é:

Mudar para a versão corrigida se seu painel já a oferece (verifiquem várias vezes ao dia).
Cloudflare / WAF na frente, que filtra antes que a requisição chegue ao PHP.
Pressionar o provedor para que coloque as mitigações em nível de servidor (php.ini ou pool de FPM) e reinicie os workers, enquanto compila o patch.

O .user.ini não faz mal se estiver limpo, mas não se deve contar com ele como proteção. Deixo um texto para o ticket, caso sua hospedagem não responda:

Inserir CODE, HTML ou PHP:

Asunto: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) - solicitud urgente

Mi cuenta sigue en PHP [VERSIÓN], sin el parche publicado el 21/10
(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).

Mientras compilan la versión corregida, solicito aplicar a nivel de
servidor o pool de FPM (no .user.ini) las mitigaciones del advisory
oficial de PHP:

- session.upload_progress.enabled = 0
- memory_limit = -1, con límite de memoria externo por cuenta
- fatal_error_backtraces = 0 (si es PHP 8.5)

y reiniciar los workers. Por favor indíquenme fecha estimada del parche.

E sim, no final, em compartilhada estamos nas mãos do provedor. Se o seu demora dias para reagir a algo de 9.2 com ataques ativos, isso também diz bastante sobre ele.

Tutorial: Como mitigar PHP2Shell (CVE-2026-109618 / 109619)

Daniel Muñoz

Tronlar

Daniel Muñoz

Tópicos similares