CVE-2026-82475 foi divulgado para o astron-agent, a plataforma open source de fluxos de trabalho agênticos da iFlytek, em 29 de agosto de 2026 às 18:31:32 UTC. Ele descreve uma تجاوز de autorização no manipulador copyFlow da plataforma: uma solicitação GET /workflow/copy-flow sem verificação de titularidade, o que, em uma implantação multitenant, significa que um tenant pode acessar os fluxos de trabalho de outro. A pontuação é de 8,1 no CVSS 3.1 e 8,6 no CVSS 4.0.

Um relatório de 25 dias, encerrado horas antes do CVE

O relatório público de bug, issue #1590, foi aberto em 4 de agosto às 00:55:06 UTC com o título "Cross-tenant workflow overwrite and disclosure via /workflow/copy-flow (missing ownership check)". Ele foi encerrado em 29 de agosto às 09:00:08 UTC. O aviso apareceu nove horas e trinta e um minutos depois, em um repositório cujos mantenedores já tratavam a questão como resolvida.

A contradição que ninguém resolve

Leia o aviso e o issue em conjunto, e eles divergem. O aviso diz que o astron-agent é vulnerável até a versão 1.1.1 e não menciona nenhuma versão corrigida. O issue diz que o problema foi resolvido. Ambos estão corretos sobre coisas diferentes, e a lacuna entre eles é a história. A correção de fato entrou — no pull request #1643, aberto em 25 de agosto às 06:38:52 UTC e mesclado 37 minutos depois, às 07:15:01 UTC. Mas esse pull request alterou 173 arquivos e tem o título "harden XSS, artifact, and sandbox boundaries". A verificação de titularidade está lá, sem nome, ao lado de tudo o mais.

Corrigido na main não significa distribuído

Aqui está a parte que decide se alguém está de fato protegido. A tag mais recente do projeto é v1.1.1, e seu commit está datado de 7 de agosto às 09:04:19 UTC — dezoito dias antes da mesclagem da correção. Portanto, toda versão baixável do astron-agent, inclusive a mais recente, ainda contém o bug. Um operador que atualize para a última tag não recebe nada. O único código corrigido está na branch main.

O custo desse padrão

Três sinais separados — um aviso, um issue, uma tag de release — apontam em três direções, e o registro do aviso novamente não traz nenhuma faixa estruturada de versões afetadas. Uma equipe fazendo exatamente o que deveria fazer, acompanhando avisos e fixando versões etiquetadas, acaba em código vulnerável enquanto acredita no contrário.