A semana em que duas garantias silenciosas não valiam nada

O fio da semana passada é desconfortável, e ele apareceu duas vezes no mesmo dia. Em 13 de agosto, o Go e o PostgreSQL publicaram correção para a mesma classe de problema: uma garantia que o sistema anunciava e não estava cumprindo, sem avisar ninguém. No Go, o banco de checksum que existe para provar que o módulo baixado é o módulo publicado podia ser burlado. No Postgres, o pgcrypto cifrava para texto claro quando o OpenSSL recusava a cifra — e devolvia sucesso.

Nenhum dos dois é bug de crash. Os dois são pior que isso: são falha silenciosa de uma promessa em que a gente apoia decisão de arquitetura. "O módulo é verificado" e "a coluna está cifrada" são frases que ninguém revisita depois de escrever no documento. Esta semana as duas precisaram de revisão.

A outra metade da semana foi a inferência puxando para dois lados opostos. A Meta soltou um modelo agêntico de 30B sob Apache 2.0 que roda numa GPU de consumo, e a OpenAI mostrou o mesmo modelo dela rodando três vezes mais rápido num tier de acesso fechado. Oito itens. Três desenvolvidos, e o do Postgres é o que tem prazo.

Destaques

O checksum database do Go deu para ser burlado

Saíram em 13 de agosto o Go 1.26.6 e o 1.25.13, com dez CVEs. A que muda a forma de pensar é um par. Na CVE-2026-56864, um servidor GOSUMDB comprometido conseguia distribuir conteúdo de módulo que não estava no log de transparência; combinado com um GOPROXY malicioso, isso entrega módulo adulterado sem deixar rastro detectável. Na CVE-2026-56865, um GOPROXY malicioso conseguia forjar até dois tiles do sumdb e fazer um módulo pedido passar por cima da verificação do GOSUMDB, injetando conteúdo controlado por atacante no cache local. O conserto verifica todos os tiles contra o tile pai.

O que muda na prática: o argumento inteiro do go.sum mais checksum database é "não preciso confiar no proxy, porque o log de transparência me protege". Era exatamente essa camada que estava furada. Quem roda GOPROXY próprio — e quase toda empresa com Go em produção roda — herda o problema pelo lado do cliente: a correção está no binário do go, não no servidor. Atualizar o toolchain nas máquinas de build é o item, e é o mesmo trabalho de sempre com a diferença de que aqui não existe mitigação de configuração.

O resto do lote não é enfeite. A CVE-2026-56862 deixa cliente TLS malicioso mandar KeyUpdate em sequência depois do handshake e forçar o servidor a derivar chave indefinidamente — isso é qualquer servidor Go exposto na internet. A CVE-2026-56858, no html/template, quebra o rastreio de contexto de regexp em JavaScript e abre caminho para XSS. E tem encoding/asn1 sem limite de recursão, encoding/xml com contador de profundidade que nunca disparava, e net/http deixando de aplicar ReadHeaderTimeout no preface de HTTP/2 sem TLS. É lote de atualizar hoje, não de agendar.

O pgcrypto cifrava para texto claro, e o padrão mudou

Em 13 de agosto saíram 18.6, 17.11, 16.15, 15.19, 14.24 e o terceiro beta do 19: 28 CVEs e mais de 110 bugs.

A que eu leria primeiro é a CVE-2026-14663, com CVSS 6,5 — nota baixa que esconde consequência alta. O pgcrypto não detectava quando o OpenSSL recusava a cifra pedida (modo FIPS, provedor legado não carregado) e, em vez de falhar, aplicava XOR do bloco não cifrado com o texto claro. Cifra trivialmente quebrável, retorno de sucesso. Atinge principalmente cifra depreciada: blowfish, twofish, cast5, 3des. E o comportamento padrão mudou nesta versão — as notas do 18.6 dizem que o pgcrypto agora falha ao decifrar qualquer mensagem afetada, com um ignore-cipher-failure=1 novo em pgp_sym_decrypt() e pgp_pub_decrypt() para restaurar o comportamento antigo e conseguir tirar o embrulho.

O que muda na prática: se você usa pgcrypto para cifrar coluna, esta atualização pode transformar leitura que funcionava em erro — e isso é o sistema te contando que aquele dado nunca esteve cifrado de verdade. Não é regressão para consertar com a flag e esquecer. A flag é para conseguir ler o dado, decifrar de novo com cifra que o OpenSSL aceite, e aí seguir. Vale checar antes da janela quais cifras seu pgcrypto usa.

Duas outras vale nomear. A CVE-2026-14664 é estouro de heap no motor de expressão regular com execução de código arbitrário e CVSS 8,8, e regex costuma vir de entrada do usuário. E duas são do cliente, não do servidor: a CVE-2026-6464 (CVSS 8,1), em que falha no início de um COPY FROM STDIN faz o psql interpretar as linhas de dados como comandos dele mesmo, e a CVE-2026-18408 (CVSS 8,8), no \unrestrict. Servidor atualizado com psql velho na máquina de operação continua exposto.

Além de trocar o binário, tem serviço. As notas trazem a consulta que identifica tabelas com reltuples absurdo por causa de build paralelo antigo de índice GIN — o que trava autovacuum e autoanalyze — e o conserto é um ANALYZE. Índice btree_gist sobre float4/float8 com NaN, e sobre coluna bit, pede REINDEX; índice de ltree com mais de 14.653 rótulos também. E a data: o PostgreSQL 14 para de receber correção em 12 de novembro de 2026. São menos de três meses.

Um modelo agêntico de 30B, Apache 2.0, rodando numa GPU

Em 10 de agosto a Meta publicou o Muse Glimmer, 30 bilhões de parâmetros sob licença Apache 2.0, desenhado para agente local: execução de horizonte longo, chamada de ferramenta precisa, entrada multimodal, memória de contexto longo. Quantizado, cabe em 24 a 32 GB de VRAM — a Meta testou em MacBook M4-Max, M5-Max e RTX-5090. Com speculative decoding usando o drafter DFlash, o ganho de velocidade que eles relatam é de 3,1× no RTX-5090, 1,8× no M5-Max e 1,5× no M4-Max. Está no Hugging Face. Os comparativos que a Meta escolheu mostrar são contra Gemma4-31B e Qwen3.6-27B em tarefa agêntica de ponta a ponta, uso de ferramenta e recuperação de falha.

O que muda na prática é a licença junto com o tamanho. Apache 2.0 significa que o modelo pode entrar em produto, ser modificado e redistribuído sem cláusula de uso aceitável para o jurídico ler. E 30B numa GPU de consumo muda duas contas de uma vez: a de custo, porque agente é o tipo de carga que estoura token por volume e não por pico, e a de dado, porque tem cliente para quem "o texto sai da nossa rede" é o bloqueio inteiro do projeto. É a primeira vez em um bom tempo que a resposta para esse cliente pode ser um modelo capaz o suficiente para chamar ferramenta em vez do menor modelo que existe.

O ceticismo que eu manteria: benchmark de agente publicado por quem treinou o modelo é ponto de partida, não conclusão. E "roda numa GPU" não é "roda com a latência que seu usuário aceita" nem "aguenta dez sessões simultâneas". Antes de prometer local para alguém, meça token por segundo com o seu prompt de verdade e com o seu número de sessões — não com o exemplo do card do modelo.

Em nota

• A OpenAI colocou velocidade como tier de API. A Cerebras anunciou em 13 de agosto o modo Ultrafast do GPT-5.6 Sol, rodando na infraestrutura dela a até 750 tokens de saída por segundo, com 5,6× de ganho ponta a ponta nas tarefas do GDP-Val e a mesma inteligência do tier padrão. É preview limitado, e nem o anúncio da Cerebras nem o da OpenAI trazem preço, lista de região ou compromisso de disponibilidade. Ou seja: dá para experimentar, não dá para desenhar um SLA em cima. Interessante para carga onde latência é o produto — autocomplete, agente de suporte ao vivo.
• Token de OAuth do GitHub agora expira, e tem uma pegadinha nos apps antigos. Desde 14 de agosto, app OAuth pode pedir token de acesso de oito horas com refresh de seis meses (via escopo offline_access), e registrar até dez redirect URIs em vez de uma. O detalhe que eu checaria hoje: app OAuth existente com uma única redirect URI ficou com casamento por wildcard ligado por padrão, como comportamento legado. O próprio GitHub recomenda revisar e desligar onde não faz sentido. Wildcard em redirect URI é como se rouba código de autorização.
• Patch Tuesday grande, com zero-day em exploração. A Microsoft publicou 421 CVEs em 11 de agosto — a contagem varia entre fontes conforme o critério. Uma está sob exploração ativa: a CVE-2026-68820, use-after-free no driver do WinSock (afd.sys), usada para elevar privilégio a System. Outras duas foram divulgadas antes da correção. Se você tem Windows Server no parque, é fila da semana.
• Deploy de Next.js na Vercel devolveu 404 em rota de API dinâmica. O incidente pegou de 12 de agosto às 17:12 UTC até 13 de agosto às 20:33 UTC, e só atingia deploy que juntava três condições: Next.js 16.2 ou anterior, Pages Router com i18n configurado no next.config.js, e rota de API dinâmica (pages/api/[slug].ts e afins). O que importa é a cauda: não conserta sozinho. Deploy feito na janela precisa ser refeito. Se você publicou algo nesses dois dias e tem Pages Router com i18n, vale um curl nas rotas de API antes de descobrir pelo suporte.
• Cacho de incidentes na plataforma de Workers da Cloudflare. O histórico de status registra quatro incidentes em 13 de agosto e quatro em 14 — erro em requisição de Workers KV, queda de disponibilidade em Durable Objects e Workflows, erro no Workers AI com modelos específicos, autenticação intermitente no MCP Server Portal, mais congestionamento de rede no leste dos EUA. Todos classificados como menores e todos resolvidos. Não é motivo para sair da plataforma; é motivo para conferir se o seu código trata KV e Durable Objects como dependência que falha, com retry e caminho degradado, em vez de como memória local.

O que eu faria com isso esta semana

1. Atualizar o toolchain do Go nas máquinas de build, hoje. As duas CVEs de sumdb não têm mitigação de configuração e o conserto é do lado do cliente. Enquanto o go é velho, a verificação de módulo continua sendo a garantia que não garante.
2. Antes da janela do Postgres, listar quais cifras o pgcrypto usa. Se aparecer blowfish, cast5, twofish ou 3des, trate como dado provavelmente não cifrado: planeje ler com ignore-cipher-failure=1 e recifrar, não sair ligando a flag em produção para o erro parar de aparecer.
3. Atualizar o psql das máquinas de operação, não só o servidor. Duas CVEs desta leva são do cliente. A mesma lógica vale para toda ferramenta que roda na sua máquina e fala com produção.
4. Abrir as configurações dos seus apps OAuth do GitHub e olhar o wildcard. É cinco minutos, o padrão legado foi ligado por você não fazer nada, e o estrago de redirect URI permissiva é sequestro de sessão.

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.