Semana pesada de segurança: PHP2Shell, patch do Node e LiteLLM envenenado

O dia 21 de outubro de 2026 foi daqueles em que você abre o feed e fecha o editor de código. PHP, Node.js e Python soltaram atualizações de segurança praticamente juntos, e no meio disso uma biblioteca Python bem popular foi comprometida no PyPI.

Trabalho com as três stacks (Laravel no dia a dia, Node/Next.js no próprio DevDiary e Python para automações), então fiz o que todo mundo deveria fazer: parei, li os advisories e atualizei. Deixo aqui o resumo do que importa e o checklist que usei.

Se você só tem 30 segundos: atualize o PHP para 8.4.27 (ou o patch da sua versão), o Node para 22.23.4 / 24.22.1 / 26.12.1 e o Python para o último patch da sua série. E confira se litellm==1.107.0 passou por algum ambiente seu.

PHP: PHP2Shell (CVE-2026-109618 e CVE-2026-109619)

Esse é o mais grave da semana, de longe.

O que é: duas falhas no próprio interpretador do PHP (não em framework, não em extensão) que permitem execução remota de código sem autenticação. As duas receberam nota 9.2 no CVSS v4.0.

CVE-2026-109618: quando o PHP trata um erro de falta de memória (out-of-memory), o fluxo é interrompido com dados internos da requisição só parcialmente inicializados. Depois, a limpeza da requisição trata esse lixo como dado válido. O atacante força o OOM de propósito e chega à execução de código.
CVE-2026-109619: um estado interno da requisição continua apontando para memória que já foi liberada. A próxima requisição atendida pelo mesmo worker pode usar esse estado velho antes de ele ser resetado. Clássico use-after-free entre requisições.

Quem está afetado: todas as versões do PHP da 5.4 até a 8.5.11. Ou seja: praticamente todo PHP rodando no mundo.

Por que é urgente:

Os detalhes vazaram antes do patch sair. A existência das falhas foi anunciada no dia 20 e a correção saiu no dia 21.
A Amazon registrou tentativa de exploração nos honeypots dela no dia 17, quatro dias antes da divulgação.
A Cloudflare viu as tentativas saltarem de dezenas de milhares nos primeiros 45 minutos para milhões no dia seguinte.
A Palo Alto estima mais de 22 milhões de instâncias expostas potencialmente vulneráveis.

Versões corrigidas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

O time do PHP foi direto no anúncio: não existe mitigação completa, atualizar é a única opção segura.

E já tem mais uma: CVE-2026-115560

Hoje (23/10) o PHP publicou um aviso curto sobre uma nova falha que pode levar a execução de código, mas só em aplicações com uma configuração de sessão incomum. Não há exploração conhecida e a correção vai sair no ciclo normal de releases. A recomendação provisória é desligar o upload progress de sessão:

; php.ini
session.upload_progress.enabled = 0

Quase ninguém usa esse recurso em app Laravel moderno, então desligar não deve quebrar nada. Mas teste.

O que eu fiz nos projetos Laravel

# Ver a versão realmente usada pelo PHP-FPM, não só a do CLI
php -v
php-fpm8.4 -v   # o nome do binário varia por distro

# Debian/Ubuntu com o repositório do Ondřej
sudo apt update && sudo apt install --only-upgrade php8.4-fpm php8.4-cli

# Reinicie o FPM, senão os workers antigos continuam vivos
sudo systemctl restart php8.4-fpm

Pontos que pegam muita gente:

composer update não resolve nada aqui. A falha é no binário do PHP, não nos pacotes.
Docker: atualizar o servidor não atualiza a imagem. Rebuilde com a imagem base nova (php:8.4-fpm já puxando 8.4.27) e faça o deploy de novo.
Hospedagem compartilhada: confira no painel qual versão está ativa. Se o provedor ainda não atualizou, abra chamado.
PHP 8.2 chega ao fim do suporte em 31/12/2026. Se você está nela, aproveite o susto para planejar a migração.

Node.js: release de 21/10 com 10 CVEs

Bem menos dramático que o PHP, mas tem coisa séria. O projeto corrigiu 10 vulnerabilidades em todas as linhas ativas (22.x, 24.x e 26.x), com quatro classificadas como altas:

CVE	Onde	O que faz
CVE-2026-111497	Decoder Brotli	Escrita fora dos limites de memória, com potencial de execução remota de código
CVE-2026-105482	`dns.resolve`	Nomes com caractere NUL são truncados, o que ajuda a burlar proteções contra SSRF
CVE-2026-105483	Validação de hostname TLS	Bypass quando o IP é escrito com dígitos fullwidth (não afeta a 22.x)
CVE-2026-106069	Validação de hostname TLS	Outro bypass de validação de hostname no certificado

Entre as médias, tem um problema no keep-alive HTTP (o socket pode processar uma resposta escrita antes da requisição ser enviada) e uma falha de validação de certificado com hostnames IPv4 fora do padrão. O release também atualiza os certificados raiz embutidos e passa a rejeitar cadeias com chaves públicas bloqueadas, por causa do incidente com a CA eMudhra/emSign.

Até o dia da publicação não havia exploração reportada.

Versões corrigidas: 22.23.4, 24.22.1 e 26.12.1.

Node 20 ou anterior: está fora de suporte e não vai receber patch. Se ainda tem algo em produção nessa versão, a hora de migrar é agora.

Bônus para quem usa Next.js

Uma semana antes, no dia 14, o Next.js corrigiu duas falhas críticas de execução remota de código (CVSS 9.5). As versões corrigidas são 15.5.28 e 16.4.1. Como o DevDiary roda em Next.js, atualizei os dois juntos.

# Versão do Node que REALMENTE está rodando, não só a do seu shell
node -v
ps aux | grep node

# Com nvm / fnm
nvm install 24.22.1 && nvm alias default 24.22.1
# ou
fnm install 24.22.1 && fnm default 24.22.1

# Next.js
npm install next@latest
npm ls next

Lembrete: processos gerenciados por pm2, systemd ou containers continuam usando o binário antigo até serem reiniciados ou rebuildados. Atualizar o Node no terminal não muda o que já está rodando.

Python: patches no CPython e o caso LiteLLM

CPython

Do lado do interpretador, o mês teve duas rodadas:

1º de outubro: saíram 3.10.22, 3.11.17, 3.12.15, 3.13.16 e 3.14.8, todas com a correção da CVE-2026-82049, uma falha no filtro de extração do tarfile envolvendo hard links para links simbólicos. Na prática, um .tar malicioso podia expor arquivos fora da pasta de destino e alterar permissões deles. Essa rodada também corrige uma falha crítica no callback SNI do módulo ssl (CVE-2026-19445). A 3.10.22 foi a última da série: Python 3.10 morreu.
21 de outubro: releases expressos 3.15.1, 3.14.9 e 3.13.17, que atualizam o pip embutido para 26.2.2 com certificados novos, também por causa do incidente com a CA eMudhra/emSign. O time do Python pede para atualizar pip e uv em todos os virtualenvs existentes.

Se você está na 3.12 (eu estava na 3.12.3), o alvo é a 3.12.15.

python3 --version

# Dentro de cada venv
python -m pip install --upgrade pip certifi
uv self update   # se usa uv

LiteLLM 1.107.0: ataque à cadeia de suprimentos

Esse é o tipo de coisa que dá mais medo que CVE, porque não depende de bug: o pacote oficial veio com malware.

No dia 21, o pipeline de release do LiteLLM (proxy muito usado para rotear chamadas entre provedores de LLM) foi comprometido, e a versão 1.107.0 foi publicada no PyPI e no Docker Hub com um ladrão de credenciais e um trojan de acesso remoto. Os pacotes ficaram no ar por cerca de duas a três horas e tiveram mais de 49 mil downloads estimados. Segundo a investigação, os atacantes usaram tokens OAuth do GitHub CLI comprometidos.

O detalhe técnico que achei mais traiçoeiro: o pacote instalava arquivos .pth e sitecustomize.py no site-packages. Isso faz o malware rodar toda vez que o interpretador Python inicia, mesmo que seu código nunca importe o litellm. O payload procura credenciais de AWS, Azure, Google Cloud, Kubernetes, Docker, Git, chaves SSH, variáveis de ambiente e bancos de dados de navegador.

E é a segunda vez no ano que o LiteLLM é comprometido.

Se você instalou a 1.107.0:

Não rode python nem pip nessa máquina para "investigar". Qualquer start do interpretador dispara o malware de novo.
Isole a máquina ou o container e reconstrua do zero.
Troque todas as credenciais que estavam acessíveis: chaves de cloud, tokens de API de IA, chaves SSH, tokens do GitHub.
Fixe uma versão limpa no requirements.txt / pyproject.toml e use lockfile com hash.

O que eu tirei dessa semana

Três coisas que vou levar a sério daqui para frente:

Saber exatamente que versão roda em produção. Não a do meu notebook, a do servidor. Coloquei a versão do runtime num endpoint de health interno.
Imagem Docker parada é imagem vulnerável. Rebuild periódico, mesmo sem mudança no código.
Lockfile com hash e atraso proposital em dependências novas. Instalar a versão que saiu há 10 minutos é exatamente o que um ataque como o do LiteLLM espera que você faça.

Checklist rápido

PHP em 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (CLI e FPM)
PHP-FPM reiniciado e imagens Docker rebuildadas
session.upload_progress.enabled = 0 até sair o fix da CVE-2026-115560
Node em 22.23.4 / 24.22.1 / 26.12.1, processos pm2/systemd reiniciados
Nada rodando em Node 20 ou anterior
Next.js em 15.5.28 ou 16.4.1
Python no último patch da série (3.12.15, 3.13.17, 3.14.9...)
pip, certifi e uv atualizados em todos os venvs
pip show litellm em todo ambiente que usa IA; se aparecer 1.107.0, rotacionar credenciais