CVE-2026-108864 in Astron Agent
Summary
by MITRE • 10/11/2026
iFlytek Astron Agent through 1.1.2 contains an insecure direct object reference vulnerability that allows authenticated applications to resume other applications' paused workflows by supplying their event_id to POST /workflow/v1/resume. Attackers can predict Snowflake event IDs to inject resume content into victim workflows and read their continuation output stream, breaking cross-tenant isolation.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The iFlytek Astron Agent software, specifically through version 1.1.2, contains a critical insecure direct object reference vulnerability that fundamentally compromises the integrity of workflow execution in multi-tenant environments. This flaw resides within the API endpoint POST /workflow/v1/resume, which is designed to allow authenticated applications to resume paused workflows by providing a specific event identifier. The core technical deficiency lies in the server's failure to validate whether the requesting application possesses authorization for the target workflow identified by the supplied event_id. Instead of enforcing strict ownership checks or tenant isolation boundaries before processing the request, the system blindly accepts any validly formatted event ID provided by an authenticated client and resumes the associated process. This lack of access control logic creates a direct path for attackers to manipulate stateful operations across organizational boundaries.
The operational impact of this vulnerability is severe due to the predictability of the underlying identifier scheme used by iFlytek Astron Agent, which relies on Snowflake event IDs. These identifiers are generated using algorithms that produce sequential or semi-sequential values based on timestamps and machine-specific parameters, making them highly predictable for an attacker who has access to at least one valid ID from a target tenant. By leveraging this predictability, malicious actors can enumerate potential event IDs within the same time window as active workflows in victim organizations. Once a relevant ID is identified, the attacker submits it via the resume endpoint, effectively hijacking the execution context of another application's workflow. This allows the attacker to inject custom content into the paused process and subsequently read the continuation output stream, leading to unauthorized data exfiltration and potential manipulation of business logic that relies on these workflows for critical operations.
This vulnerability represents a classic case of broken access control where cross-tenant isolation is entirely bypassed. In SaaS or multi-instance deployments, maintaining strict separation between different customers' data and processes is paramount for security compliance and trust. The ability to read the output stream of another tenant's workflow constitutes a significant confidentiality breach, potentially exposing sensitive business information, customer data, or proprietary algorithms embedded within those workflows. Furthermore, by injecting content into these resumed workflows, an attacker could cause denial of service conditions, corrupt downstream systems that consume this output, or escalate privileges if the workflow interacts with other privileged services. The predictability of Snowflake IDs exacerbates the risk compared to random UUIDs, as it reduces the attack surface from a brute-force search space to a narrow temporal window, making exploitation feasible and efficient for determined adversaries.
To mitigate this vulnerability, immediate remediation should focus on implementing robust authorization checks at the API level before any workflow state is modified or accessed. The POST /workflow/v1/resume endpoint must verify that the authenticated user or application token explicitly owns the resource identified by the event_id, ensuring that cross-tenant access is strictly prohibited regardless of ID predictability. Additionally, organizations should consider migrating from predictable Snowflake IDs to cryptographically random identifiers for workflow events if feasible within their architecture constraints, thereby increasing the entropy and reducing the feasibility of enumeration attacks. Input validation alone is insufficient; server-side ownership verification is required to enforce proper isolation. For users unable to patch immediately, network-level controls such as Web Application Firewalls can be configured to monitor for anomalous patterns in event ID usage or rapid sequential requests that may indicate an enumeration attempt, although this serves only as a temporary compensating control rather than a definitive fix.