CVE-2026-82475 è stata pubblicata contro astron-agent, la piattaforma open-source di workflow agentici di iFlytek, il 29 agosto 2026 alle 18:31:32 UTC. Descrive un bypass dell'autorizzazione nel gestore copyFlow della piattaforma: una richiesta GET /workflow/copy-flow senza controllo della proprietà, il che in un'implementazione multi-tenant significa che un tenant può accedere ai workflow di un altro tenant. Il punteggio è 8.1 su CVSS 3.1 e 8.6 su CVSS 4.0.

Un report di 25 giorni, chiuso poche ore prima della CVE

Il bug report pubblico, issue #1590, è stato aperto il 4 agosto alle 00:55:06 UTC con il titolo "Cross-tenant workflow overwrite and disclosure via /workflow/copy-flow (missing ownership check)". È stato chiuso il 29 agosto alle 09:00:08 UTC. L'avviso è apparso nove ore e trentuno minuti più tardi, su un repository i cui manutentori, a quel punto, avevano già considerato la questione risolta.

La contraddizione che nessuno risolve

Letti insieme, l'avviso e l'issue si contraddicono. L'avviso dice che astron-agent è vulnerabile fino alla 1.1.1 e non indica alcuna versione corretta. L'issue dice che il problema è risolto. Entrambi sono corretti rispetto a cose diverse, e il divario tra le due cose è la storia. La correzione è arrivata — nella pull request #1643, aperta il 25 agosto alle 06:38:52 UTC e mergiata 37 minuti dopo, alle 07:15:01 UTC. Ma quella pull request ha modificato 173 file ed è intitolata "harden XSS, artifact, and sandbox boundaries". Il controllo della proprietà è lì, senza essere nominato, insieme a tutto il resto.

Corretto su main non significa distribuito

Ecco il punto che decide se qualcuno sia davvero protetto. Il tag più recente del progetto è v1.1.1, e il suo commit è datato 7 agosto alle 09:04:19 UTC — diciotto giorni prima della fusione della correzione. Quindi ogni release scaricabile di astron-agent, compresa la più recente, contiene ancora il bug. Un operatore che aggiorni all'ultimo tag non ottiene nulla. L'unico codice corretto si trova sul branch main.

Quanto costa questo schema

Tre segnali separati — un avviso, un issue, un tag di release — puntano in tre direzioni, e il record dell'avviso riporta ancora una volta nessun intervallo strutturato delle versioni interessate. Un team che fa esattamente ciò che dovrebbe fare, seguendo gli avvisi e bloccandosi su release con tag, finisce su codice vulnerabile credendo il contrario.