Quando o servidor, o kernel e o agente pedem limite

Tem um tipo de problema que cresce quieto: a gente dá poder para uma peça do sistema porque precisa que ela trabalhe por nós, depois esquece que ela ficou com esse poder.

O servidor na entrada passa a decidir o que chega na aplicação. O caminho mais fundo da máquina decide quem pode fazer o quê lá dentro. A ferramenta que edita código ganha acesso a arquivos, comandos e talvez segredos. O operador de banco, lá no cluster, vira a mão que troca instância, disco, réplica e failover quando algo dá errado.

Nada disso é ruim por si só. Sem essas camadas, a produção vira uma pessoa fazendo plantão com fita crepe e café frio. O problema aparece quando o poder fica grande demais, espalhado demais, antigo demais ou pouco observado. Aí o assunto deixa de ser só a etiqueta da falha ou o anúncio da ferramenta. Vira uma pergunta de gente adulta, infelizmente mais chata: quem ganhou autoridade aqui, qual é o tamanho do estrago se ela falhar, e onde está o freio?

Hoje o dia veio com esse gosto de inventário. Uma peça muito comum na frente de aplicações ganhou pressa de correção. Um caminho local no Linux lembrou que “precisa estar dentro da máquina” não significa “tanto faz”. Um texto em PT-BR sobre agentes foi direto no ponto: antes de deixar automação mexer no repositório, desenhe a cerca. E uma comparação entre operadores de Postgres no Kubernetes mostrou que ferramenta de banco também é decisão sobre autoridade, não só sobre feature.

Eu sei. Talvez isso nunca vire adesivo bonito no notebook. Ainda assim, evita aquele silêncio estranho depois do deploy.

Vamos por partes.

A falha do NGINX saiu da prateleira de advisory

A história mais urgente do dia é o NGINX Rift, registrado como CVE-2026-42945. A versão curta, sem transformar isso em receita de ataque, é: existe um estouro de buffer no heap dentro do ngx_http_rewrite_module, e ele atinge uma peça que muita gente coloca bem na frente da aplicação.

Esse lugar na arquitetura muda o peso da notícia. Um bug em proxy exposto não é igual a um bug escondido em um serviço que ninguém alcança sem passar por três controles. NGINX costuma receber tráfego de usuário, API, dashboard, webhook, painel interno publicado às pressas e todo tipo de “era temporário, mas ficou”. Temporário, em infraestrutura, às vezes ganha aniversário.

A Depthfirst descreve o problema como uma falha antiga em um padrão específico de rewrite. Em configurações padrão, o impacto confirmado é negação de serviço: o worker pode cair. A mesma fonte e o registro CVE dizem que execução remota de código pode acontecer quando ASLR está desativado. Esse detalhe precisa ficar no texto porque muda o tom. É sério, mas não autoriza sair dizendo que todo NGINX da internet já virou concha de acesso remoto.

As versões citadas pela Depthfirst colocam NGINX Open Source de 0.6.27 até 1.30.0 na área afetada, com correção em 1.30.1 e 1.31.0. Para NGINX Plus, a página lista R32 até R36, com correções em R32 P6 e R36 P4. A curadoria também apontou a cadeia de CVE e PoC pública, então para quem opera isso a ação é bem pouco poética: inventariar versões, olhar primeiro o que está exposto na internet, revisar uso de rewrite e atualizar.

O pedaço novo de hoje é a virada de urgência. A SecurityWeek publicou que a VulnCheck observou exploração em canários depois da publicação do CVE, e atribuiu a uma consulta da Censys o número de cerca de 5,7 milhões de servidores NGINX expostos com versão potencialmente vulnerável. A própria reportagem ressalta que a população realmente explorável deve ser menor, porque depende de configuração específica.

Esse é o ponto bom para levar para o time: transforme a notícia em fila de prioridade, não em pânico. Edge primeiro, versão antiga primeiro, configuração de rewrite primeiro. O resto pode esperar a reunião, a menos que a reunião seja justamente sobre por que o proxy de 2019 ainda está de pé.

Fontes: Depthfirst, registro CVE-2026-42945, PoC e detector no GitHub e SecurityWeek.

DirtyDecrypt começa local e ainda assim merece respeito

A segunda notícia também é de segurança, mas tem outro desenho. DirtyDecrypt é uma escalada local de privilégio no Linux. Isso quer dizer que o atacante precisa conseguir executar código na máquina antes de tentar virar root. Parece menos dramático do que uma falha remota em servidor público, e em parte é mesmo. Só que “local” não é palavra mágica que apaga risco.

Pensa em workstation de dev, runner de CI, máquina de build, laboratório com distro rápida, host compartilhado, container com kernel do host logo ali embaixo. Depois que alguém tem um pé dentro, bugs locais decidem se aquilo fica contido ou vira domínio completo da máquina. É o tipo de detalhe que separa “invadiram um usuário limitado” de “agora eu tenho um problema com gosto de fim de semana”.

A BleepingComputer reportou que há PoC pública para DirtyDecrypt, também chamado na cobertura de DirtyCBC, e que o problema envolve rxgk_decrypt_skb, no caminho de RxRPC/rxgk. O projeto da V12 descreve uma falha ligada a page cache e falta de guarda de copy-on-write. A conexão com CVE-2026-31635 precisa vir com cuidado: a reportagem atribui o alinhamento a Will Dormann, mas também diz que não há um identificador CVE oficial limpo na página do PoC. A NVD fala de Linux antes de 6.14.4 e aponta o commit 30e5acb0a179d8023460b50a029e83f610f18bd6c, mas o texto da NVD não bate perfeitamente com a descrição pública do PoC.

Traduzindo a bagunça sem perder o alerta: existe PoC, existe área técnica identificada, existe correção em cadeia de kernel, mas a etiqueta exata ainda merece atribuição. Isso não impede defesa. Impede manchete gritando certeza onde a fonte ainda está com as bordas tortas.

A superfície também não é todo Linux do planeta da mesma forma. A BleepingComputer diz que a exploração exige kernel com CONFIG_RXGK, ligado ao suporte de segurança RxGK para o cliente AFS e transporte de rede. A reportagem cita mais atenção para distros próximas do upstream, como Fedora, Arch e openSUSE Tumbleweed, e diz que o PoC foi testado em Fedora e kernel mainline.

Mitigação aqui é chata do jeito certo: atualizar kernel. Há sugestão de blacklisting de módulos como esp4, esp6 e rxrpc, mas isso pode quebrar VPNs IPsec e AFS. Então não é um comando bonito para jogar em frota inteira antes de entender o que usa isso. Segurança que resolve um incidente criando outro merece uma cadeira separada na reunião.

Fontes: BleepingComputer, PoC da V12 no GitHub e NVD sobre CVE-2026-31635.

Agente dentro do repo precisa de cerca antes da euforia

Depois de proxy e kernel, vem uma história menos explosiva e talvez mais útil para a rotina de quem programa. Um texto no TabNews defende uma ideia simples: antes de colocar agentes para mexer no seu repositório, desenhe as fronteiras.

Gosto desse tipo de conselho porque ele troca a pergunta bonita pela pergunta operacional. O agente pode ler tudo? Pode ver .env? Pode instalar pacote? Pode rodar comando arbitrário? Pode abrir PR? Pode dar push na main? Pode iniciar deploy? Onde ficam os logs? Quem aprova o que saiu? Parece burocracia até você lembrar que a ferramenta escreve código com a mesma confiança textual com que erra o caminho de um arquivo.

O artigo recomenda limitar workspace, segredos, branch, comando, deploy e aprovação antes da adoção. Em vez de soltar a automação no repositório inteiro, use branch temporária, ambiente falso quando der, token com privilégio mínimo, validação de CI, secret scanning, aprovação humana para passo perigoso e logs que permitam entender o que aconteceu depois. Se a tarefa é pequena, o poder também deveria ser pequeno.

Esse cuidado ajuda justamente quem quer usar agente de verdade. Se a ferramenta é útil o bastante para tocar código real, ela merece o mesmo tratamento que qualquer automação com acesso a shell. A diferença é que ela conversa bonito, e isso engana. Shell com lábia continua sendo shell.

Também vale uma distinção honesta: esse bloco é orientação de prática, não benchmark, incidente ou paper medido. O valor está na checklist mental. Para times que estão testando agentes hoje, especialmente em repositórios com segredo, infraestrutura, deploy ou cliente real, a decisão começa pelo espaço permitido para essa ferramenta trabalhar.

Fonte: Antes de colocar agentes no seu repositório, desenhe as fronteiras.

Operador de Postgres também é decisão de incidente

Gabriele Bartolini publicou uma comparação entre CloudNativePG e Crunchy Postgres Operator, também conhecido como PGO. A fonte precisa de aviso logo no começo: ele é cofundador e mantenedor do CloudNativePG, e chama o texto de opinionated. Então o melhor jeito de ler é como uma lista de critérios bons para testar no seu próprio cluster, sem transformar o artigo em placar final de campeonato.

O assunto parece específico, mas o fundo é bem comum: quando você coloca Postgres no Kubernetes, o operador vira parte do plano de controle do banco. Ele mexe em pods, volumes, failover, backup, upgrade e observabilidade. Se ele falha, se a API do Kubernetes some, se uma imagem carrega superfície demais, você descobre que “operador” é uma palavra pequena para uma autoridade enorme.

O contraste central do texto é arquitetural. Segundo Bartolini, o Crunchy PGO trabalha com Patroni em sidecar e um DCS, o distributed configuration store. O CloudNativePG, por sua vez, usa a API do Kubernetes como fonte de verdade e gerencia diretamente Pods e PVCs. Isso muda o comportamento quando o cluster fica doente.

Um exemplo bom é a queda da API do Kubernetes. Pods existentes continuam rodando, mas agendamento, reconciliação e lógica do operador ficam prejudicados. O texto diz que o CloudNativePG suspende failover nesse cenário para proteger dados. Isso pode soar conservador demais para quem quer troca automática a qualquer custo. Também pode ser exatamente o freio que evita transformar uma indisponibilidade de controle em divergência de estado no banco.

Há ainda a comparação de superfície de imagem, atribuída ao Docker Scout no texto: imagem do Crunchy com 625 pacotes, 2 vulnerabilidades críticas e 156 altas; imagem do CloudNativePG com 140 pacotes, 0 críticas e 4 altas. Número de scanner não é verdade universal, e amanhã pode mudar com outra versão. Mesmo assim, é uma pergunta ótima: o que está dentro da imagem que carrega seu banco?

Para quem escolhe operador de Postgres, a conclusão responsável é meio sem glamour: rode backup e restore, simule upgrade, force failover, derrube a API em ambiente controlado, olhe permissões, leia licença, entenda imagem e veja como o time reage ao incidente. Feature table ajuda na primeira triagem. Incidente real não lê tabela bonita.

Fonte: CloudNativePG and Crunchy PGO: an honest, opinionated comparison.

Destaques rápidos para hoje.

• A OpenSSF publicou um alerta de preparo para o Cyber Resilience Act. A organização diz que 66% dos respondentes da pesquisa não estavam familiarizados com a CRA, que 51% dos fabricantes dependem passivamente de comunidades open-source e que workarounds privados custam em média 258 mil dólares por ciclo de release. As datas que entram no radar são setembro de 2026, para obrigações de reporte de vulnerabilidade, e dezembro de 2027, para obrigações mais amplas. Para empresa que usa software livre, isso vira inventário, SBOM, processo de vulnerabilidade e contato com upstream. Fonte: OpenSSF.

• Semble apareceu como uma ferramenta open-source de busca de código pensada para agentes. A promessa é reduzir o desperdício de contexto antes da edição: ele roda localmente em CPU, sem chave de API ou GPU, combina embeddings Model2Vec, BM25, reciprocal rank fusion e reranking, e expõe integração via MCP. Os números grandes, como 98% menos tokens, qualidade perto de 99% e melhorias de velocidade, são claims do projeto. Eu colocaria isso na pasta “testar em repo real antes de acreditar com força”. Fonte: MinishLab/semble.

• O Pwn2Own Berlin 2026 fechou com 1.298.250 dólares em prêmios e 47 vulnerabilidades zero-day únicas, segundo a Zero Day Initiative. A DEVCORE ganhou Master of Pwn com 50,5 pontos e 505 mil dólares. O detalhe importante para quem cuida de ambiente corporativo é o relógio: vendors têm janela coordenada de 90 dias antes de divulgação pública pela ZDI. Guarde isso como lista de advisories para acompanhar nos próximos meses, sem tratar o resultado como exploit dump de hoje. Fontes: ZDI e BleepingComputer.

• block_size no PostgreSQL parece configuração normal, mas é uma opção preset, lida a partir de como o servidor foi compilado. O valor padrão documentado é 8192 bytes, determinado por BLCKSZ, e não é um botão de postgresql.conf para mexer depois do almoço. Se você não está construindo um PostgreSQL customizado e testando cluster novo para isso, deixe quieto. Fonte: The Build e documentação do PostgreSQL.

Acompanhamento de tendências do dia.

O fio que junta as histórias de hoje é autoridade com raio de explosão menor. O proxy na borda recebe tráfego demais para ficar velho sem dono. O kernel continua sendo a parte em que “local” vira root quando a corrente já começou. O agente no repositório precisa de limite antes de receber chave, branch e deploy. O operador de banco precisa ser escolhido pelo comportamento em falha, não só pelo nome que aparece melhor no README.

Tem um sinal paralelo no kernel também. A Phoronix reportou que Greg Kroah-Hartman continuou encontrando bugs com um fuzzer local apoiado por IA, o Clanker 2000, levando a correções no driver core do Linux. A graça aqui está em ver automação entrando no fluxo de gente experiente para achar coisa repetitiva, cansativa e útil. Depois vem revisão, patch e manutenção normal. Que coisa, né? Software ainda gosta de processo.

O mesmo vale para a CRA no mundo open-source. Quando a lei vira processo de vulnerabilidade, inventário e documentação, a cobrança não cai só em jurídico. Ela passa por quem mantém pacote, quem publica imagem, quem responde advisory, quem sabe onde está a dependência e quem vai receber o e-mail quando algo quebrar. O nome bonito é conformidade. O trabalho real parece mais com lista, contato, prazo e evidência.

Se der para tirar uma ação pequena do dia, eu começaria assim: descubra o que está exposto, reduza privilégio onde a ferramenta fala com produção, teste o failover que você acha que entende e deixe o agente trabalhar em um cercado que você conseguir explicar depois. Não resolve o mundo. Já seria uma segunda-feira menos corajosa do que o necessário.

Fontes: Depthfirst, BleepingComputer sobre DirtyDecrypt, TabNews, OpenSSF e Phoronix.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.