CVE-2026-82475 se publicó contra astron-agent, la plataforma de flujos de trabajo agénticos de código abierto de iFlytek, el 29 de agosto de 2026 a las 18:31:32 UTC. Describe una omisión de autorización en el controlador copyFlow de la plataforma: una solicitud GET /workflow/copy-flow sin comprobación de propiedad, lo que en una implementación multiinquilino significa que un inquilino puede acceder a los flujos de trabajo de otro. Tiene una puntuación de 8.1 en CVSS 3.1 y de 8.6 en CVSS 4.0.

Un informe de 25 días, cerrado horas antes del CVE

El informe público del error, la incidencia #1590, se abrió el 4 de agosto a las 00:55:06 UTC con el título "Cross-tenant workflow overwrite and disclosure via /workflow/copy-flow (missing ownership check)". Se cerró el 29 de agosto a las 09:00:08 UTC. El aviso apareció nueve horas y treinta y un minutos después, en un repositorio cuyos responsables ya habían considerado el asunto resuelto.

La contradicción que nadie resuelve

Si se lee conjuntamente el aviso y la incidencia, discrepan. El aviso dice que astron-agent es vulnerable hasta la 1.1.1 y no señala ninguna versión corregida. La incidencia afirma que el problema está resuelto. Ambas afirmaciones son correctas sobre cosas distintas, y la distancia entre ellas es la historia. El arreglo sí llegó, en la solicitud de incorporación #1643, abierta el 25 de agosto a las 06:38:52 UTC y fusionada 37 minutos después, a las 07:15:01 UTC. Pero esa solicitud modificó 173 archivos y lleva por título "harden XSS, artifact, and sandbox boundaries". La comprobación de propiedad está ahí, sin nombre, junto con todo lo demás.

Corregido en main no significa publicado

Esta es la parte que decide si alguien está realmente protegido. La etiqueta más reciente del proyecto es v1.1.1, y su commit está fechado el 7 de agosto a las 09:04:19 UTC, dieciocho días antes de que se fusionara la corrección. Así que todas las versiones descargables de astron-agent, incluida la más reciente, siguen conteniendo el fallo. Quien actualice a la etiqueta más reciente no obtiene nada. El único código parcheado está en la rama main.

Lo que cuesta este patrón

Tres señales distintas —un aviso, una incidencia y una etiqueta de versión— apuntan en tres direcciones, y el registro del aviso vuelve a no incluir ningún intervalo estructurado de versiones afectadas. Un equipo que hace exactamente lo que se supone que debe hacer, seguir los avisos y fijarse en versiones etiquetadas, acaba usando código vulnerable mientras cree lo contrario.