Resumo executivo

Informações sobre duas vulnerabilidades de execução remota de código (RCE) no PHP, identificadas como CVE-2026-109618 e CVE-2026-109619, vazaram antes do fim do embargo de divulgação coordenada. Em publicação no X, a watchTowr afirmou que as falhas são reais, mas disse não poder compartilhar mais detalhes e orientou a aplicação dos patches assim que disponíveis.^[1]

O FAQ publicado pela própria watchTowr é cauteloso: trata o escopo divulgado como baseado em relato não verificado e afirma não haver, até o momento, advisory oficial, causa-raiz descrita, versão corrigida ou workaround validado.^[2] Os registros CVE seguem em status reservado, sem descrição ou pontuação.^[3]

Mesmo com essas incertezas, a quebra do embargo encurta a janela entre o conhecimento público da falha e a disponibilidade do patch. Organizações que operam PHP devem tratar o tema como crítico: fazer inventário imediato, reduzir exposição e preparar atualização emergencial para o dia da divulgação.

Ficha técnica

Como o vazamento ocorreu

Em 20 de outubro, um usuário do Hacker News publicou, citando uma “fonte confiável”, que um anúncio sobre duas RCEs no PHP com CVSS 10.0 estava agendado para 22 de outubro às 18h CEST e que as falhas afetariam todas as versões a partir do PHP 5. O próprio autor admitiu não ter evidências. O post foi sinalizado e removido, mas capturas de tela já circulavam no X e no Mastodon.^[3]

Horas depois, pesquisadores com acesso ao embargo reagiram publicamente. A watchTowr confirmou a existência das falhas^[1] e Florian Roth afirmou que se trata de RCE no núcleo do PHP e que apenas o PHP 8 receberá correções.^[4] Nenhuma das publicações identificou a função, extensão ou configuração vulnerável.^[3]

O embargo existe justamente para que distribuições Linux, provedores de hospedagem e fornecedores de segurança preparem pacotes corrigidos antes do anúncio. Com data e severidade públicas, quem eventualmente já conhece as falhas sabe exatamente quanto tempo tem até a chegada dos patches.^[3]

Risco e impacto

Uma RCE no interpretador PHP pode permitir que um atacante execute código arbitrário no servidor que hospeda a aplicação. Em cenários típicos, isso pode resultar em:

• comprometimento de aplicações web, APIs, painéis administrativos e serviços expostos;
• execução de comandos com os privilégios do serviço PHP ou do usuário do servidor web;
• instalação de webshells, roubo de credenciais e acesso a bancos de dados;
• movimentação lateral para outros sistemas da rede interna;
• persistência e uso do servidor como base para ataques adicionais.

Como o PHP sustenta WordPress, Drupal, Magento e a maior parte da hospedagem compartilhada, uma falha remota no núcleo alcança uma fração muito grande da web.^[3] O risco é particularmente relevante para hospedagens compartilhadas, ambientes multitenant, aplicações legadas e servidores com PHP exposto à Internet. Não há confirmação pública de exploração ativa, mas a ausência de evidência não deve ser lida como ausência de risco.

Escopo e versões

O post vazado afirma que as falhas afetam todas as versões a partir do PHP 5, mas o autor não apresentou evidências e o escopo não foi confirmado pelo PHP Group.^[2][3] Segundo Florian Roth, apenas os ramos do PHP 8 receberão correções.^[4]

Atenção a pacotes de distribuição: Debian, Ubuntu, Red Hat e derivados mantêm pacotes próprios de ramos antigos do PHP e podem publicar correções por backport, independentemente do PHP Group. Quem depende do PHP do sistema operacional deve acompanhar o security tracker da sua distribuição.^[8][9][10] Ambientes em ramos sem suporte e sem backport exigem migração ou contenção imediata.

Ações recomendadas

Ações imediatas

1. Inventariar todos os componentes PHP em produção: servidores web, PHP-FPM, CLI, cron jobs, workers, containers, imagens de sistema e runtimes empacotados por aplicações.
2. Identificar versões exatas, distinguindo PHP do sistema operacional, PHP compilado manualmente e PHP dentro de imagens de container.
3. Priorizar sistemas expostos à Internet, especialmente aplicações web, APIs, painéis administrativos, WordPress e hospedagem.
4. Preparar janela de emergência para 22/10, com homologação, plano de rollback e responsáveis definidos. Quem depende de provedor de hospedagem deve confirmar com ele o prazo de atualização.
5. Acompanhar o advisory oficial nos canais do PHP^[6] e da sua distribuição para obter a lista definitiva de versões afetadas e corrigidas.

Inventário de versões (Linux)

# Versão e SAPI do PHP padrão do sistema
php -v
php -i | grep -E "^(PHP Version|Server API|Loaded Configuration File)"

# Pacotes instalados — Debian/Ubuntu
dpkg -l | grep -E '^ii\s+(php|libapache2-mod-php)'

# Pacotes instalados — RHEL/AlmaLinux/Rocky
rpm -qa | grep -i php

# Binários PHP fora do gerenciador de pacotes (compilações manuais, múltiplas versões)
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' \) -perm -u+x 2>/dev/null

# Processos PHP-FPM/CGI em execução
ps -eo pid,user,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep

# Versão do PHP dentro de containers em execução
docker ps --format '{{.ID}} {{.Image}}' | while read id img; do
  echo "$img: $(docker exec "$id" php -r 'echo PHP_VERSION;' 2>/dev/null)"
done

Medidas de contenção

Como o vetor de ataque não foi divulgado, nenhuma regra de WAF ou configuração específica pode ser considerada mitigação efetiva. As medidas abaixo são de redução de superfície e de impacto:

• restringir acesso a áreas administrativas e endpoints sensíveis por VPN, lista de permissões ou autenticação multifator;
• revisar regras de WAF e limitar requisições anômalas a aplicações PHP, sabendo que não há assinatura específica para estas falhas;
• segmentar servidores web de bancos de dados, serviços internos e estações administrativas;
• restringir conexões de saída a partir de servidores web ao estritamente necessário;
• revisar permissões de arquivos e diretórios, impedindo que o usuário do serviço web grave ou execute código em locais sensíveis;
• desabilitar funcionalidades desnecessárias, como execução de PHP em diretórios de upload.

Detecção e monitoramento

Recomenda-se elevar a atenção a indícios de comprometimento, como processos filhos incomuns originados de php-fpm, php-cgi, apache ou nginx; execução de comandos do sistema pelo usuário do serviço web; criação ou alteração inesperada de arquivos .php, sobretudo em diretórios de upload, cache ou temporários; conexões de saída anômalas; download de binários ou tentativas de escalada de privilégios; e alterações em configurações, cron, serviços e chaves SSH.

Comandos de verificação

# Árvore de processos: shells ou utilitários sob o PHP/servidor web são suspeitos
ps -eo pid,ppid,user,cmd --forest | grep -E -A3 'php-fpm|php-cgi|apache2|httpd|nginx'

# Arquivos .php criados ou alterados nas últimas 72 horas nos web roots
find /var/www /srv /home -xdev -type f -name '*.php' -mtime -3 -ls 2>/dev/null

# Arquivos .php em diretórios temporários (não deveriam existir)
find /tmp /var/tmp /dev/shm -xdev -type f -name '*.php' -ls 2>/dev/null

# Arquivos .php em diretórios de upload/cache
find /var/www -xdev -type f -name '*.php' \( -path '*upload*' -o -path '*cache*' \) -ls 2>/dev/null

# Conexões estabelecidas por processos do PHP/servidor web
ss -tnp state established | grep -E 'php-fpm|php-cgi|apache2|httpd|nginx'

# Crontab dos usuários de serviço web (ajuste ao seu ambiente)
for u in www-data apache nginx; do echo "== $u"; crontab -l -u "$u" 2>/dev/null; done

# Chaves SSH alteradas recentemente
find / -xdev -name authorized_keys -mtime -3 -ls 2>/dev/null

# Opcional (auditd): registrar execve feitos pelo usuário web (UID 33 = www-data no Debian/Ubuntu)
auditctl -a always,exit -F arch=b64 -S execve -F uid=33 -k web_exec

Indicadores de comprometimento (IOCs)

Até o fechamento deste alerta, não há IOCs públicos (hashes, endereços IP, domínios de C2 ou padrões de requisição) associados a estas vulnerabilidades. Esta seção será atualizada caso surjam indicadores confiáveis após a divulgação oficial.

Orientação sobre CVSS e PoCs

A nota CVSS 10.0 tem origem no post vazado e em comentários de pesquisadores; o valor CVSS v4.0 9.2 que circula em fontes secundárias não tem origem primária identificada. Como os registros CVE estão reservados e o advisory não foi publicado, nenhuma das notas é oficial.^[2][3]

O Diário do Analista recomenda não buscar, distribuir ou testar PoCs não verificados em ambientes de produção. A prioridade é inventário, contenção, monitoramento e aplicação da correção oficial assim que disponível.

Conclusão

Trata-se de um alerta crítico, porém preliminar. A existência das vulnerabilidades foi afirmada por uma fonte de segurança reputada, mas escopo, causa-raiz, severidade oficial e correções ainda não foram publicados. A quebra do embargo torna o dia 22 de outubro decisivo: organizações que utilizam PHP devem chegar a essa data com inventário concluído, exposição reduzida, monitoramento reforçado e processo de atualização pronto para execução.

Referências

1. watchTowr. Post no X sobre o vazamento das vulnerabilidades no PHP, 20/10/2026. https://x.com/watchtowrcyber/status/2112611507749982605
2. watchTowr. Frequently Asked Questions About PHP Remote Code Execution (CVE-2026-109618 & CVE-2026-109619), 20/10/2026. https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
3. Cyber Kendra. PHP RCE Zero-Days CVE-2026-109618, CVE-2026-109619 Leak Early, 21/10/2026. https://www.cyberkendra.com/2026/10/php-cve-2026-109618-cve-2026-109619-rce.html
4. Florian Roth. Post no X sobre as vulnerabilidades no núcleo do PHP, 20/10/2026. https://x.com/cyb3rops/status/2112616479061667936
5. Hacker News. Post “Tell HN” original (removido). https://news.ycombinator.com/item?id=50167754
6. PHP. Security advisories do repositório php-src. https://github.com/php/php-src/security/advisories
7. PHP. Supported Versions. https://www.php.net/supported-versions.php
8. Debian Security Tracker. CVE-2026-109618 · CVE-2026-109619
9. Ubuntu Security. CVE-2026-109618 · CVE-2026-109619
10. Red Hat Customer Portal. CVE-2026-109618 · CVE-2026-109619
11. CVE.org. Registros CVE-2026-109618 e CVE-2026-109619 · NVD: CVE-2026-109618 · CISA KEV: catálogo