GPT-6 Astra varia 37 pontos entre configurações, e Casdoor cruza tenants

Você compra o mesmo modelo, roda o mesmo benchmark e recebe dois resultados separados por 37,2 pontos percentuais. Entre uma execução e outra, trocaram o harness e o nível de raciocínio. O nome na caixa continuou GPT-6 Astra. Todo o resto que ajudava o modelo a trabalhar mudou. Benchmark de agente é um esporte coletivo que insiste em dar o troféu só para o atacante.

Essa confusão atravessa as notícias de hoje. Um teste diz que a vulnerabilidade foi corrigida porque o crash conhecido sumiu. Uma chamada de ferramenta nasce válida e morre no parser. E o Casdoor autoriza um objeto enquanto altera outro, numa falha crítica entre tenants. Quem olha apenas o resultado final perde justamente a fronteira que quebrou.

GPT-6 Astra mostra o peso do harness no resultado

A OpenAI apresentou o GPT-6 Astra como um modelo para trabalhos complexos de ponta a ponta: raciocínio, programação, uso do computador, pesquisa e criação de documentos. O acesso começou num programa limitado para empresas consideradas confiáveis. Depois, deve chegar à API e aos planos pagos do ChatGPT.

O modelo tem janela de contexto de 1,05 milhão de tokens e saída máxima de 128 mil tokens. Na API, texto custa 10 dólares por milhão de tokens de entrada e 50 dólares por milhão de tokens de saída. Se a requisição passar de 272 mil tokens de entrada, os multiplicadores maiores valem para a solicitação inteira.

É bastante contexto. Também é bastante espaço para enfiar uma arquitetura inteira na fatura e depois culpar o preço do token.

A parte mais interessante do lançamento veio de uma avaliação separada da ARC Prize Foundation, publicada em 3 de setembro. No ARC-AGI-3 Semi-Private, o Astra marcou 62,7% com o harness Standard da organização, a um custo total de 26.098 dólares. Com o Provider Adapter, bateu 99,9% e custou 18.817 dólares.

O harness é a infraestrutura que organiza a conversa entre o modelo e a tarefa: template, ferramentas, retenção de estado, compactação, tentativas e entrega ao avaliador. No adapter do provedor, o estado de raciocínio opaco foi preservado entre requisições, e as conversas longas passaram por compactação. No Standard, o modelo carregava apenas as notas que ele próprio decidia guardar.

A diferença de 37,2 pontos mostra que a configuração do sistema mexe muito no placar, mas não mede o efeito isolado do harness. As execuções também usaram níveis de raciocínio diferentes: max no Standard e high no Provider Adapter. Não dá para separar quanto veio do template, da memória, da compactação ou desse nível de raciocínio.

Os valores em dólares são o custo das execuções do benchmark, não uma tabela de preço por tarefa em produção. Ainda assim, a conta deixa uma pista útil: um token mais caro pode sair mais barato se o sistema precisar de menos chamadas. O token barato vira carnê rapidinho quando a tarefa entra no carrossel de falha, retry e verificação.

Por isso, numa avaliação interna, anote bem mais que gpt-6-astra e um percentual bonito. Guarde o prompt ou template, o nível de raciocínio, como o estado foi retido, a política de compactação, as ferramentas e o custo total por tarefa concluída. Inclua retries, verificações externas e revisão humana. Sem esse registro, duas equipes dizem que testaram o mesmo modelo enquanto testaram sistemas diferentes usando o mesmo crachá.

Fontes: documentação do GPT-6 Astra na OpenAI e avaliação da ARC Prize Foundation.

PatchBench separa o crash calado da vulnerabilidade corrigida

Você entrega um proof of concept, o agente muda o código e o programa para de cair com aquela entrada. Verde. Agora falta descobrir se o invasor perdeu o caminho ou se o patch só estendeu um tapete sobre o buraco exato mostrado no teste.

O PatchBench nasceu dessa diferença. O preprint, enviado ao arXiv em 3 de setembro, avalia agentes que corrigem vulnerabilidades em projetos C e C++. Os pesquisadores transplantaram falhas históricas para novos contextos de repositório e fizeram mutações no código. Também escolheram casos em que a correção verdadeira fica fora da pilha do crash e validaram tanto a segurança quanto a correção semântica.

O desenho tenta fechar dois atalhos. Um deles é reproduzir um patch histórico que já apareceu nos dados de treino. Pela métrica dos autores, em média 25% dos patches avaliados tinham semelhança substancial com correções anteriores feitas por desenvolvedores. Isso sugere possível memorização. Sozinho, esse número não prova que um patch específico foi memorizado.

O outro atalho é mexer no trecho mais perto do estrondo. Segundo os autores, os agentes frequentemente alteraram código presente na stack para impedir o crash, sem localizar e corrigir a causa da vulnerabilidade. Entre 11 agentes, incluindo os três primeiros colocados no AIxCC, validar somente com o PoC original inflou a taxa média de resolução em 1,83 vez.

Um PoC responde se uma entrada conhecida ainda produz o efeito conhecido. Uma correção de segurança precisa restaurar a regra violada e preservar o comportamento esperado pelos outros caminhos. Se o defeito está numa fronteira de confiança ou num limite incorreto, silenciar uma chamada na stack pode deixar essa fronteira aberta. O teste passa. O atacante agradece a documentação extra.

Na prática, mantenha o PoC na suíte como regressão e traga companhia. Testes semânticos verificam o uso legítimo; casos vizinhos e entradas mutadas procuram caminhos alternativos; fuzzing ajuda onde fizer sentido; e a revisão do diff confere se a mudança caiu no limite real de confiança ou de bounds. Não tem magia aí. Só uma pergunta melhor que “parou de quebrar exatamente deste jeito?”.

Os números são de um estudo v1, reportados pelos próprios autores e concentrados em vulnerabilidades de C e C++. Transferir os percentuais sem ajuste para qualquer linguagem, repositório ou agente de produção seria chute. A lição que sobra é mais simples e bem incômoda: se o critério de sucesso enxerga uma única demonstração, o agente pode otimizar para ela.

Fonte: PatchBench: Evaluating AI Agents for Vulnerability Patching.

A chamada de ferramenta pode morrer entre o template e o parser

Um modelo local retorna zero chamadas de ferramenta. A equipe olha para o modelo, o treinamento e o prompt. Um novo estudo encontrou o cadáver em outro lugar: o modelo produzia chamadas completas, mas o adapter de serving não reconhecia a sintaxe. A ferramenta não falhou. Nunca chegou a ser chamada.

O contrato começa no chat template, que define a forma apresentada ao modelo e influencia a saída que ele gera. Depois, o parser precisa reconhecer essa saída e convertê-la numa chamada estruturada. Template e parser podem funcionar perfeitamente com seus pares originais e desandar quando alguém monta o casal errado em produção.

No preprint Interface-Induced Trajectory Censoring, Wenbo Wang manteve pesos, casos, decoding e seeds fixos sobre dados do BFCL v4. A única troca foi o adapter de serving, e as pontuações passaram de 0,00 para 0,96/0,19. Uma análise com dois templates e dois parsers localizou o efeito na interação entre eles.

No tau-bench, a troca levou as chamadas aceitas pelo servidor de zero para 636 em 115 tarefas de varejo. As tarefas que chegaram a executar alguma ferramenta foram de zero para 103. Em outra configuração, durante o treinamento com AgentLoop e um modelo de 7 bilhões de parâmetros, 45 de 115 gerações continham uma chamada completa. Zero foram aceitas, executadas ou receberam uma observação de volta.

Esse silêncio estraga o diagnóstico inteiro. O placar diz que o agente não usa ferramentas, o trace agregado concorda e a equipe começa a discutir retreinamento. Enquanto isso, uma string perfeitamente aproveitável está do lado de fora do parser, olhando pela janela.

Conte cada fronteira na telemetria: saída bruta do modelo, chamadas sintaticamente completas, chamadas aceitas pelo parser, execuções iniciadas, resultados devolvidos e resposta final do avaliador. O autor também publicou um preflight de 98 linhas que, segundo o estudo, pegou todos os casos silenciosos analisados. As 98 linhas são quase uma piada pronta perto do custo de retreinar um modelo para consertar um cano desconectado.

No experimento, corrigir o adapter restaurou o parsing. A taxa de sucesso das tarefas foi de 53 para 62, uma diferença sem significância estatística. O encanamento certo deixa o agente tentar; acertar a tarefa continua sendo outro problema. E aqui também temos um preprint v1, escrito por um único autor e medido em adapters, templates, parsers e modelos específicos.

Fonte: Interface-Induced Trajectory Censoring.

Casdoor autoriza um objeto e altera outro tenant

No Casdoor, a fronteira quebrou entre a autorização e a operação. Em 3 de setembro, o CERT/CC publicou a CVE-2026-15630, que afeta as versões 3.115.0 e anteriores em ambientes multi-tenant. Um administrador de organização sem privilégio global pode executar ações administrativas contra outras organizações.

O filtro global verifica o objeto indicado pelo parâmetro ?id= da URL. Depois da aprovação, os controllers afetados usam os campos owner e name do corpo JSON para decidir qual objeto adicionar ou remover. A camada de política examina o objeto A; a lógica de negócio atua no objeto B. É o atendente que confere seu documento e entrega a chave do apartamento anotado num post-it diferente.

Para explorar a falha, o atacante precisa de uma conta autenticada de administrador de organização, com IsAdmin=true. Dentro desse acesso, o isolamento entre tenants deixa de funcionar. O pesquisador Louis Sanchez atribuiu CVSS 3.1 de 9,9 e diz ter verificado o problema pela última vez contra a versão 3.115.0 e o branch master em 12 de julho. Tanto a pontuação quanto a estimativa de aproximadamente 25 endpoints afetados vêm do pesquisador. O CERT/CC confirma o defeito central e a faixa de versões atingida.

Na data da publicação, não havia patch conhecido. O CERT/CC também informou que não conseguiu falar com o Casdoor para coordenar a correção. Por isso, o material disponível ainda não traz uma posição do fornecedor.

Se você opera Casdoor em modo multi-tenant, trate cada administrador de organização como alguém capaz de atravessar a separação atual. Até sair uma correção, reduza as contas administrativas, exija MFA, desligue concessões automáticas de privilégio e crie alertas para ações administrativas entre organizações. Uma regra no proxy comparando os identificadores pode ajudar como tripwire temporário. A interface legítima e as ações de administradores globais podem gerar falsos positivos nessa regra.

A correção de arquitetura é amarrar a autorização ao objeto canônico que a operação realmente recebe. Uma nova checagem na camada do objeto acrescenta defesa em profundidade. Conferir um nome na porta e executar outro no controller transforma uma policy correta numa decoração cara.

Fontes: CERT/CC VU#889462 e advisory da Voke Cyber sobre a CVE-2026-15630.

Destaques rápidos para hoje.

• PostgreSQL consegue deixar no log quem segurou o lock. Na versão 18, log_lock_waits vem desligado e registra esperas que passam de deadlock_timeout; log_lock_failures, também desligado, acrescenta detalhes para falhas de SELECT ... NOWAIT em linha. No PostgreSQL 19 beta 3, log_lock_waits deve vir ligado por padrão e preservar PID do bloqueador, fila de espera e contexto para depois do incidente. Baixar deadlock_timeout só para antecipar o log também faz a detecção de deadlock rodar mais vezes. E log_lock_failures ainda não cobre LOCK TABLE ... NOWAIT, cancelamentos por lock_timeout ou SKIP LOCKED; polling agressivo com NOWAIT pode transformar o log num chafariz. Fontes: documentação do PostgreSQL 18 e análise de Christophe Pettus.

• Rust 1.98.1 corrige código inválido gerado pelo compilador 1.98.0. Em algumas circunstâncias, uma vtable de trait object recebia um ponteiro nulo no lugar de um ponteiro de função. O resultado é comportamento indefinido e pode acabar em segmentation fault mesmo com código-fonte aparentemente seguro. Quem usa a 1.98.0 deve executar rustup update stable e reconstruir os artefatos afetados. A equipe não informou quantos crates ou binários caem nesse caso. Fonte: Rust Blog — Announcing Rust 1.98.1.

• Atualização de hook de agente é atualização de código executável. No threat model do HookPry, o atacante controla metadados públicos do plugin e a configuração de lifecycle hooks. Ele ainda depende da instalação do update e não pode alterar o harness, forjar resultados de ferramenta ou furar a sandbox. Em 1.000 execuções sobre sete harnesses, cinco backends e 25 combinações, os autores reportam efeitos confirmados em 77% dos casos e pico de 92,5% num harness. Hooks podem ligar comandos do host a eventos como início de sessão e edição de arquivo, fora da conversa que o modelo vê. Revise o diff do update, confirme as mudanças item por item e limite sandbox, permissões do sistema e rede. Prompt nenhum manda num comando executado por fora dele. Os números vêm de experimentos controlados de um preprint v1 e não mostram que toda instalação esteja comprometida; os autores ainda aguardavam resposta dos fornecedores. Fonte: A Blind Trust, the Bloody Thrust.

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