PHP2Shell (CVE-2026-109618 e CVE-2026-109619): o que Aconteceu, Como Corrigir e Monitorar com Zabbix

Uma das linguagens mais usadas da web entrou em alerta máximo em outubro de 2026. Em 21 de outubro, o projeto PHP publicou versões de emergência para corrigir duas falhas críticas que permitem a um atacante executar código no servidor com uma única requisição, sem login. O caso ganhou o apelido de PHP2Shell e mobilizou equipes de segurança no mundo todo, porque o PHP está por trás de cerca de 7 em cada 10 sites com linguagem de servidor conhecida, incluindo WordPress, sistemas de gestão, portais de clientes e painéis de hospedagem.

Se a sua empresa mantém sites, sistemas web ou painéis internos em PHP, este artigo explica o que aconteceu, quem está exposto e, principalmente, o passo a passo para corrigir e monitorar.

O que aconteceu: a cronologia do PHP2Shell

As falhas foram encontradas em agosto de 2026, durante uma auditoria do código-fonte do PHP feita pelo pesquisador Ryan Austin, da Calif. A empresa de segurança Wiz chegou de forma independente aos mesmos problemas e cunhou o nome PHP2Shell, em referência à possibilidade de obter um shell (terminal) no servidor atacado (Wikipedia).

A divulgação estava planejada para 22 de outubro, mas detalhes vazaram nas redes sociais no dia 20, e o projeto PHP antecipou as correções para o dia 21 (anúncio oficial do PHP). Antes disso, a Amazon já havia registrado, em 17 de outubro, uma tentativa de exploração em sua rede de iscas (honeypots). Cloudflare e watchTowr também relataram tentativas de exploração logo após a divulgação.

Em 26 de outubro, a agência americana de cibersegurança CISA adicionou as duas falhas ao catálogo KEV (Known Exploited Vulnerabilities), reservado a vulnerabilidades com evidência de exploração real, e deu prazo até 29 de outubro para que órgãos federais dos EUA corrigissem seus sistemas (alerta da CISA).

Fonte: CERT-EU, CISA, W3Techs, via Wikipedia.

Entendendo as falhas (sem complicar)

As duas vulnerabilidades exploram a forma como o PHP limpa a memória entre uma requisição e outra:

• CVE-2026-109618 – corrupção de memória ao estourar o limite. Quando uma requisição ultrapassa o memory_limit, o PHP interrompe o processamento de forma abrupta. Se isso acontece no meio do tratamento de um envio de formulário com arquivos (multipart), a limpeza posterior pode liberar memória que nunca foi inicializada e que ainda contém dados controlados pelo atacante (aviso GHSA-w8hw-w9fx-j79w).
• CVE-2026-109619 – “estado velho” entre requisições (use-after-free). Após certos erros fatais, informações internas de uma requisição sobrevivem mesmo depois de a memória correspondente ter sido liberada. A requisição seguinte atendida pelo mesmo processo pode reutilizar esse estado antes de ele ser reiniciado (aviso GHSA-6wmf-4rv5-p3rp).

Na prática, um atacante envia requisições preparadas para forçar essas condições e transformar o erro de memória em execução de código. O CERT da União Europeia destaca que apenas a atualização corrige o problema; as configurações alternativas só reduzem a exposição (aviso do CERT-EU).

Quem está exposto

Fonte: CERT-EU, Rapid7.

Os cenários afetados são todos os que atendem requisições web: PHP-FPM (o mais comum com Nginx), Apache com mod_php (considerado o de maior risco), php-cgi, FrankenPHP e LiteSpeed. Softwares que trazem o PHP embutido, como painéis de hospedagem e aplicações instaladas em servidores Windows, também precisam ser verificados; o NCSC da Holanda mantém uma lista pública de produtos afetados.

Atenção redobrada para

Tutorial: como verificar e corrigir seus servidores

O roteiro abaixo segue as recomendações da CISA e do CERT-EU: inventariar, atualizar começando pelo que está exposto à internet, reiniciar todos os processos do PHP e verificar. Faça backup e, se possível, teste em homologação antes.

1. Descubra onde e como o PHP está rodando

No servidor Linux (SSH):

# versão do PHP da linha de comando
php -v

# serviços do PHP em execução (PHP-FPM) e servidor web
systemctl list-units --type=service | grep -Ei 'php|apache2|httpd|nginx|lsws'

# o Apache está usando mod_php?
apache2ctl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php          # RHEL/Alma/Rocky

# versões instaladas (Debian/Ubuntu)
ls /etc/php/

Atenção: a versão do php -v (linha de comando) pode ser diferente da usada pelo site. Confira também o binário do FPM, por exemplo php-fpm8.3 -v.

2. Atualize o PHP

Debian e Ubuntu:

sudo apt update && sudo apt upgrade
# confirme que o pacote da sua distribuição já traz a correção:
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]' 

RHEL, AlmaLinux, Rocky:

sudo dnf upgrade --refresh 'php*'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]' 

Contêineres Docker com a imagem oficial:

docker pull php:8.3-fpm
docker run --rm php:8.3-fpm php -v     # deve mostrar 8.3.36 ou superior
# depois, recrie os contêineres que usam a imagem

Distribuições como Debian, Ubuntu e Red Hat costumam aplicar a correção sem mudar o número da versão (por exemplo, continua aparecendo 8.2.x), por isso o changelog do pacote é a melhor prova. Quem usa o repositório Remi deve conferir se o pacote corrigido já está disponível, pois o CERT-EU apontou atraso no dia do lançamento. Em hospedagem compartilhada ou cPanel, confirme com o provedor e selecione no painel uma versão corrigida.

3. Reinicie todos os processos do PHP

sudo systemctl restart php8.3-fpm      # ajuste para a sua versão
sudo systemctl restart apache2         # se usar mod_php (httpd no RHEL)
sudo systemctl restart lsws            # se usar LiteSpeed

Os avisos oficiais insistem: é preciso reiniciar (não apenas recarregar) para que nenhum processo antigo continue em memória.

4. Sem como atualizar agora? Aplique mitigações temporárias

Se a atualização depende de janela de manutenção, o PHP e o CERT-EU indicam configurações que reduzem a exposição, mas não corrigem as falhas. Elas devem ser aplicadas no pool do FPM ou na configuração do servidor (não via ini_set() nem .user.ini), seguidas de reinício:

PHP-FPM:

; /etc/php/8.3/fpm/pool.d/www.conf  (no pool do PHP-FPM)
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 32M          ; 8M se o site não recebe uploads
php_admin_value[upload_max_filesize] = 30M    ; sempre menor que post_max_size
; somente PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off

No servidor web:

# Nginx: limite o tamanho das requisições
client_max_body_size 32m;

# Apache: limite o corpo das requisições (32 MB)
LimitRequestBody 33554432

Para conferir o que o FPM carregou:

php-fpm8.3 -tt 2>&1 | grep -E 'upload_progress|post_max_size|fatal_error_backtraces' 

O aviso do CERT-EU também cita memory_limit=-1 (definido administrativamente) para a CVE-2026-109618. Use só com um limite de memória no contêiner ou cgroup, para que um processo não derrube o servidor. Não use RLIMIT_AS ou RLIMIT_DATA, que podem acionar justamente o caminho vulnerável. Um WAF pode ajudar enquanto a correção não é aplicada (CERT-EU).

5. Procure sinais de comprometimento

Não existe uma lista definitiva de indicadores, e a ausência de registros não prova que o servidor está limpo. A CISA recomenda vigiar processos do PHP abrindo terminais ou baixando ferramentas. Comece por:

# travamentos do PHP-FPM (sinal de tentativa de exploração de memória)
journalctl -u php8.3-fpm --since "2026-10-17" | grep -E 'SIGSEGV|exited on signal'

# travamentos de processos do Apache (mod_php)
grep -E 'exit signal Segmentation fault' /var/log/apache2/error.log*

# processos rodando como o usuário do site (procure sh, bash, curl, wget)
ps -u www-data -o pid,ppid,etime,cmd

# arquivos PHP alterados nos últimos 14 dias dentro do site
find /var/www -name '*.php' -mtime -14 -ls

Se encontrar algo suspeito, siga um plano de resposta a incidentes: isole o servidor, preserve evidências e avalie a comunicação à ANPD caso haja dados pessoais envolvidos. Veja também o que fazer nas primeiras 24 horas após uma invasão.

Monitorando o processo com Zabbix

Corrigir é o primeiro passo; garantir que nenhum servidor fique para trás e perceber rápido qualquer comportamento estranho é o segundo. É aqui que entra o Zabbix, plataforma open source de monitoramento usada por empresas e provedores de internet no mundo todo. Com um agente instalado em cada servidor, ele coleta métricas, lê logs, verifica processos e dispara alertas quando algo sai do esperado.

A seguir, três verificações práticas para o PHP2Shell. Elas usam o Zabbix Agent 2 e funcionam nas versões atuais do Zabbix (como a 7.0 LTS).

Verificação 1: o servidor ainda está em uma versão vulnerável?

Crie o arquivo de parâmetros no servidor monitorado:

# /etc/zabbix/zabbix_agent2.d/php2shell.conf
UserParameter=php.version,php -r 'echo PHP_VERSION;'
UserParameter=php.php2shell.vulneravel,php -r '$v=PHP_VERSION_ID; $m=intdiv($v,100); $f=[802=>80235,803=>80336,804=>80427,805=>80512]; echo $m<802 ? 1 : ($m>805 ? 0 : (int)($v<$f[$m]));' 

Reinicie o agente e teste:

sudo systemctl restart zabbix-agent2
zabbix_agent2 -t php.php2shell.vulneravel     # 1 = vulnerável, 0 = corrigido

No Zabbix, crie o item php.php2shell.vulneravel no host (ou em um template) e um gatilho de severidade alta com a expressão last(/Servidor Web/php.php2shell.vulneravel)=1. Assim, qualquer servidor ainda vulnerável aparece no painel e gera alerta (documentação de UserParameters).

Em distribuições que corrigem sem mudar o número da versão (Debian, Ubuntu, Red Hat), essa verificação pode acusar falso positivo. Nesses casos, troque a lógica por uma checagem do changelog do pacote, por exemplo: UserParameter=php.php2shell.patch_debian,zgrep -c -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-common/changelog.Debian.gz (resultado maior que zero indica pacote corrigido).

Verificação 2: o PHP-FPM está travando?

Tentativas de exploração tendem a derrubar processos do PHP. Um item de log do Zabbix conta essas ocorrências (documentação das chaves do agente, como log[] e proc.num[]):

Tipo do item:  Zabbix agent (active)
Chave:         log[/var/log/php8.3-fpm.log,"exited on signal",,,skip]
Gatilho:       count(/Servidor Web/log[/var/log/php8.3-fpm.log,"exited on signal",,,skip],10m)>3

# o agente precisa ler o log:
sudo usermod -aG adm zabbix && sudo systemctl restart zabbix-agent2

Para acompanhar a saúde do FPM (processos ativos, fila e requisições lentas), use o template oficial PHP-FPM do Zabbix, habilitando a página de status (pm.status_path) no pool.

Verificação 3: o usuário do site está abrindo terminais ou baixando ferramentas?

Itens do tipo Zabbix agent (ajuste o usuário: www-data, apache ou nginx):

Chaves:   proc.num[sh,www-data]   proc.num[bash,www-data]
          proc.num[wget,www-data] proc.num[curl,www-data]
Gatilho:  last(/Servidor Web/proc.num[sh,www-data])>0

Esse é exatamente o comportamento que a CISA pede para vigiar. Ajuste exceções se alguma aplicação legítima executa comandos do sistema.

Resumo do que monitorar

Fonte: Documentação do Zabbix.

Próximo passo: do alerta à ação com GLPI e Grafana

Um alerta só gera resultado quando alguém age sobre ele. Por isso, este artigo abre uma série: no próximo, vamos mostrar o Zabbix na prática, da instalação aos templates, e como integrá-lo a duas ferramentas que fecham o ciclo (veja todos os artigos da série Monitoramento):

• GLPI: cada problema detectado pelo Zabbix vira um chamado automaticamente, vinculado ao ativo (o servidor) e ao responsável, e é encerrado quando o problema se resolve.
• Grafana: painéis para a gestão acompanharem servidores corrigidos, alertas por severidade e tempo de resposta, sem precisar entrar no Zabbix.

Leia também

• Vulnerabilidades críticas em aplicativos: o que marcou 2021 a 2023
• Como proteger seu site WordPress: comandos e permissões
• Help desk em TI: guia de implantação e gestão
• Serviços de cibersegurança: MSSP, SOC, pentest e mais

A Alliances aplica as correções e monitora seu ambiente

Incidentes como o PHP2Shell mostram que não basta corrigir uma vez: é preciso saber, a qualquer momento, quais servidores estão expostos, o que mudou e quem está cuidando. A Alliances atua exatamente nessa frente:

• Correção emergencial do PHP2Shell: inventário, atualização, mitigações e verificação de sinais de comprometimento em servidores Linux, Windows, contêineres e hospedagens.
• Implantação de Zabbix + GLPI + Grafana: monitoramento de servidores, links, equipamentos de rede e aplicações; abertura automática de chamados no GLPI; e painéis executivos no Grafana.
• Para provedores de internet: monitoramento de links, concentradores, OLTs, roteadores e sistemas web do provedor, com alertas antes que o assinante perceba.
• Para empresas com TI interna: apoio ao time de TI com monitoramento 24×7, resposta a incidentes e gestão de chamados, sem precisar montar tudo do zero.

Fale com a Alliances e peça um diagnóstico do seu ambiente. Conheça também nossos serviços de segurança cibernética e de TI gerenciada.

Fonte: PHP – anúncio oficial, CISA – alerta e catálogo KEV, CERT-EU – aviso 2026-018, Rapid7, NCSC-NL – php2shell, GitHub – GHSA-w8hw-w9fx-j79w, GitHub – GHSA-6wmf-4rv5-p3rp, Wikipedia – PHP2Shell.

Perguntas Frequentes

O que é o PHP2Shell?

É o nome dado às vulnerabilidades CVE-2026-109618 e CVE-2026-109619 do PHP, divulgadas em outubro de 2026, que permitem executar código remotamente no servidor sem autenticação.

Quais versões do PHP corrigem o PHP2Shell?

PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Para 8.1, 8.0 e 7.4, o PHP publicou apenas correções de código-fonte; o recomendado é migrar para uma versão suportada ou usar pacotes do fornecedor da distribuição.

Meu site WordPress está vulnerável?

Depende da versão do PHP do servidor, e não do WordPress. Verifique a versão no painel da hospedagem ou com o comando php -v e atualize para uma versão corrigida.

Mudar configurações do php.ini resolve?

Não completamente. Desativar session.upload_progress e limitar o tamanho das requisições reduz a exposição, mas segundo o PHP e o CERT-EU só a atualização corrige as falhas.

As falhas estão sendo exploradas?

Sim. Houve tentativas desde 17 de outubro de 2026, e a CISA incluiu as falhas no catálogo de vulnerabilidades exploradas ativamente (KEV) em 26 de outubro.

Como o Zabbix ajuda nesse caso?

Com um item que indica se cada servidor ainda roda uma versão vulnerável, alertas para travamentos do PHP-FPM e detecção de shells ou downloads executados pelo usuário do site.