Zero-day no F5, RCE no next/og e o disco do inquilino anterior

A semana teve um fio, e ele é sobre fronteira que a gente supõe existir. Em 22 de setembro a F5 corrigiu fora de hora um estouro de buffer no BIG-IP APM que já estava sendo explorado, e o caminho é tráfego sem autenticação chegando na memória de um servidor de autorização OAuth. No mesmo dia o Next.js publicou uma execução remota nota 9,5 no next/og, e o caminho é valor que veio do usuário chegando dentro de um SVG. Na quarta a Cloudflare contou como um cliente conseguia ler blocos de disco que pertenciam a outro cliente nos Containers. E na segunda o time do Rust avisou que rodar cargo miri com cache no GitHub Actions entregava os segredos do repositório para quem abrisse um pull request.

Quatro itens, quatro fronteiras diferentes, e a mesma forma. Em nenhum dos casos o atacante furou uma barreira: ele usou uma porta que estava documentada como segura. O OAuth do BIG-IP aceita tráfego anônimo por definição, é o que ele faz. O next/og aceita parâmetro de query, é para isso que serve. O disco de provisionamento fino reaproveita bloco, é o ganho dele. O cache de CI existe para ser reusado entre execuções. Em cada um, o que faltou foi uma linha de código tratando o pior caso da própria função.

A outra metade da semana foi sobre cadência, e é quase o oposto disso. O Chrome entregou a primeira versão estável no ciclo de duas semanas. O Next.js avisou com uma semana de antecedência que vai publicar nove correções em 30 de setembro. E o PostgreSQL 19 tirou cinco recursos do beta 4 para não atrasar a data. Três projetos grandes escolhendo previsibilidade em cima de conteúdo, na mesma semana. Oito itens. Três desenvolvidos.

Destaques

Zero-day no BIG-IP APM, explorado antes do aviso

A F5 publicou em 22 de setembro o aviso da CVE-2026-94127, um estouro de buffer em heap no Access Policy Manager que permite execução remota de código sem autenticação nenhuma. A nota é 9,8 no CVSS 3.1 e 9,3 no 4.0. A CISA pôs a falha no catálogo de exploração ativa no mesmo dia, com prazo de correção em 25 de setembro para as agências federais americanas. Ou seja: a publicação do aviso já veio depois de ataque, não antes.

O detalhe que decide se isso é problema seu está na configuração, e não na versão instalada. Segundo a análise da Rapid7, é preciso um virtual server com política de acesso do APM e perfil OAuth configurados juntos, e o gatilho só existe quando o APM está atuando como servidor de autorização OAuth. Quem usa o APM como cliente ou como servidor de recurso não é atingido. Ter BIG-IP com APM licenciado, por si, não responde nada.

As correções saíram como hotfix de engenharia, não como versão nova: a Hotfix-BIGIP-21.1.0.2.0.30.22-ENG para a 21.1.0, a Hotfix-BIGIP-17.5.1.9.0.160.12-ENG para a 17.5.0 e a Hotfix-BIGIP-17.1.3.5.0.41.14-ENG para a 17.1.0. Repare no formato, porque ele muda o procedimento: hotfix de engenharia não aparece no fluxo normal de atualização e quem não pode aplicar agora precisa pedir ao suporte da F5 o contorno por iRule. A Rapid7 registra que, na data do aviso, não havia prova de conceito pública confirmada.

O que muda na prática vai além do BIG-IP. Vale olhar o resto do que entrou no catálogo da CISA na mesma leva: duas do Check Point, validação indevida de certificado e travessia de caminho, e uma do Arista VeloCloud Orchestrator. Um dia antes tinha entrado uma falha em switches Zyxel GS1900, também explorada. Cinco itens em dois dias, todos em equipamento de borda. É o padrão que se repete há dois anos e ainda surpreende gente: o aparelho que termina o TLS e autentica a sua rede é o alvo mais interessante que existe, porque ele fica exposto por profissão e quase nunca está no inventário de atualização de ninguém. Se você não sabe quem cuida do firmware do seu balanceador, essa é a pergunta da semana.

RCE no next/og, e mais nove correções marcadas para 30 de setembro

Em 22 de setembro a Vercel publicou o Next.js 16.3.6 e o 15.5.26 fora do calendário, por causa de uma falha em dependência acima na cadeia. O aviso GHSA-vcvr-r3jv-pc5j descreve execução remota de código na implementação Node.js do ImageResponse, do next/og. A CVE é a 2026-94545, nota 9,5 no CVSS 4.0, e o vetor é rede, sem privilégio e sem interação do usuário. Atingidas: todas as versões da 16.2.0 até antes da 16.3.6. A linha 15 não tem a execução remota, e a 15.5.26 é só endurecimento.

Aqui também a exposição depende de como você usa, e o aviso é explícito nos dois casos que não são atingidos. Primeiro: quem usa a implementação Edge do ImageResponse está fora. Segundo, e mais importante, quem não passa valor controlado pelo atacante para dentro do conteúdo, dos atributos ou dos estilos do SVG também está fora. Esse é o teste que eu faria antes de qualquer coisa: abra cada rota que gera imagem e veja de onde vem cada string que entra no SVG. Se todas são constantes suas, o risco é outro. Se alguma vem de searchParams, de título de post ou de nome que o usuário digitou, é essa.

Vale o exemplo concreto, porque é o caso mais comum que eu vejo. Card social gerado na hora, com o título da página desenhado em cima da arte, e o título vindo da URL. É um padrão bonito, é recomendado em tutorial, e é exatamente a forma dessa falha. Neste site o card social é um PNG estático em app/opengraph-image.png, então o next/og não entra em cena. Isso não foi previdência, foi escolha de performance feita por outro motivo, mas serve para o ponto: dependência que você não tem é a única que não te acorda de madrugada.

E tem a segunda parte, que é o motivo de eu desenvolver esse item em vez de deixar em nota. No dia seguinte, 23 de setembro, a Vercel avisou que vai publicar o 16.3.7 e o 15.5.27 em 30 de setembro, com nove correções: uma crítica, duas altas, cinco médias e uma baixa. O aviso prévio existe para dar tempo de planejar, e eu acho isso acertado. Mas repare no que ele significa para quem opera: em oito dias você vai atualizar Next.js duas vezes. Se a sua esteira de deploy trata atualização de framework como evento raro, com janela, aprovação e teste manual, essa é a semana de descobrir. Eu colocaria os dois no calendário agora e trataria o dia 30 como já agendado, não como surpresa.

Um cliente lia o disco do cliente anterior nos Cloudflare Containers

Em 24 de setembro a Cloudflare publicou o relato de uma exposição de dados entre inquilinos nos Containers. Vale ler inteiro, porque é boa engenharia contada com honestidade, e porque a causa raiz é uma opção de configuração que muita gente liga sem pensar.

O mecanismo: os Containers usavam provisionamento fino do device mapper do Linux com a opção skip_block_zeroing ativada. Com ela, o dm-thin não zera o bloco recém-alocado antes de entregar. O ataque que Oren Yomtov, da Accomplish, desenhou é elegante: escreva 4 KiB numa região não mapeada, alinhada ao bloco de 64 KiB do pool. Isso força a alocação de um bloco físico do pool compartilhado. E como ninguém zerou nada, os 60 KiB restantes podem trazer o conteúdo do dono anterior. O que dava para recuperar assim, segundo o texto, é metadado de sistema de arquivos, estrutura de diretório, página de banco de dados e dado de aplicação. Bastava uma conta Workers Paid.

A linha do tempo é o que eu mostraria para um time que discute resposta a incidente. O relato foi para o HackerOne às 15h26 UTC de 4 de setembro. A Cloudflare confirmou em produção às 18h45 do mesmo dia. As correções entraram e o rollout começou entre 21h27 e 23h15, também no dia 4. O rollout terminou às 6h13 UTC de 7 de setembro, e aí começou a limpeza dos dados residuais. Em 14 de setembro os pesquisadores confirmaram que a prova de conceito não funcionava mais. A limpeza dos snapshots em cache anteriores à mitigação terminou às 15h03 UTC de 19 de setembro. Seis horas do relato ao início do rollout, e quinze dias até o último resíduo apagado. Essa diferença entre as duas datas é a parte que ninguém coloca no slide.

A Cloudflare diz que não encontrou evidência de exploração maliciosa, que a atividade identificada é atribuível aos pesquisadores e à validação autorizada dos próprios engenheiros, e que não há ação a tomar do lado do cliente.

O que muda na prática, e não é sobre a Cloudflare: isso é o custo de multi-inquilino, e ele não some. Você aluga isolamento de alguém, esse alguém otimizou uma camada que você não vê, e a otimização tinha um preço. Não estou dizendo para sair da nuvem, estou dizendo o que dá para fazer com isso. Se você processa dado sensível em computação efêmera de terceiro, a pergunta que importa é o que sobra em disco quando o seu container morre, e a resposta que não depende do fornecedor é cifrar antes de escrever. Chave por execução, dado em claro só na memória. Aí o bloco que vazar para o inquilino seguinte é ruído.

Em nota

• cargo miri com cache no GitHub Actions entregava seus segredos. O aviso do time do Rust, em 21 de setembro, é direto: o Miri gravava todas as variáveis de ambiente no diretório target/. Se esse target/ ia para actions/cache ou para o Swatinem/rust-cache, e se o CI de pull request tem acesso ao mesmo cache, então qualquer pessoa que abrisse um PR podia extrair os segredos dali e depois empurrar mais um commit para esconder o rastro. As recomendações são desligar cache nos jobs de Miri, restringir segredo a passos que não incluam o Miri, limpar os caches existentes e rotacionar o que pode ter vazado. A correção está no nightly de 22 de setembro. A lição vale além do Rust, e o próprio aviso a generaliza: não exponha segredo a job que escreve em cache legível por pull request, porque quase nenhuma ferramenta promete não gravar variável de ambiente em disco.
• PostgreSQL 19 beta 4 tirou cinco recursos para não atrasar. O anúncio de 24 de setembro reverte o suporte a SQL/PGQ, o liga e desliga de checksum de dados com o servidor no ar, os updates e deletes temporais por FOR PORTION OF, as operações MERGE PARTITIONS e SPLIT PARTITIONS do ALTER TABLE, e três funções de geração de DDL. O motivo declarado é confiabilidade e calendário previsível, e os recursos devem voltar a ser considerados para uma versão futura. O que fica de pé continua sendo forte: o REPACK, que junta VACUUM FULL e CLUSTER e tem CONCURRENTLY, o WAIT, que espera a réplica aplicar até um ponto escolhido, a replicação lógica de valor de sequência e o autovacuum com worker paralelo. O release candidate sai no começo de outubro e a versão final pode sair no mesmo mês. Se você escreveu plano de migração contando com grafo em SQL ou com particionamento em tempo real, releia a lista antes de escrever código.
• GPT-6 Sol e Luna, com preço pela metade. A OpenAI anunciou os dois modelos em 22 de setembro, na API, no Codex e no ChatGPT, posicionados como a inteligência do GPT-6 Astra em versão mais rápida e mais barata. A tabela de preços põe o Sol em 2 dólares por milhão de tokens de entrada e 10 de saída, contra 4 e 20 do GPT-5.6 Sol. O Luna fica em 0,10 de entrada e 0,50 de saída, contra 0,20 e 1,20 da geração anterior. O Astra, para comparação, está em 10 e 50. Duas coisas para quem tem custo de inferência em planilha: entrada em cache sai a 10% do preço cheio, então a forma do seu prompt vale mais que a escolha do modelo; e requisição que passa de 272 mil tokens de entrada dobra o preço de entrada e multiplica a saída por 1,5 na requisição inteira, o que faz janela de um milhão de tokens ser um recurso de exceção, não de arquitetura.
• Chrome 154 estável, e o ciclo de duas semanas virou rotina. O Chrome 154 saiu em 22 de setembro, quatorze dias depois do 153, que foi o primeiro do novo ciclo. Duas mudanças pedem atenção de quem opera site. O modo somente HTTPS passa a perguntar ao usuário por padrão em conexão insegura, o que significa aviso na cara de quem serve conteúdo misto. E o Background Fetch passou a respeitar CORS e a restrição de acesso a rede local. Fora isso, Iterator.includes(), text-decoration-inset e dispensa por clique fora em popover e dialog. O recado de processo é o que fica: com estável a cada duas semanas, fixar versão de navegador em teste automatizado vira manutenção contínua, e quem precisa de ritmo lento tem o Extended Stable, que segue em oito semanas.
• Python virou linguagem de primeira classe nos Cloudflare Workers. O anúncio de 21 de setembro tira o Python do beta na plataforma. Roda sobre Pyodide, ou seja, interpretador compilado para WebAssembly, e a lista de suporte inclui FastAPI, Django e Flask, além de asyncpg e aiomysql via Hyperdrive e dos bindings de R2, D1, Queues, Workflows e Durable Objects. O limite é o de sempre nesse modelo e está dito no texto: pacote com extensão nativa em C, C++ ou Rust precisa ser compilado para WebAssembly, e muitos ainda não são. A Cloudflare propôs a PEP 783 para padronizar o alvo PyEmscripten, que é a tentativa de resolver isso na raiz. Para serviço Python pequeno e sem dependência científica, é opção real de borda hoje.

O que eu faria com isso esta semana

1. Perguntar quem cuida do firmware do seu balanceador. Se tem BIG-IP com APM, procure virtual server com política de acesso e perfil OAuth juntos, e confirme se o APM está como servidor de autorização. Se estiver, o hotfix de engenharia é hoje, e não na próxima janela: o prazo da CISA era 25 de setembro e já passou. Se a resposta para "quem cuida do firmware" for silêncio, esse é o achado mais valioso da semana.
2. Atualizar o Next.js hoje e agendar o dia 30. A 16.3.6 fecha a execução remota no next/og. Depois disso, abra cada rota de ImageResponse e rastreie de onde vem cada string que entra no SVG: se alguma vem de searchParams ou de texto de usuário, essa rota era a porta. E ponha 30 de setembro na agenda, com as nove correções seguintes.
3. Procurar cargo miri nos seus workflows, e cache logo em volta. Se os dois aparecem juntos e o CI roda em pull request, trate como segredo vazado: limpe cache e rotacione. Depois aproveite a passada e responda a pergunta mais geral, que é a que interessa: quais dos seus jobs recebem segredo e escrevem em cache que um PR de fora pode ler.
4. Cifrar antes de escrever, em computação efêmera de terceiro. O caso dos Containers não pede ação do cliente, e é justamente por isso que ele é útil como ensaio. Se dado sensível seu passa por disco de container gerenciado, chave por execução e claro só em memória é a única defesa que não depende do fornecedor ter zerado o bloco.

Radar é a newsletter semanal deste blog: o que aconteceu na semana em tecnologia, com comentário sobre o que muda para quem constrói e opera software.