Falhas críticas do PHP:
o que conferir nos seus servidores hoje.

Atualizar o PHP do sistema que o time conhece é a parte fácil. A falha fica aberta no PHP que a equipe esqueceu que existe: a intranet antiga, o portal do fornecedor, o site que o marketing contratou, o painel web de um equipamento. Por isso o inventário começa pelos endereços, e só depois vai pros servidores.

Endereços

Peça a lista de domínios e subdomínios pra quem cuida do DNS. Cada nome aponta pra um sistema, e cada sistema precisa de alguém que responda por ele. O cabeçalho X-Powered-By às vezes entrega o PHP e a versão, mas costuma estar escondido: se ele não aparecer, o sistema ainda pode rodar PHP.

curl -sI https://intranet.suaempresa.com.br | grep -i x-powered-by

Servidores Linux

Liste os pacotes de PHP instalados, os binários de PHP que existem no disco e os processos que rodam PHP. Servidor com painel de hospedagem costuma ter várias versões lado a lado, e cada site pode usar uma: anote todas.

dpkg -l 'php*' | grep ^ii        # Debian e Ubuntu
rpm -qa 'php*'                   # Red Hat, Alma, Rocky
ls -d /usr/bin/php[0-9]* /opt/plesk/php/*/bin/php /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php 2>/dev/null
ps -eo pid,user,args | grep -E 'php|httpd|apache2|lsphp' | grep -v grep

Windows com IIS

Procure os php-cgi.exe do servidor e veja qual deles o IIS chama no mapeamento de handler do FastCGI. Cada pasta é uma instalação.

where /r C:\ php-cgi.exe
"C:\caminho\do\php\php-cgi.exe" -v

Containers

Toda imagem que tem PHP dentro conta, mesmo quando o nome dela não diz php. Pergunte a versão pra cada container que está rodando. No Kubernetes, a mesma pergunta vale pra cada imagem que o cluster roda.

docker ps --format '{{.Names}}  {{.Image}}'
docker exec NOME_DO_CONTAINER php -v || docker exec NOME_DO_CONTAINER php-fpm -v

Equipamentos

Firewall, storage, central telefônica e outros equipamentos com painel de administração web podem trazer PHP embutido. O pfSense é o caso mais comum, e tem seção própria mais abaixo. Pros outros, quem diz se o seu é afetado é o fabricante: procure o aviso dele pelas duas CVEs. O NCSC da Holanda mantém uma lista pública do status de cada produto. Em 23/10 ela mostrava correção pro pfSense, o OPNsense e os pacotes de PHP do Synology, e o PHP embutido do QNAP QTS ainda como vulnerável.

Sistemas prontos

Nextcloud, GLPI, Moodle, Roundcube, phpMyAdmin e WordPress rodam sobre o PHP do servidor, e o que corrige é atualizar esse PHP. Quando o sistema vem em container, quem corrige é a imagem: o Nextcloud AIO trouxe o PHP corrigido na versão 14.4.1, e o GLPI reconstruiu as imagens Docker oficiais.

PHP de terceiros

Na hospedagem do site, no portal do fornecedor e no sistema que uma software house mantém pra vocês, o PHP é de outra empresa. Peça por escrito qual versão roda e se a correção das duas CVEs já foi aplicada. Atualizar WordPress, Joomla, Drupal, Moodle, tema ou plugin não corrige a falha, porque ela está no PHP que roda por baixo.

Feche o inventário numa tabela simples: sistema, onde roda, versão do PHP, de onde vem esse PHP, quem responde por ele e se fica exposto pra internet.

Dois servidores com PHP 8.3 podem precisar de duas correções diferentes. Se o PHP veio do Ubuntu, a correção vem do Ubuntu. Se veio do painel de hospedagem, vem do painel. Atualizar por outro caminho costuma instalar um segundo PHP do lado, e o site continua no primeiro.

Pra saber se o PHP que serve o site veio de pacote, pergunte ao gerenciador de pacotes quem é o dono do binário do PHP-FPM (o passo 3 mostra como achar o PID dele). Se nenhum pacote for dono, alguém compilou ou copiou esse PHP à mão.

dpkg -S "$(sudo readlink -f /proc/PID/exe)"     # Debian e Ubuntu
rpm -qf "$(sudo readlink -f /proc/PID/exe)"     # Red Hat, Alma, Rocky
apt-cache policy php8.3-fpm                     # mostra de qual repositório o pacote veio

O php -v mostra o PHP da linha de comando. As páginas são servidas pelo PHP-FPM ou pelo mod_php, que vêm de outro pacote e às vezes de outra versão. E no Ubuntu e em parte do Red Hat o pacote corrigido continua mostrando o número antigo: um servidor corrigido pode aparecer como 8.1.2 ou 8.3.6.

Qual PHP serve o site

Ache o processo principal do PHP-FPM e veja qual binário ele roda. No mod_php, veja se o Apache carrega o módulo.

ps -eo pid,lstart,args | grep 'php-fpm: master' | grep -v grep
sudo readlink /proc/PID/exe          # ex.: /usr/sbin/php-fpm8.3. Se terminar em (deleted), ainda roda o binário antigo
apache2ctl -M | grep -i php          # httpd -M no Red Hat, Alma, Rocky

Debian e Ubuntu

Veja a versão instalada e de qual repositório ela veio. Depois compare com a versão corrigida da mesma origem: um pacote vulnerável do Surý, como o 8.3.35, passa por corrigido se você comparar com o número do Ubuntu, que é 8.3.6. O apt changelog mostra o histórico da versão instalada e confirma se ela cita as duas CVEs.

dpkg-query -W -f='${Package} ${Version}\n' 'php*-fpm' 'php*-cli' 'libapache2-mod-php*'
apt-cache policy php8.3-fpm                 # de qual repositório veio
FIX=8.3.6-0ubuntu0.24.04.13                 # versão corrigida da MESMA origem (Surý: 8.3.36-1)
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.3-fpm)" ge "$FIX" \
  && echo corrigido || echo PENDENTE
apt changelog php8.3-fpm 2>/dev/null | grep -m2 -E 'CVE-2026-10961(8|9)'

Red Hat, Alma, Rocky

Compare a versão instalada com a do aviso RHSA, ALSA ou RLSA da tabela abaixo. O dnf updateinfo lista as correções disponíveis que ainda não foram instaladas: se ele devolver o aviso, o servidor está pendente. Lista vazia não prova correção, porque o Remi e a CloudLinux não publicam esse aviso e o módulo php:8.4 do RHEL 9 ainda não tinha correção.

rpm -q php-fpm php-cli
sudo dnf updateinfo list --cve CVE-2026-109618

CloudLinux

No alt-php e no ea-php, confira pelo changelog. No PHP nativo do CloudLinux 8, 9 e 10, o changelog não cita a CVE: ali a conferência é pela versão, que precisa ser 8.2.35 ou 8.3.36 ou mais nova.

rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'

Alpine

O Alpine usa o número do projeto. Compare com a tabela.

apk list -I 'php*'

Versão corrigida por origem, lida em 23/10/2026

Sistema operacional fora de suporte, como CentOS 7 ou Debian 11, não aparece nessa tabela porque não recebe correção gratuita: veja o passo 5. Se o seu fluxo do Red Hat não está aqui, confira a página da CVE na Red Hat, que ainda estava sendo atualizada em 23/10.

Na maioria dos servidores não precisa reiniciar o sistema operacional. Basta reiniciar os serviços que rodam PHP, e a parada costuma ser de segundos.

Depois, confirme que nenhum processo ficou com a versão antiga. No Debian e no Ubuntu, o needrestart lista o que ainda usa biblioteca velha. No Red Hat e derivados, o dnf needs-restarting faz o mesmo.

sudo needrestart -r l                  # Debian e Ubuntu: só lista, não reinicia
sudo dnf needs-restarting -s           # Red Hat, Alma, Rocky

Nada aqui substitui a atualização. O php.net diz que as medidas abaixo reduzem a exposição a caminhos de ataque conhecidos, mas não deixam a instalação segura. Quando a correção entrar, desfaça as que atrapalham a aplicação, menos o progresso de upload desligado, que o php.net sugere manter até a próxima versão.

Fechar o acesso

Tire da internet o que não precisa estar lá: webGUI do pfSense, Zabbix, painel de hospedagem, sistema interno. Deixe o acesso só por VPN ou por endereços autorizados. O CTIR Gov, que coordena a resposta a incidentes do governo federal, recomenda restringir o acesso às aplicações expostas enquanto a atualização não sai.

Tirar do ar

Pro que precisa ficar exposto e não dá pra atualizar já, a CISA, agência de cibersegurança dos Estados Unidos, recomenda tirar o sistema do ar até corrigir. A NSA, a agência de segurança dos Estados Unidos, deu o mesmo recado. A CISA estende isso a quem roda PHP 8.1 ou mais velho.

PHP 8.1 ou mais velho

O projeto PHP não vai lançar versão corrigida do 8.1 pra trás. Publicou só correções mínimas no código-fonte do 7.4, do 8.0 e do 8.1, pra quem compila. Na prática, a saída é o backport de quem distribui o seu PHP, como nas tabelas dos passos 2 e 3. Sem nenhum backport, a CISA e os centros de cibersegurança da Holanda e da Irlanda recomendam tirar do ar ou isolar até migrar. Planeje a migração pro 8.4 ou o 8.5. O 8.2 também perde suporte em 31/12/2026.

Configuração do PHP

O php.net lista configurações que reduzem a exposição a caminhos de ataque conhecidos. Aplique onde a aplicação não consegue desfazer: no pool do PHP-FPM ou na configuração do Apache, com php_admin, nunca por ini_set() ou .user.ini. Reinicie todos os workers depois.

; PHP-FPM: no pool, ex.: /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[fatal_error_backtraces] = off ; só no PHP 8.5
php_admin_value[post_max_size] = 8M          ; 32M se o sistema recebe upload
php_admin_value[memory_limit] = -1

# Apache com mod_php: no vhost ou num .conf do Apache
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8M
php_admin_value memory_limit -1

As duas primeiras linhas são da CVE-2026-109619 e fecham só os caminhos já confirmados. O post_max_size e o memory_limit são da CVE-2026-109618. O memory_limit = -1 parece estranho, mas é o que o php.net indica: ele tira o limite de memória do PHP, que é a falta de memória que o atacante consegue provocar. Uma falha real de alocação ainda pode chegar ao mesmo ponto, então o limite de memória passa pro container ou pro cgroup do serviço. Não use RLIMIT_AS nem RLIMIT_DATA, que provocam justamente a falha. Deixe o upload_max_filesize abaixo do post_max_size e limite no servidor web ou no proxy o tamanho da requisição e o número de partes e de cabeçalhos.

WAF

Se o site passa por um WAF, o filtro de aplicação web, confira se as regras que o provedor publicou pra essas falhas estão ativas e bloqueando, e não só registrando. Cloudflare e AWS publicaram as delas. A AWS avisa que as regras não fecham as falhas e cobrem só em parte a CVE-2026-109618.

A atualização não diz se alguém entrou antes dela, então essa conferência vem depois. A Amazon recomenda investigar desde 17/10, a data da primeira tentativa que ela viu. Os pesquisadores também mostraram que dá pra ler trechos da memória do PHP pela rede, onde podem estar senhas, tokens e chaves de API de outras requisições.

Logs

Procure falta de memória, processo do PHP caindo perto de POST grande ou de envio de arquivo, e erro 500 repetido depois de envio de formulário. Log limpo não descarta invasão: o ataque roda abaixo da aplicação e pode não deixar rastro nela.

PADRAO='Allowed memory size|SIGSEGV|exited on signal|exit signal|exited with code 137'
sudo grep -E "$PADRAO" /var/log/php*-fpm.log /var/log/apache2/error.log    # Debian e Ubuntu
sudo grep -rE "$PADRAO" /var/log/php-fpm/ /var/log/httpd/error_log         # Red Hat, Alma, Rocky

Processos

PHP-FPM ou Apache com sh, bash, curl ou wget pendurado embaixo, rodando com o usuário do site.

ps -eo user,pid,ppid,lstart,args --forest | less

Arquivos e agendamentos

Arquivo .php novo na pasta do site sem deploy que explique, tarefa nova no cron, arquivo estranho em /tmp. Troque www-data pelo usuário do site no seu servidor (apache no Red Hat).

sudo find /var/www /home -type f -name '*.php' -newerct 2026-10-17 2>/dev/null
sudo find /tmp /var/tmp -type f -newerct 2026-10-17 -ls
sudo crontab -l -u www-data

Rede e contas

Conexão de saída aberta por processo do PHP, conta nova no sistema ou na aplicação, login fora do padrão. O comando abaixo esconde as conexões que chegam nas portas 80 e 443 do servidor, pra sobrar o que o PHP abriu pra fora.

sudo ss -tpn state established | awk '$3 !~ /:(80|443)$/' | grep -E 'php|apache2|httpd'

Requisições

Se você tem log de WAF ou do corpo das requisições, procure POST com PHP_SESSION_UPLOAD_PROGRESS em envio de formulário e cookie PHPSESSID grande demais ou malformado. A Amazon publicou seis IPs ligados às tentativas: 103.216.220.92 (17/10), 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 e 95.217.98.37 (21/10). São redes de anonimização compartilhadas: investigue o acesso em vez de só bloquear.

Se achar sinal de invasão

Isole o servidor da rede antes de desligar, porque desligar apaga o que está na memória. Não limpe nada antes da análise: guarde os registros e chame quem responde por incidente na empresa. Pela leitura de memória que os pesquisadores demonstraram, a gente trocaria as senhas, tokens e chaves que a aplicação usa. Se o sistema guarda dado pessoal e o incidente pode trazer risco ou dano relevante aos titulares, a LGPD obriga o controlador a comunicar a ANPD e os titulares (art. 48). Avalie isso com o encarregado de dados e o jurídico.