Em 21 de outubro de 2026 o projeto PHP publicou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 com a correção de duas falhas graves: CVE-2026-109618 e CVE-2026-109619, as duas com nota 9,2 (CVSS 4.0) e as duas permitindo execução remota de código sem login. O apelido que pegou foi PHP2Shell. Não é uma falha de um sistema feito em PHP. É uma falha no próprio PHP. Então não importa qual aplicação roda por cima: se o servidor atende requisições web com PHP, ele está no escopo.
Pra um provedor, isso começa no próprio NOC. O frontend do Zabbix é PHP. Webmail, sistema de chamados, phpIPAM, GLPI, painel de cliente e boa parte das ferramentas internas também costumam ser.
O que as duas falhas fazem
- CVE-2026-109618: quando o PHP fica sem memória no meio da preparação da requisição, ele para com dados internos montados pela metade. Depois, a limpeza da requisição trata esses dados como se fossem válidos. Um atacante que consegue provocar esse estouro de memória de propósito chega à execução de código.
- CVE-2026-109619: um estado interno da requisição continua apontando para uma memória que já foi liberada. Uma requisição seguinte, atendida pelo mesmo processo, pode usar esse lixo antes de ele ser zerado.
Segundo o próprio PHP, o risco vale para qualquer instalação que atende requisições web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O caso mais grave é o Apache com mod_php, onde o ataque demonstrado dispara numa requisição sem login, antes de qualquer linha da aplicação rodar. Não adianta a aplicação ter senha forte ou autenticação em dois fatores.
Já está sendo explorada
Os identificadores vazaram em 20 de outubro e o PHP antecipou a publicação. A Amazon relatou uma tentativa de exploração em 17 de outubro, quatro dias antes da correção, e ataques de vários grupos a partir do dia 21. A Unit 42 (Palo Alto) contou mais de 22,6 milhões de instâncias expostas e descreveu um ataque a um órgão de governo europeu: em duas horas, o invasor já tinha hashes de senha e segredos de MFA e tentava virar administrador do domínio. Há código de exploração circulando. Parte dele não foi verificada e pode até trazer malware, então não rode "PoC" achado na internet pra testar o seu servidor.
A Red Hat e a Rapid7 lembram que a exploração confiável depende de uma combinação específica de sistema, versão e servidor web. Isso não é motivo pra esperar. É só o motivo de nem todo servidor cair no primeiro ataque.
Onde isso encosta no provedor
| Onde costuma ter PHP | Por que preocupa |
|---|---|
| Frontend do Zabbix | Guarda credenciais de equipamento, scripts e acesso à rede de gerência |
| Webmail (Roundcube e similares) | Exposto pra internet por natureza |
| Chamados, wiki, phpIPAM, GLPI | Inventário e documentação da rede inteira |
| Painel do assinante, site institucional | Público, sempre alcançável |
O frontend do Zabbix merece atenção especial. Quem comprometer o servidor web do Zabbix fica a um passo do banco, das macros com community SNMP e senhas de equipamento, e de uma máquina que, por definição, enxerga toda a rede de gerência.
A versão do PHP costuma acompanhar a do sistema operacional. Debian 11 vem com PHP 7.4, Ubuntu 22.04 com 8.1, Debian 12 com 8.2, Ubuntu 24.04 com 8.3 e Debian 13 com 8.4. Os ramos 8.2 a 8.5 têm correção oficial. Do 8.1 para trás, o projeto PHP não lança versão nova: para 7.4, 8.0 e 8.1 há só um patch mínimo em código-fonte, e o resto depende da distribuição ou de um fornecedor de suporte estendido. Muito Zabbix 5.0 e 6.0 ainda roda em Debian 11 com mod_php 7.4, que é exatamente a pior combinação.
Como resolver: atualizar o PHP
Atualizar é a única correção completa, segundo o próprio PHP. As distribuições receberam o patch antes da divulgação, então, num sistema suportado, basta o pacote de segurança normal.
- Descubra a versão e como o PHP roda.
php -vmostra a versão.systemctl list-units | grep -E 'php.*fpm|apache2|httpd'mostra se é PHP-FPM ou Apache. No Apache,apache2ctl -M | grep phpacusa o mod_php, que é o caso mais grave. - Atualize pelo gerenciador de pacotes. No Debian e no Ubuntu:
apt update && apt install --only-upgrade 'php*'. No RHEL, Rocky e Alma:dnf upgrade 'php*'. Confira se a versão bate com a corrigida (8.5.12, 8.4.27, 8.3.36 ou 8.2.35) ou com o número que o boletim da sua distribuição informa para o pacote corrigido. - Reinicie o PHP de verdade.
systemctl restart php8.4-fpm(ajuste o número da versão) ousystemctl restart apache2. Processo antigo que continua em memória continua vulnerável, mesmo com o pacote novo instalado. - Confirme depois do reinício. Rode de novo
php -ve confira a data de início dos processos comps -o lstart= -C php-fpm8.4(ouapache2). Se algum processo começou antes da atualização, ele não foi reiniciado. - Repita em todo servidor com PHP, não só no do Zabbix (veja a última seção).
Paliativo: quando o sistema operacional não recebe mais atualização
É o caso clássico de Debian 10 ou 11 e Ubuntu 18.04 ou 20.04 sem suporte estendido, com PHP 7.x ou 8.0/8.1. Não vai sair pacote corrigido, então o objetivo passa a ser reduzir a superfície de ataque até migrar. Faça tudo o que couber, em camadas. Nenhuma delas sozinha resolve.
1. Fechar o acesso. É o que mais reduz o risco.
Se o atacante não alcança a página, a falha não é explorada. Frontend do Zabbix, phpIPAM e wiki interna não precisam estar abertos para a internet. Deixe-os acessíveis só pela VPN ou por uma lista de IPs de origem, no firewall (nftables/iptables) ou no próprio servidor web (Require ip no Apache, allow/deny no nginx). Para o que precisa ser público, como webmail e painel do assinante, siga os passos abaixo. A CISA recomenda tirar do ar o sistema em PHP que não puder ser corrigido nem protegido.
2. Desligar o caminho confirmado da CVE-2026-109619.
Num arquivo da configuração do servidor (no Debian, algo como /etc/php/7.4/apache2/conf.d/99-cve-2026-109619.ini, ou o equivalente em fpm/conf.d):
session.upload_progress.enabled = 0
No Apache com mod_php, dá para forçar no próprio VirtualHost com php_admin_flag session.upload_progress.enabled off. Não use ini_set() nem .user.ini: esses chegam tarde demais. No PHP 8.5, acrescente também fatal_error_backtraces = 0. Reinicie o Apache ou o FPM no final.
3. Dificultar o estouro de memória da CVE-2026-109618.
O PHP indica memory_limit = -1, aplicado com php_admin_value (no pool do FPM ou no Apache) para que a aplicação não volte a impor um limite finito. Junto com isso:
post_max_size = 8M ; 32M se o sistema precisar de upload
upload_max_filesize = 8M ; sempre menor que post_max_size
Sem limite de memória no PHP, quem segura o consumo passa a ser o sistema: use limite de cgroup no serviço (por exemplo MemoryMax= num override do systemd para o php-fpm ou o apache2). Não use RLIMIT_AS ou RLIMIT_DATA (ulimit -v), porque eles provocam justamente a falha de alocação vulnerável.
4. Barrar requisição anormal antes de ela chegar ao PHP.
Limite no servidor web ou no proxy da frente o tamanho do corpo e dos cabeçalhos, o número de campos e de partes multipart, inclusive quando a requisição chega sem Content-Length. No nginx: client_max_body_size, large_client_header_buffers, client_header_buffer_size. No Apache: LimitRequestBody, LimitRequestFields, LimitRequestFieldSize. Se o site passa pela Cloudflare, as regras de WAF dela para essa falha ajudam, mas só protegem o tráfego que passa por ela. Quem acessa o IP de origem direto não passa por esse filtro.
5. Tirar o frontend do PHP velho sem mexer no sistema operacional.
Para o Zabbix, um caminho rápido é rodar o frontend na imagem oficial em contêiner (zabbix/zabbix-web-nginx-pgsql ou -mysql, na mesma versão do seu servidor Zabbix), que já vem com PHP atual, apontando para o mesmo banco. O Apache e o PHP antigos saem do ar e o servidor Zabbix continua como está. Depois de validar, desative o mod_php antigo (a2dismod php7.4 && systemctl restart apache2) para ele não ficar esquecido escutando.
6. Ter um caminho de correção, mesmo que demorado. Para PHP 7.4, 8.0 e 8.1, o PHP publicou um patch mínimo no código-fonte. Compilar o PHP na mão em produção é trabalhoso e fica fora do gerenciador de pacotes. Outras opções são um fornecedor de suporte estendido (por exemplo, o ELTS da Freexian para Debian antigo, ou o Ubuntu Pro). O conserto de verdade é migrar para um sistema operacional suportado. PHP 7.4 em Debian 11 vai continuar aparecendo a cada falha nova.
7. Vigiar enquanto não corrige.
Monitore no Zabbix os processos e o consumo de memória do PHP, erros 500 em sequência e workers morrendo no log. Procure também arquivo .php novo em diretório de upload e conexões de saída inesperadas a partir do servidor web. Comprometimento costuma aparecer primeiro aí.
Achar todos os servidores, não só os que você lembra
O difícil aqui é o mesmo de todo alerta grave: ter certeza de que nenhum servidor ficou para trás. O servidor do Zabbix vem à cabeça na hora. A VM antiga do webmail, o painel de um POP e o servidor de teste que ficou com IP público, nem sempre.
O próprio Zabbix ajuda nisso. Um item no agente com a versão instalada do pacote PHP (dpkg-query ou rpm -q), ou o inventory do host, transforma a pergunta "quem ainda está vulnerável?" numa lista com um trigger, em vez de uma caça manual por SSH.
Se o seu ambiente ainda não responde rápido onde roda PHP e em qual versão, vale fechar essa lacuna agora, antes da próxima falha. Fale com a gente ou veja como o NOC Geomap ajuda a visualizar a sua infraestrutura no mapa.
Fontes: PHP.net — avisos de segurança de outubro de 2026, Unit 42 — Threat Brief: CVE-2026-109618 e CVE-2026-109619, Tenable — perguntas frequentes sobre o php2shell e Red Hat — CVE-2026-109618.