Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as any tenant user
-
DeliveryEnumerate predictable Snowflake fileIds
-
ExploitRequest /file/download with foreign fileId
-
ExecutionServer skips owner/tenant check
-
ImpactExfiltrate other tenants' S3 files
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires a valid authenticated tenant account on the target AstronRPA instance (PR:L) and the ability to reach the resource-service /file/download endpoint over the network. Exploitation specifically depends on the absence of any owner/tenant ownership check in FileMapper.getFile combined with predictable, time-ordered Snowflake fileIds that allow an attacker to guess or enumerate IDs belonging to other tenants (reflected as AT:P). Limiting factors: the attacker must already hold a tenant login, and only confidentiality of S3-stored files is at stake - no write, modification, or availability impact. Affects all multi-tenant deployments of AstronRPA through version 1.1.6. |
| Impact | This is a cross-tenant Insecure Direct Object Reference (CWE-639) in AstronRPA's resource-service /file/download endpoint, confirmed by the vendor advisory (VulnCheck) and a public technical writeup. The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H) scores 6.0 (Medium): network-reachable, low complexity, but requiring low-level authentication (PR:L - any valid tenant account) and an attack requirement (AT:P) reflecting the need to enumerate fileIds. Impact is confidentiality-only and high (VC:H); integrity and availability are unaffected (VI:N/VA:N), consistent with a read-only file-disclosure flaw. No EPSS score was provided and the input shows no KEV listing and no explicit POC flag, so this is not confirmed as actively exploited - it reads as a genuine but moderate-priority data-exposure issue rather than a critical remote-code-execution emergency. The key risk amplifier is that fileIds are predictable time-ordered Snowflake IDs with no owner/tenant check in FileMapper.getFile, making mass enumeration of other tenants' S3-stored files practical for any authenticated user; this makes it more serious than a typical single-object IDOR. The main limiting factor is the authentication requirement, which confines exploitation to parties who can obtain a tenant account on a given deployment. |
| Exploit ScenarioDerived | An attacker registers or obtains any low-privilege tenant account on an AstronRPA deployment (≤1.1.6), then issues repeated authenticated requests to /file/download while incrementing or predicting time-ordered Snowflake fileIds. Because FileMapper.getFile performs no owner or tenant check, each valid ID returns another tenant's S3-stored file, allowing bulk harvesting of cross-tenant data. A public technical writeup describing the flaw exists, but no weaponized exploit tool is confirmed in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Authenticated cross-tenant file disclosure affects the iFlytek AstronRPA platform through version 1.1.6 via an insecure direct object reference in the resource-service /file/download endpoint. Any user who holds a valid tenant login can supply a fileId belonging to a different tenant and receive that tenant's S3-stored file, because the DAO method FileMapper.getFile returns the object without any owner or tenant ownership predicate; the time-ordered Snowflake file identifiers make reliable enumeration practical (reflected as AT:P in the CVSS 4.0 vector). Impact is confidentiality-only (no write or availability effect) and the assessment is CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, with no public exploit code identified at time of analysis, though a public technical writeup documents the flaw and no CISA KEV entry exists.
RemediationAI
No vendor-released patch identified at time of analysis - no fixed version is published in the available advisory data, so AstronRPA 1.1.6 and earlier should be treated as unfixed until iFlytek ships a corrected release; monitor https://github.com/iflytek/astron-rpa and the VulnCheck advisory at https://www.vulncheck.com/advisories/astronrpa-through-1.1.6-cross-tenant-file-disclosure-via-file-download for updates. Until then, the decisive compensating control is to add an explicit tenant/owner predicate to FileMapper.getFile (and to any other DAO lookup by primary key), scoping every file read to the caller's tenant before the S3 object is fetched - either as a local code patch or by fronting the endpoint with an authorization filter; the trade-off is that a hasty patch can break legitimate cross-tenant or administrator workflows, so test those paths. Replace or supplement the sequential, time-ordered Snowflake fileIds with unguessable UUIDs or otherwise opaque tokens to remove enumerability, accepting a migration cost for existing stored objects and any external integrations that persist IDs. If patching is not possible, restrict the /file/download route at the API gateway or reverse proxy so only trusted internal services or a vetted allowlist of tenants can call it (this disables the feature for ordinary users), or move resource-service onto per-tenant storage credentials so a leaked fileId cannot resolve to another tenant's object. Regardless of mitigation, enable access logging on /file/download with tenant, user, and fileId correlation and alert on download volumes or ID ranges inconsistent with a single tenant, since successful exploitation leaves only benign-looking 200 responses in normal logs.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-639, Authorization Bypass Through User-Controlled Key, commonly known as an IDOR. AstronRPA's backend is a Java microservice architecture in which resource-service handles file operations; the vulnerable flow reaches the DAO method FileMapper.getFile (referenced in the iFlytek repository at backend/resource-service/.../file/dao/FileMapper.java), which retrieves a file record by its primary key alone with no JOIN or predicate tying the record to the authenticated caller's tenant or user. Identifiers are Snowflake-style 64-bit, time-ordered keys, so they are not cryptographically random and can be approximated from observed IDs, making blind enumeration of other tenants' objects feasible rather than requiring a full 2^64 search - this dependency on ID guessing is what the CVSS 4.0 vector captures as AT:P (Attack Requirements: Present). The actual bytes live in S3 object storage, so once the authorization check is bypassed the service happily streams cross-tenant content back to the caller, turning a missing tenant scoping predicate into direct data exfiltration.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable endpoint with low-privilege tenant auth (PR:L) and predictable enumerable IDs keep AC:L; read-only cross-tenant file disclosure gives C:H with I:N/A:N.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
AstronRPA through 1.1.6 contains an insecure direct object reference vulnerability in the resource-service /file/download endpoint that allows authenticated users to download other tenants' files by supplying their fileId. Attackers can enumerate predictable time-ordered Snowflake file IDs, since FileMapper.getFile performs no owner or tenant check, to retrieve S3-stored files uploaded by other tenants.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-101564
GHSA-xg73-6f4x-27x7
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB