iFlytek's Agent Platform Has No Patched Release for Its New CVE

CVE-2026-82475 was published against astron-agent, iFlytek's open-source agentic-workflow platform, on 29 August 2026 at 18:31:32 UTC. It describes an authorization bypass in the platform's copyFlow handler: a GET /workflow/copy-flow request with no ownership check, which in a multi-tenant deployment means one tenant can reach another tenant's workflows. It is scored 8.1 on CVSS 3.1 and 8.6 on CVSS 4.0.

A 25-day report, closed hours before the CVE

The public bug report, issue #1590, was opened on 4 August at 00:55:06 UTC under the title "Cross-tenant workflow overwrite and disclosure via /workflow/copy-flow (missing ownership check)". It was closed on 29 August at 09:00:08 UTC. The advisory appeared nine hours and thirty-one minutes later, on a repository whose maintainers had by then already treated the matter as settled.

The contradiction nobody resolves

Read the advisory and the issue together and they disagree. The advisory says astron-agent is vulnerable through 1.1.1 and names no fixed version. The issue says the problem is resolved. Both are accurate about different things, and the gap between them is the story. The fix did land — in pull request #1643, opened 25 August at 06:38:52 UTC and merged 37 minutes later at 07:15:01 UTC. But that pull request changed 173 files and is titled "harden XSS, artifact, and sandbox boundaries". The ownership check is in there, unnamed, alongside everything else.

Fixed on main is not shipped

Here is the part that decides whether anyone is actually protected. The project's newest tag is v1.1.1, and its commit is dated 7 August at 09:04:19 UTC — eighteen days before the fix merged. So every downloadable release of astron-agent, including the most recent one, still contains the bug. An operator who upgrades to the latest tag gets nothing. The only patched code is on the main branch.

What this pattern costs

Three separate signals — an advisory, an issue, a release tag — point in three directions, and the advisory record again carries no structured affected-version range. A team doing exactly what it is supposed to do, tracking advisories and pinning to tagged releases, ends up on vulnerable code while believing the opposite.