Falha crítica no PHP: RCE sem login, atualize agora

Ontem, 21 de outubro, o time do PHP publicou um aviso com o título mais direto possível: vulnerabilidades críticas de execução remota de código, atualize agora. É uma falha crítica no PHP que dispensa login e, em alguns cenários, dispara antes de qualquer linha da sua aplicação rodar. Se você tem um servidor PHP respondendo requisições na internet, esse é o seu problema de hoje.

Eu sei. Você escreve TypeScript, roda Bun, deploya na Vercel. Mas faz uma conta rápida: o blog do cliente em WordPress, o painel antigo em Laravel que "ninguém mexe", aquele phpMyAdmin esquecido num subdomínio. PHP ainda roda uma fatia enorme da web, e é bem provável que pelo menos um deles seja seu ou de alguém que vai te ligar.

O que aconteceu com o PHP

São duas vulnerabilidades, ambas com nota CVSS v4.0 de 9.2 segundo o pré-anúncio do dia 20. As correções saíram nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A fonte oficial está no arquivo de notícias do php.net.

A primeira, CVE-2026-109618, mexe com falta de memória. Quando o PHP estoura o limite no meio de uma requisição, ele pode parar com dados internos montados pela metade. Depois, na limpeza da requisição, esses dados quebrados são tratados como válidos. Memória corrompida que o atacante consegue provocar é o caminho clássico para execução de código.

A segunda, CVE-2026-109619, é sobre estado que sobrevive além da conta. Um pedaço de estado interno de uma requisição continua apontando para memória já liberada. A próxima requisição atendida pelo mesmo worker pode usar esse lixo antes da inicialização normal limpar tudo. Um clássico use-after-free, com o detalhe ruim de atravessar requisições.

Quem está em risco de verdade

Resposta curta: quase todo mundo que serve web com PHP. O aviso cita PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.

O cenário mais grave é o mod_php. O time do PHP diz que existe exploit demonstrado em que uma requisição sem autenticação dispara o ataque antes de qualquer código da aplicação executar. Ou seja, não importa se o seu Laravel valida tudo direitinho. O problema acontece antes de o Laravel acordar.

Não adianta ter o código mais seguro do mundo se o runtime cai antes dele.

Um ponto que muita gente vai ignorar: PHP 8.1 e anteriores não recebem mais atualização oficial. Se o seu servidor ainda roda 7.4, você está no grupo que mais precisa agir e que menos tem opção pronta.

Como saber qual versão você roda

Antes de qualquer coisa, descubra o que está em produção. Não confie no que está no composer.json, confie no binário:

php -v
# ou, para a versão que o servidor web usa de fato:
php-fpm -v

O CLI e o FPM podem estar em versões diferentes na mesma máquina. Já vi isso mais vezes do que gostaria. Se der para criar uma rota temporária, um phpinfo() atrás de autenticação mostra a versão real que atende as requisições. Depois apague a rota.

Se você usa Docker, olhe a tag da imagem:

# ruim: pode estar presa numa versão vulnerável por meses
FROM php:8.3.10-fpm

# melhor: acompanha os patches da linha 8.3
FROM php:8.3-fpm

Tag fixa em patch dá reprodutibilidade, mas cobra caro num dia como hoje. Se for manter fixa, que exista um processo para subir a versão.

Como atualizar sem drama

O caminho certo é um só: subir para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, de acordo com a sua linha.

• Distribuições Linux receberam os patches antes, então rode o update do pacote da sua distro e reinicie o FPM ou o Apache.
• Docker: rebuild da imagem com --pull e redeploy. Sem --pull, você reconstrói em cima do cache antigo e fica achando que atualizou.
• Windows: binários novos na página de downloads.
• Hospedagem compartilhada: abra chamado hoje e pergunte a versão exata. "Estamos verificando" não é resposta.

# Debian/Ubuntu com pacotes da distro
sudo apt update && sudo apt upgrade php8.3-fpm
sudo systemctl restart php8.3-fpm
php-fpm8.3 -v

Tem um detalhe que pega muita gente: se você usa o repositório rpms.remirepo.net, mantido por voluntários, o próprio aviso diz que ele não terá atualização hoje. A recomendação é trocar por pacotes da distribuição ou compilar do fonte. Não é crítica ao mantenedor, que faz um trabalho enorme de graça. É só a realidade de depender de uma pessoa num dia de incêndio.

Para quem está preso em 7.4, 8.0 ou 8.1, o time de segurança publicou backports mínimos em branches no GitHub, voltados a quem compila do fonte ou não tem fornecedor de LTS. É um gesto raro para versões fora de suporte, e mostra o tamanho da coisa.

E se eu não puder atualizar hoje?

Acontece. Janela de manutenção, cliente que precisa aprovar, servidor que ninguém sabe a senha (esse último é piada, mas nem tanto). O aviso lista mitigações, com uma ressalva honesta: elas reduzem caminhos de ataque específicos, não deixam a instalação segura.

Para a falha de falta de memória:

; no pool do FPM, para a aplicação não sobrescrever
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M

A ideia é remover o estouro de memória controlável pelo atacante e diminuir o tamanho do que ele consegue mandar. Se a aplicação precisa de upload, o aviso sugere post_max_size de 32M, com upload_max_filesize abaixo disso. Sem limite de memória no PHP, quem segura a máquina é o container ou o cgroup, de preferência matando só o worker afetado. E não troque isso por RLIMIT_AS, que pode justamente provocar a falha.

Vale também apertar limites no proxy, como Nginx ou o balanceador: tamanho do corpo, número de campos, partes de multipart, quantidade de headers. Inclusive para requisições sem Content-Length confiável.

Para a falha de estado que sobrevive entre requisições:

session.upload_progress.enabled = 0
; só no PHP 8.5
fatal_error_backtraces = 0

Isso precisa estar no php.ini, no pool do FPM ou na configuração do servidor. ini_set() e .user.ini não servem, porque entram tarde demais. E reinicie todos os workers, senão a configuração nova não vale para os processos que já estão de pé.

Um detalhe que eu achei interessante: esconder erro com @ ou display_errors=0 não ajuda. O caminho vulnerável é o diagnóstico ser emitido, não ser exibido. É um bom lembrete de que esconder warning nunca foi o mesmo que corrigir.

O que isso muda no seu fluxo

A lição prática não é sobre PHP. É sobre o tempo entre "saiu o patch" e "está em produção". Na maioria dos times que eu conheço, esse tempo se mede em semanas, porque ninguém é dono da atualização do runtime. O código da aplicação tem PR, review e CI. A imagem base fica lá, parada, até alguém lembrar.

Algumas coisas que valem para qualquer stack, inclusive a sua de Node ou Bun:

• Saiba listar em cinco minutos todos os runtimes que você tem em produção e suas versões.
• Use tag de imagem que acompanhe patches, ou automatize o bump com Renovate ou Dependabot.
• Tenha um deploy que você consiga rodar numa terça-feira à tarde sem medo.

Minha opinião, e aqui sem meio-termo: se você ainda roda mod_php em 2026, essa é a desculpa que faltava para migrar para PHP-FPM ou FrankenPHP atrás de um proxy. Não porque o FPM esteja imune, ele não está. Mas porque isolar o PHP do servidor web dá a você mais lugares para colocar limites quando o próximo aviso desses aparecer. E ele vai aparecer.

Atualize hoje, aplique as mitigações onde não der, e anote quanto tempo levou. Esse número diz mais sobre a saúde da sua infra do que qualquer dashboard. Se quiser ver como eu organizo deploy e infraestrutura nos meus próprios projetos, dá uma olhada no que eu ando construindo.

Ontem o PHP soltou um aviso sem rodeio: falha crítica, execução remota de código sem login, atualize agora.

No mod_php o ataque dispara antes de qualquer linha da sua aplicação rodar. Seu Laravel pode validar tudo, porque o problema acontece antes dele acordar.

"Mas eu uso TypeScript e Bun." Beleza. E o WordPress do cliente, o painel antigo que ninguém mexe, o phpMyAdmin esquecido num subdomínio?

As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Confira no binário, não no composer.json. E se o seu servidor ainda está em 8.1 ou anterior, não tem atualização oficial pra ele.

Pra mim, a lição maior nem é sobre PHP. É sobre quanto tempo seu time leva entre sair o patch e ele chegar em produção.

No artigo completo eu explico como checar a versão, atualizar sem drama e o que dá pra mitigar se não der pra subir hoje. Quanto tempo você leva pra aplicar um patch desses?

#PHP #SegurançaDaInformação #DevOps #DesenvolvimentoWeb #Infraestrutura