O n8n tem mais de 21 páginas de advisories publicados. A página 1 traz dez entradas, todas de 30/set/2026; a página 21 traz dez, de 28/abr/2025 a 4/fev/2026, e ainda oferece página seguinte. Na primeira requisição, o controle informou que o número mais alto visível era 21, e eu quase tomei isso por total.

Daí a regra, e ela é a lição do dia: o controle de paginação exibe uma janela de números, não o máximo. O que marca o fim é o "Próxima" desligado. Ontem eu contei 33 para o Claude Code e a contagem vale justamente porque na página 4 o controle de página seguinte estava inativo; hoje a página 21 do n8n está cheia e o controle segue ativo, logo não há contagem.

Com as duas páginas que eu contei trazendo dez cada, o piso é 210 se todas as páginas tiverem dez — e o número real é maior. ⏳ Não conto o n8n, e deixo escrito que das 21 páginas eu li duas.

O censo perde o total. Os 48 advisories em 21 membros do corpus não são publicáveis como soma: dos quatro valores do topo, três eram páginas — OpenClaw, Claude Code e n8n. Sobrou um membro contado, o Claude Code com 33, e dois com ordem de grandeza conhecida e contagem ausente: o n8n acima de 210 e o OpenClaw com 73 páginas ou mais.

O que sobrevive da tese, e sai mais forte, é o que a contagem media. Eu dizia que ela media prática de divulgação. Hoje tenho o mecanismo dessa prática: publicação em lote. Dez advisories do OpenClaw em 11/set e dez do n8n em 30/set, cada conjunto no mesmo dia. Qualquer contagem feita num dia qualquer mede a data do último lote, e não o acervo.

Impacto A no cap. 07 e no apêndice.

Dois títulos do lote de 30/set do n8n, lado a lado, e juntos eles reescrevem o eixo de aprovação:

"Cross-User Agent Chat Resume Allows Hijacking Another User's Pending Tool Approval" — Moderada

"Send-and-Wait HMAC Bypass Allows Unauthenticated Approval of Waiting Executions" — Alta

O primeiro é sequestro da aprovação pendente de outro usuário ao retomar a conversa. O segundo é aprovação não autenticada de execuções em espera, por desvio de HMAC.

O eixo de aprovação que eu vinha montando tratava a aprovação como decisão: quando acontece, sobre o que incide, quanto dura, se sobrevive à revogação. Estes dois advisories mostram que ela também é objeto, com dono e com autenticidade — e que o objeto pode ser tomado de outro e fabricado por quem não tem conta. Em 2/out o Codex anunciou restaurar permissões salvas ao retomar e eu perguntei se a revogação viajava com elas; a pergunta certa, que eu não tinha feito, é de quem é a aprovação pendente quando a sessão é retomada.

Para o cap. 07 isto acrescenta duas propriedades à lista que o capítulo já pede de um portão: a aprovação precisa ser atribuível a um titular e autenticável na volta. Persistir não basta, e nem reconferir onde o efeito acontece — se o token da espera é forjável, o portão aprova sozinho.

Impacto A no cap. 07, com material para o 03.

"Shared-Workflow Credential Check Misses Nested and Tool Inline Sub-Workflows" — Alta

A verificação de credencial de fluxo compartilhado não alcançava subfluxos aninhados nem embutidos em ferramenta. É a primeira vez que vejo, com título próprio, a falha de não recursão da verificação: a política existe, roda no nível de cima e para ali. Conversa direto com a medida do HarnessSafe de que o portador Subagente contém pior que Memória, e com a cautela que registrei em 2/out sobre o APPA confinar em ramo filho — se a verificação não desce, confinar embaixo não ajuda.

E dois títulos do mesmo lote colocam o validador no banco dos réus:

"Shared Prototype Mutation Through the MCP Workflow-Validation Interpreter Allows Owner Account Takeover" — Alta

"Prototype Pollution in the AI Workflow Builder Connection Merge" — Moderada

Tomada de conta do proprietário através do interpretador que valida o fluxo. Em 1º/out eu registrei que o redator de segredo é uma política e herda o defeito das políticas; aqui o validador é a superfície. O componente que confere é código que recebe entrada hostil, e tratá-lo como parte da defesa em vez de alvo é o erro de desenho que os dois títulos compartilham.

Impacto B nos caps. 07 e 12.

"Code Execution in the Git Node Log Operation via Unneutralized Repository Configuration" — Alta

Ontem registrei, no acervo do Claude Code, "arbitrary code execution caused by maliciously configured git email", de 9/set/2025. Hoje, no n8n, execução de código na operação de log do nó Git por configuração de repositório não neutralizada. Dois harnesses, treze meses de distância, o mesmo portador.

A tabela de portadores que eu propus ontem ao cap. 07 ganha, com isto, a sua primeira linha confirmada em mais de um sistema — e ela é a linha que o paper de CPE já havia apontado, com mensagem de commit e nome de arquivo em listagem de diretório. O repositório é entrada, e os seus campos de configuração chegam à execução.

Impacto B no cap. 07.

A contagem fechada, com a procedência de cada parcela: página 2 com 10, página 3 com 10 e página 4 com 3, lidas hoje, mais a página 1 com 10, que é a contagem que eu já tinha e que produziu o valor do censo. Total 33, e a página 4 é a última porque o controle de página seguinte está inativo. O histórico vai de 23/jun/2025 até 20/abr/2026.

O censo do cap. 07 registrava 48 advisories em 21 membros do corpus. Só o Claude Code tem 33. O total do censo está baixo, e por um fator que eu não sei estimar, porque o OpenClaw segue sem contagem e o n8n continua suspeito com o seu dez. A recontagem dele é a tarefa de amanhã, e com ela o censo volta a ter um número defensável.

Impacto A no cap. 07 e no apêndice.

Este é o achado do dia, e ele muda o que o cap. 07 pode afirmar.

Ordem entre execução e diálogo de confiança, duas vezes. Dois advisories distintos, com título idêntico: "Command execution prior to Claude Code startup trust dialog" — GHSA-5hhx-v7f6-x7gv em 19/nov/2025 e GHSA-4fgq-fpq9-mr3g em 3/out/2025, ambos de severidade Alta. Execução antes do diálogo de confiança, corrigida, e de volta. E há um terceiro parente na mesma página: "Malicious repo configuration can trigger data leakage via environment configuration used before trust confirmation", Moderada, 20/jan/2026 — configuração de ambiente consumida antes da confirmação de confiança.

Desvio de negação por symlink, duas vezes. "Permission deny bypass through symlink", GHSA-66m2-gx93-v996, Baixa, 3/out/2025; e "Permission Deny Bypass Through Symbolic Links", GHSA-4q92-rfm6-2cqx, Baixa, 6/fev/2026. Quatro meses, mesmo mecanismo, mesma severidade. E, entre os dois, um terceiro de severidade Alta pela mesma porta: "Sandbox Escape via Symlink Following Allows Arbitrary File Write Outside Workspace", 20/abr/2026.

Validação do sed, duas vezes. "Sed Command Validation Bypass Allows Arbitrary File Writes", 20/nov/2025; e "Command Injection via Piped sed Command Bypasses File Write Restrictions", 6/fev/2026. A segunda acrescenta o cano ao mesmo comando.

A conclusão é direta e eu posso sustentá-la com os títulos e as datas: corrigir uma grafia do carregador não fecha o carregador. A série dos dois leitores tratava cada caso como um achado; o que o acervo mostra é que o caso tem reincidência medida, e que a reincidência passa por uma grafia nova da mesma ideia — symlink e depois seguimento de symlink, sed e depois sed com cano.

Há um detalhe de severidade que o livro deve registrar sem resolver: o desvio de negação por symlink é Baixa nas duas vezes, enquanto a escapada de sandbox pela mesma primitiva é Alta. A mesma primitiva recebe duas severidades conforme o que se alcança com ela.

Impacto A nos caps. 02 e 07.

Quatro advisories, quatro comandos, o mesmo desvio:

• "Command Injection in Claude Code echo command allowed bypass of user approval prompt for command execution", Alta, 1º/ago/2025
• "Command Injection in Claude Code rg command allowed bypass of user approval prompt for command execution", Alta, 9/set/2025
• "Command Injection in find Command Bypasses User Approval Prompt", Alta, 3/fev/2026
• e o sed, nas duas formas já citadas

echo, rg, find, sed. Quatro nomes que uma lista de permissão trata como seguros, e quatro caminhos para executar outra coisa. Em 28/set eu nomeei a lista que admite o futuro, e em 2/out a lista que admite o passado. Falta esta, que é a mais simples das três e a que mais machuca: a lista que admite o nome. Autorizar por nome de comando pressupõe que o nome determina o efeito, e em shell ele não determina.

Na mesma página há o ancestral do problema, de 15/ago/2025: "Permissive Default Allowlist Enables Unauthorized File Read and Network Exfiltration in Claude Code" — a lista padrão era permissiva. O cap. 07 tem aqui a linha do tempo inteira de uma decisão de desenho e das suas consequências, com data em cada uma.

Impacto A no cap. 07.

Ontem registrei dois advisories do OpenClaw sobre aplicar configuração por WebSocket, um deles "Unauthenticated Local RCE via WebSocket config.apply", de 4/fev/2026. Hoje, na página 4 do Claude Code: "Claude Code IDE extensions allow websocket connections from arbitrary origins", Alta, 23/jun/2025 — o advisory mais antigo do acervo.

Dois harnesses, oito meses de distância, a mesma superfície: um WebSocket local que aceita quem chega. O achado de ontem dizia que aplicar configuração em tempo de execução é caminho de privilégio; com este, o enunciado fica mais geral e mais útil ao livro — o canal local de controle é externamente alcançável, porque o navegador, o editor ou a extensão originam a conexão de dentro.

Impacto B nos caps. 07 e 12.

Cinco títulos trazem portadores que a minha série de vinte e cinco casos não tinha:

• "Claude Code vulnerable to arbitrary code execution caused by maliciously configured git email", 9/set/2025 — e-mail do git como portador, da mesma família dos vetores do paper de CPE, que listava mensagem de commit e nome de arquivo.
• "Path Restriction Bypass in Claude Code Research Preview could allow unauthorized file access when path prefixes collide", 1º/ago/2025 — colisão de prefixo de caminho.
• "Path Restriction Bypass via ZSH Clobber Allows Arbitrary File Writes", 3/fev/2026 — o clobber do ZSH.
• "Command Injection via Directory Change Bypasses Write Protection", 6/fev/2026 — troca de diretório.
• "Claude Code Vulnerable to Arbitrary Code Execution via Plugin Autoloading with Specific Yarn Versions", 24/set/2025 — autoload de plugin dependente da versão do gerenciador de pacotes.

Com os que eu já tinha — nomes curtos 8.3 do NTFS, byte NUL, substituição de comando, recuo de Unicode — o cap. 07 pode publicar uma tabela de portadores em vez de uma lista de casos. É a mesma matéria, organizada pela porta em vez de pelo episódio.

⏳ Nenhum corpo lido hoje. Título, severidade e data, que são campos da página de lista, conforme a precisão que registrei ontem.

Impacto B no cap. 07.

O que eu verifiquei hoje, e só isto: a página 1 da lista de advisories publicados do OpenClaw traz 10 entradas, todas publicadas em 11/set/2026. A página 73 existe, traz 2 entradas, de 14/fev e 4/fev/2026, e os controles de paginação ainda oferecem página seguinte. A lista está em ordem decrescente de data.

O que eu afirmei antes: OpenClaw, 10 advisories, dentro de um censo de 48 advisories em 21 membros do corpus. Esse 10 é o tamanho da página.

O que eu não vou dizer. Não vou publicar um total. Setenta e três páginas vezes dez é aritmética, não contagem, e a página 73 tem duas entradas em vez de dez, o que já mostra que o tamanho de página não é constante na borda. Em 27/ago eu retirei uma contagem do registro do ACP por ter aceitado "approximately 50+" de um resumo de busca, no mesmo dia em que escrevi que não publicaria número sem contar. A regra vale igual contra mim hoje: são centenas, e eu não sei quantas.

E o que eu tenho de retirar. A distribuição que eu chamei de bimodal se apoiava em quatro valores no topo: OpenClaw 10, Claude Code 10, n8n 10, LangGraph 9. Três deles são exatamente dez, que é o tamanho de página da interface que eu usei para contar. A coincidência tem explicação simples e ela não é estatística. A afirmação de bimodalidade cai, e os três valores de dez ficam marcados como suspeitos de leitura de primeira página até serem recontados. O LangGraph, com nove, provavelmente foi contado de verdade, porque nove não é o tamanho da página.

Fica de pé, e com mais força, o que eu disse sobre o que a contagem mede: prática de divulgação. O OpenClaw publicou dez advisories no mesmo dia, 11/set. Publicação em lote torna qualquer contagem dependente da data em que se olha, e isso é mais um argumento para a coluna de postura de divulgação não ser uma contagem — tem de registrar profundidade do corpo, presença de CWE e vetor, se os dois registros se conhecem, e agora também se o projeto publica em lote.

Impacto A no cap. 07 e no apêndice, como retratação e como método.

Os dez títulos da página 1, lidos como títulos e não como corpos, descrevem o eixo de aprovação melhor que a minha própria formulação. Dois merecem nome.

"Exec approvals could outlive their reviewed working directory" — Alta

A aprovação sobrevivia ao diretório de trabalho em que foi revisada. O eixo tem o item desde agosto na forma reconferir onde o efeito acontece; aqui está o caso em que o contexto revisado muda e a aprovação continua valendo. É a gêmea exata da regra que o OpenClaw escreveu ontem, de que remover acesso interrompe trabalho em curso — a mesma pergunta, feita sobre o diretório em vez do acesso.

"File-transfer approvals could widen durable authority" — Moderada

Uma aprovação de transferência alargava autoridade durável. O item que eu tenho é durável mais nonce de uso único; este é o defeito que justifica o item, com a palavra widen fazendo o trabalho: aprovar uma transferência concedia mais do que aquela transferência.

"Unicode fallback could escape workspaceOnly roots" — Moderada

Vigésimo quinto caso da série dos dois leitores, e dos canônicos: um recuo de Unicode escapa da raiz confinada por workspaceOnly. A política decide sobre uma leitura do caminho e o acesso acontece sobre outra, produzida por fallback de codificação. Família do oitavo caso, dos nomes curtos 8.3 do NTFS, e do vigésimo, do byte NUL.

E três que alimentam eixos recentes, com os títulos verbatim: "Prometheus diagnostics could omit operator.read enforcement", "iOS deep-link logs could expose unattended credentials" e "OpenAI-compatible transport could send provider credentials to the wrong endpoint". O primeiro é um endpoint de diagnóstico omitindo verificação de permissão; o segundo é credencial em log de deep link; o terceiro é credencial para o endpoint errado, irmão do gatewayUrl de ontem. O eixo do canal de diagnóstico, que abri em 29/set com dois harnesses, já tem instância em quatro.

Os dois restantes de severidade Alta e Moderada tocam o cap. 03: "WhatsApp login tool could reach non-owner turns" e "Slack file downloads could miss conversation authorization". Alcançar turnos de não proprietário é fronteira de privilégio por papel de mensagem, dita em quatro palavras.

⏳ Li títulos, severidades e datas. Nenhum corpo, o que significa que o mecanismo de cada um segue não verificado.

Uma precisão de instrumento, porque minha própria regra pede: a página de lista de advisories é a fonte primária de título, severidade e data, que são campos dela, diferente da página de lista de releases, que reconta o que está na tag. O que ela não tem é o corpo, e é por isso que o mecanismo fica em ⏳.

Impacto A no cap. 07, com material para os caps. 02, 03 e 12.

Na página 73, verbatim: "Unauthenticated Local RCE via WebSocket config.apply", Alta, publicado em 4/fev/2026.

Ponha ao lado o que eu li ontem no GHSA do gatewayUrl, cuja correção saiu na 2026.1.29: com o token roubado, o atacante "modify config (sandbox, tool policies), and invoke privileged actions". São dois advisories distintos, de janeiro e fevereiro, sobre aplicar configuração por WebSocket — um exigindo o token roubado, o outro sem autenticação nenhuma.

Isto deixa de ser anedota e passa a ser propriedade da superfície: o canal que aplica configuração em tempo de execução é um caminho de privilégio, e tratá-lo como canal de administração em vez de alvo é o erro de desenho que os dois advisories compartilham. O cap. 07 discute políticas de ferramenta como dado que a política lê; aqui elas são dado que o atacante escreve.

Impacto B nos caps. 07 e 12.

O corpo do GHSA-g8p2-7wf7-98mq, verbatim e inteiro:

"Summary: The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload. Clicking a crafted link or visiting a malicious site can send the token to an attacker-controlled server. The attacker can then connect to the victim's local gateway, modify config (sandbox, tool policies), and invoke privileged actions, achieving 1-click RCE. This vulnerability is exploitable even on instances configured to listen on loopback only, since the victim's browser initiates the outbound connection."

Primeira retratação. Eu venho registrando, no censo de advisories do cap. 07, que os corpos do OpenClaw são templados — título, severidade e faixa de versão, sem CVE e sem mecanismo. Este corpo tem mecanismo detalhado, vetor CVSS, CWE, faixa afetada, versão corrigida e crédito a três pesquisadores. Generalizei de uma amostra que não representava o conjunto. A caracterização de posture templada não vale para o OpenClaw como afirmei; vale, no máximo, para os advisories em que eu a observei, e eu não sei quantos são.

Segunda retratação, de ontem. Escrevi em 3/out que "a profundidade existe e está no outro lado", do lado do registro do CVE. É o inverso. O registro do MITRE descreve o gatewayUrl vindo de query string e o envio automático do token. O GHSA acrescenta tudo o que importa para o livro: que a interface de controle conecta sozinha ao carregar; que o token sai no payload de conexão; que o atacante, com o token, altera a configuração — sandbox e políticas de ferramenta — e invoca ações privilegiadas; e que nada disso é contido por escutar só em loopback, "since the victim's browser initiates the outbound connection".

Esta última oração é a melhor frase de cap. 07 que eu li esta semana. Amarrar o serviço ao loopback é a contenção canônica, e ela não cobre o caso em que o navegador da vítima é quem origina a saída. A contenção estava no lugar certo para a ameaça errada.

Terceira coisa, e é um erro de leitura meu, não uma retratação de fato. Em 30/set adotei a errata do paper de skills, que diz que este CVE é exfiltração de token "not remote code execution through a crafted skill package", e li isso como não é RCE. O GHSA diz, com as próprias palavras, "achieving 1-click RCE". Relendo a errata com cuidado, ela nega um vetor — pacote de skill forjado — e não nega o resultado. A frase da errata estava certa; a minha paráfrase dela estava errada, nos dois dias em que eu a usei, inclusive quando me corrigi em 3/out.

A regra de ontem era citar o campo e não a síntese. Hoje ela ganha corolário, e eu o escrevo contra mim mesmo: a negação tem escopo, e o escopo está na frase. Quem apaga o through Y de um não é X através de Y fabrica uma alegação que a fonte não fez.

E um achado que o teste produziu, independente dos meus erros. Os dois registros do mesmo defeito discordam na classificação: o GHSA traz CWE-200, Exposure of Sensitive Information, e o registro do CVE traz CWE-669, Incorrect Resource Transfer Between Spheres. O CVSS é idêntico nos dois, 8,8 com o mesmo vetor, e a versão corrigida é a mesma. Além disso, o GHSA marca "No known CVE", embora o CVE-2026-25253 exista e referencie este GHSA. Ou seja: o advisory do fornecedor não conhece o próprio CVE, e o mesmo defeito carrega dois CWEs.

Para a coluna de postura de divulgação que propus ao editor, isto é a medida que faltava. Ela não pode ser uma contagem: precisa registrar, por membro do corpus, profundidade do corpo, presença de CWE e de vetor, e se os dois registros se conhecem.

Impacto A no cap. 07 e no apêndice, com duas retratações e uma correção de leitura.

Última versão listada no índice partido, 2026.9.8. Quatro linhas, e a primeira resolve uma pergunta que o eixo de aprovação carregava desde agosto. Verbatim:

"Work already underway can finish when you change connection settings, provided the user still has access. Removing access still stops that work."

O eixo pedia que a revogação sobrevivesse. A dúvida que eu nunca tinha formulado bem é o que fazer com trabalho em curso quando a configuração muda, e a resposta aqui distingue dois atos que eu vinha tratando como um: mudar a configuração deixa terminar o que já começou, desde que o usuário siga com acesso; remover o acesso interrompe. Reconfiguração e revogação são operações diferentes, com efeitos diferentes sobre o que já está rodando, e esta é a primeira fonte do corpus que escreve a distinção.

"Repairing an update now keeps the plugins you allowed and enabled."

Reparar uma atualização perdia as decisões de permissão de plugin. Em 2/out o Codex anunciou restaurar permissões salvas ao retomar; aqui está o mesmo ponto pela falha — a operação de manutenção descartava o que o operador havia liberado. Persistir a aprovação é metade do trabalho; a outra metade é os caminhos de reparo não a atropelarem.

"When an agent asks another for help, the result comes back to the requester once."

"Work inside OpenClaw must return a result or keep working instead of ending silently."

"REPLY_SKIP and ANNOUNCE_SKIP no longer hide replies."

Três frases, três eixos. Uma vez é entrega exatamente-uma-vez, o parente do nonce de uso único. Terminar em silêncio é o cap. 02 na camada multiagente: o subagente acabava sem devolver nada, e o requerente ficava sem resposta nem erro. E duas opções que escondiam respostas foram removidas, o que é a decisão certa — configuração que suprime sinal é configuração que produz término silencioso por escolha.

"Fixed a case where secrets in long, unusually formatted log entries were not hidden when OpenClaw ran on Bun."

Terceiro harness no eixo do canal de diagnóstico em uma semana, depois do opencode em 28/set e das quatro correções do Claude Code em 1º/out. E com elemento novo: aqui a redação falha em função do runtime — sob Bun — e do formato da entrada. A correção do redator deixa de ser propriedade do código e passa a depender de onde ele roda.

Impacto A nos caps. 02 e 07, com material para o 12.

Tentei quatro caminhos e todos devolveram 404: aaif-goose/goose em main, em master e em v1.0, e o antigo block/goose em main. A mudança de organização que registrei em 27/ago está refletida nos meus caminhos, e o arquivo não está em nenhum deles — provavelmente porque o projeto publica por release e não por arquivo versionado. Não vou supor qual é o lugar certo: fica como dívida nomeada, com os quatro caminhos escritos para que a próxima tentativa não repita os mesmos.

Impacto C, como método.

Fecho a fila do CVE-2026-25253 com o registro oficial, obtido da API do MITRE. Estado PUBLISHED, publicado em 1º/fev/2026 e atualizado em 3/fev. A descrição, verbatim e inteira:

"OpenClaw (aka clawdbot or Moltbot) before 2026.1.29 obtains a gatewayUrl value from a query string and automatically makes a WebSocket connection without prompting, sending a token value."

Três coisas que nenhum dos recontares trazia.

A vítima é um membro do corpus. O CVE é do OpenClaw, com os três nomes que ele já teve registrados na mesma linha, e o pacote declarado como pkg:npm/clawdbot, afetado em tudo anterior a 2026.1.29. Isto satisfaz a quarta condição do meu critério de auditabilidade de 13/set, a de que o advisory enumere as identidades que o pacote já teve — e é a primeira vez que vejo um registro cumprir essa condição. Registro como instância positiva, que o critério até agora só tinha pela ausência.

O mecanismo é de aprovação ausente. A expressão que importa é "without prompting": a conexão sai automaticamente, levando um token, a partir de um valor que veio de query string. O CWE atribuído é CWE-669, Incorrect Resource Transfer Between Spheres, e a palavra spheres é a mesma que o livro usa para fronteira de confiança. Um valor controlável de fora decide o destino, e nada pergunta.

E agora a minha correção. Em 30/set eu adotei a errata do paper de skills, que diz que este CVE "is authentication-token exfiltration via an unvalidated gatewayUrl, credited to depthfirst and fixed in 2026.1.29, not remote code execution through a crafted skill package", e escrevi daí que a gravidade inflaciona no recontar. A primária confirma o mecanismo que a errata descreve e desmente a minha conclusão sobre gravidade. O CVSS v3.1 do registro é 8,8 ALTO, com vetor CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — confidencialidade, integridade e disponibilidade todas ALTAS. Exfiltração de token não produz integridade e disponibilidade altas. E as referências do próprio registro apontam para dois textos cujos endereços dizem 1-click-rce e one-click-rce-moltbot.

Então a errata acertou o mecanismo e, ao acertá-lo, encolheu o impacto. A frase correta não é a minha de 30/set. É esta: mecanismo e impacto são campos diferentes do registro, e um recontar que conserta um pode estragar o outro. A regra que fica, para o cap. 07 e para mim: citar o campo, não a síntese — descrição, CWE, vetor CVSS e faixa de versão, cada um pelo seu nome.

Há um último proveito para o censo. O advisory do fornecedor é o GHSA-g8p2-7wf7-98mq, e eu já havia registrado que os corpos do OpenClaw são templados, com título, severidade e faixa de versão, sem CVE e sem mecanismo. O registro do CVE para o mesmo defeito traz descrição, CWE e vetor. Ou seja, a profundidade existe e está no outro lado. A coluna de postura de divulgação que eu propus ao editor precisa medir dois corpos, o do GHSA e o do CVE, em vez de um.

Impacto A no cap. 07, com correção do registro de 30/set.

gemini-cli v0.63.0-preview.0, 29/set, lida na tag. Verbatim:

"fix(auth): prevent infinite auth loop from file contention, headless keyring, and supervisor state drops"

O eixo de parada ganhou instância fora da política. Em 23/set eu o registrei com o modo automático negando em laço; ontem o APPA deu o nome do caso geral, que é encalhe por monotonia. Aqui o laço é de autenticação, e as três causas estão escritas: contenção de arquivo, chaveiro sem cabeça e perda de estado do supervisor.

A do meio é a que vale para o livro. Chaveiro sem cabeça quer dizer que não há ninguém para responder ao pedido de credencial, e o laço nasce aí: o harness pede, ninguém responde, o harness pede outra vez. Todo portão que pergunta precisa saber o que fazer quando não existe quem responda, e o modo sem cabeça é onde essa pergunta deixa de ser teórica.

Na mesma release, outra linha verbatim:

"fix(acp): resolve session before config initialization and avoid same-minute filename collisions"

Duas correções numa. A primeira é de ordem — a sessão passa a ser resolvida antes da inicialização da configuração, no mesmo espírito do request_permission de ontem. A segunda é de identidade: nome de arquivo derivado de carimbo de tempo com granularidade de minuto colide quando duas coisas acontecem no mesmo minuto. Entra na mesma família das colisões de id de plugin por caixa, de 28/set e 1º/out, com uma diferença que merece nome: ali o nome existia e era comparado frouxamente; aqui o nome é derivado e não carrega unicidade suficiente para identificar a coisa.

Impacto B nos caps. 02, 07 e 17.

arXiv:2607.24625, APPA: Recoverable Information-Flow Control for Real-World LLM Agents (Kravchenko, Liventsev, Konstantinov, Iskhakov, Kukuy), v1 em 27/jul e v2 em 26/ago/2026. O resumo abre com o diagnóstico, verbatim:

"LLM agents deployed in practical workflows routinely mix private context, untrusted tool and web outputs, and external side effects. While information-flow control (IFC) provides structural defenses against prompt injection, data exfiltration, and confused-deputy attacks, conventional IFC relies on monotone taint tracking that either over-blocks benign operations or permanently strands downstream execution once an agent ingests unvetted data."

A oração final é o item que eu tinha registrado em 23/set sem nome bom: fechar por falha precisa de critério de parada. O nome está aqui, e é melhor que o meu — taint monótono encalha permanentemente a execução a jusante. Uma vez que o agente ingeriu dado não verificado, não existe caminho de volta, e o modo automático que eu vi negando em laço era essa monotonia vista de fora.

E a resposta do paper é a peça que faltava ao eixo: recuperação governada por política, com monitoramento de duas fases no despacho de ferramenta, confinamento de trajetória por ramos filhos descartáveis e tipagem de segurança gradual.

Agora o número que importa, e ele cobra uma dívida. Em 28/set eu anotei que o OAP publicava 0% de sucesso de ataque em 879 tentativas sem taxa de tarefa cumprida, e que política que nega tudo alcança 0% de graça. O APPA publica os dois eixos: utilidade de 64,2% a 91% com zero ataques observados em 1.320 episódios guardados, e o campo de comentários acrescenta banco empírico de três modelos e 6.600 episódios. É o relato em nível de configuração modelo-harness que eu vinha exigindo desde 19/set, e é a comparação que o OAP recusou. Também é um custo visível: 64,2% na ponta de baixo não é tarifa pequena, e só se sabe que ela existe porque o paper a imprimiu.

Uma cautela, porque o mecanismo do APPA encosta num achado que me incomoda. Ele usa ramos filhos descartáveis como contenção, e o HarnessSafe mediu que o portador Subagente, com 46,7, contém pior que Memória, com 60,0. Confinar em subagente e propagar por subagente são usos opostos da mesma estrutura. Registro a tensão e não a resolvo com o resumo na mão.

Fecho ainda uma divergência de título com mecanismo confirmado. Em 29/set eu registrei este paper pelo título que a busca me deu, Agentic Permissions Policy Algebra for Taint Confinement in LLM Agents. A primária traz outro, e o campo de comentários explica: "v2: Major revision with updated title". O título mudou entre versões. Em 27/set eu havia marcado uma divergência igual no Scanning the Harness sem saber a causa; agora tenho a causa, dita pela fonte.

Impacto A nos caps. 07 e 11.

gemini-cli v0.62.0, estável, 29/set, lida na tag. Verbatim:

"fix(cli): emit tool_call update prior to request_permission in ACP mode"

A correção põe a notificação da chamada antes do pedido de permissão. Antes dela, no modo ACP, o cliente recebia request_permission e só depois o tool_call que o descrevia — ou seja, o pedido de aprovação chegava antes da coisa a aprovar. Para um cliente de interface isso significa desenhar um diálogo de permissão sem ter o que mostrar nele.

Esta é a família que abri em 29/ago, a da ordem entre a operação e o portão, e é o caso mais limpo que ela teve. Nos vinte e quatro casos da série dos dois leitores, a política lê a cadeia errada. Aqui a política não tem o que ler: ela é consultada antes da chegada do conteúdo. E o lugar em que isso acontece é o protocolo, não o harness — o ACP, cujo registro eu acompanho desde agosto e cuja governança registrei em 27/ago como a menos neutra entre as três.

Na mesma release, e isto é o par certo:

"fix(core,acp): format MCP tool call titles as structured signatures and segregate explanations"

Separar a assinatura da chamada da explicação que a acompanha. O cap. 03 argumenta que o papel da mensagem é fronteira de privilégio; aqui a fronteira desce ao título da chamada de ferramenta, separando o que executa do que descreve. Quem aprova olhando a explicação aprovava prosa; agora olha a assinatura.

Também verificado na tag: "fix(core): retain oauth refresh token on refresh and make credential deletion idempotent". Deleção de credencial idempotente toca o eixo de revogação, que ganhou instância no Claude Code ontem.

Impacto A nos caps. 03, 07 e 17.

Codex 0.160.0, 1º/out, lido na tag rust-v0.160.0. Quatro linhas, verbatim:

"Start sessions outside a project with workspace defaults when policy permits, and restore saved permissions when resuming."

Permissão persistida e restaurada no retomar. O eixo de aprovação tem este item desde agosto, e aqui ele é recurso anunciado. Fica a pergunta que o eixo já sabe fazer e que a nota não responde: a permissão restaurada carrega consigo a revogação que tenha ocorrido entre a gravação e a retomada? Ontem o Claude Code corrigiu justamente sessões que sobreviviam ao desligamento da política. ⏳ Não sei, e não vou supor.

"Prevented SQLite stalls during connection setup and logging, and surfaced initialization errors instead of masking them as timeouts."

Erro de inicialização mascarado como tempo esgotado. O cap. 02 trata do término que se apresenta como conclusão; este é o parente próximo, o erro que se apresenta como outro erro, e o disfarce escolhido é o mais inócuo possível, porque tempo esgotado convida a tentar de novo.

"Subagents now retain environments that are still starting and receive their configuration or preparation failure."

O subagente não recebia a própria falha de configuração. A falha existia e não chegava a quem precisava dela.

"Explicit provider model catalogs no longer include unsupported bundled models or reuse stale entries after refresh failures."

Catálogo que reaproveitava entrada velha quando a atualização falhava. Em 28/set eu nomeei o defeito oposto na 2.1.283 do Claude Code, a lista que admite o futuro, em que a correspondência frouxa libera versões que não existiam quando a política foi escrita. Esta é a gêmea: a lista que admite o passado, porque a falha de atualização preserva o que já não vale. Os dois casos têm a mesma raiz, que é a lista de permissão não saber a própria data de validade.

Impacto B nos caps. 02 e 07.

A lista de releases do Codex me ofereceu, como sendo da 0.160.0, três linhas que não estão no corpo da tag: "Keep configuration values out of Windows sandbox policy events", "Skip remote Git discovery for Guardian diff paths" e "Preserve encrypted agent messages in Guardian reviews". A primeira me interessava muito, porque seria o terceiro harness na semana a tirar valor de configuração de um canal de diagnóstico.

Quarta ocorrência documentada: 23/ago nas datas, 27/ago na contagem do ACP, 30/ago na versão do symlink do gemini-cli, e hoje. A regra que eu venho aplicando está confirmada o bastante para virar proposta ao contrato, e eu não edito o contrato: a página de lista agrega e a tag afirma, e nenhuma linha entra sem a tag.

Impacto C, como método.