EUVD-2026-115901Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege tenant user
-
ExploitEnumerate sequential auto-increment product IDs
-
ExecutionCall unguarded ProductController by-ID endpoint
-
ImpactRead MQTT credentials, overwrite tenant_id, or delete products
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 FastBee tenant account (PR:L) and a multi-tenant deployment where other tenants' products exist. The specific trigger per the source references is that the ProductController by-ID endpoints (detail/credential/edit/delete, around ProductController.java lines 77-141) enforced only RuoYi permission strings and omitted the tenant-ownership scoping that the list query applies at the service layer; combined with auto-increment product primary keys this lets any tenant enumerate and act on foreign IDs. Limiting factors: attacker must be logged in as a tenant user, and global-scope roles (admin/manager/visitor) are legitimately all-access, so the issue specifically affects cross-tenant isolation; no non-default configuration is otherwise needed. The only complete fix per the evidence is the vendor patch adding ownership enforcement. |
| Impact | This is a genuine, actionable authorization flaw rather than an inflated high-CVSS score, but its reach is bounded. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) is internally consistent with the description: exploitation is remote and low-complexity, requires no user interaction, but does require a valid authenticated tenant account (PR:L) - so this is not an unauthenticated internet-wide exposure. VC:H/VI:H are well supported (reading MQTT account/password/secret values, and overwriting product configuration including tenant_id), while VA:L reflects the product-deletion-with-cascading-rows capability. No EPSS score was provided in the input, so exploitation probability cannot be quantified here. The CVE is NOT in CISA KEV and no confirmed working exploit code is listed, so exploitation status is 'no public exploit identified at time of analysis' despite VulnCheck having published source-level analysis. The vuln.today decision label is 'this_week', which - combined with an available vendor patch, trivially enumerable auto-increment product IDs, and high confidentiality/integrity impact - makes this a near-term priority for anyone running multi-tenant FastBee, while the authentication requirement and the product's niche footprint keep it below emergency tier. No signals are internally conflicting; the main missing signal is EPSS. |
| Exploit ScenarioDerived | A low-privilege but authenticated FastBee tenant user iterates sequential (auto-increment) product IDs against the ProductController by-ID endpoints, which validated only permission strings and not tenant ownership. By doing so they read other tenants' MQTT account, password, and secret values, and can overwrite product configuration (including tenant_id) or delete products with cascading row deletion. No confirmed working exploit code is published, though VulnCheck released a source-level advisory identifying the vulnerable endpoints. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 03, 2026
Cross-tenant object reference flaw in FastBee through 2.1.0 lets any authenticated tenant user read another tenant's MQTT account, password and secret values, and overwrite or delete foreign product records, by supplying or enumerating sequential product IDs. The by-ID endpoints in ProductController enforced only RuoYi permission strings and omitted the tenant-ownership scoping that the list query applies at the service layer, which yields high confidentiality and integrity impact with limited availability impact (reported CVSS 4.0 score 8.7; independently assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L). Exploitation requires a valid tenant account on a multi-tenant deployment where other tenants' products exist, and no public exploit code or active exploitation was identified at time of analysis.
RemediationAI
Apply the vendor fix, which the evidence identifies as the only complete remediation: FastBee states patch availability and the ownership enforcement is delivered in commit 3393e3223965a9dc9682dfb2bd37635fffa0fbd2 (https://github.com/beecue/FastBee/commit/3393e3223965a9dc9682dfb2bd37635fffa0fbd2), which adds the IotDataAccessGuard and wires it into the product and device by-ID endpoints; a tagged patched release version is not stated in the available data, so confirm the build you deploy contains that commit or a later one carrying the guard. Because the check is implemented at the controller boundary rather than the service layer, verify after upgrading that every by-ID product and device route invokes the guard - service methods are also reached from MQTT broker threads and internal flows where no login context exists, so partial backports that only guard one controller leave the path open. Until the fix is deployed, the exposure is bounded by the prerequisites described in the advisory: only authenticated tenant accounts on multi-tenant deployments can reach foreign products, and accounts holding RuoYi all-data scope roles (admin, manager, visitor) are global by design, so limiting who holds tenant-scoped accounts and running single-tenant installations reduces but does not remove the risk, and doing so also removes the tenant separation the platform is meant to provide. Rotate the MQTT accounts, passwords and secrets of any product that may have been enumerated, since leaked credentials allow connecting to the broker as that device.
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
FastBee is a Java/Spring Boot IoT platform built on the RuoYi framework, with MyBatis mappers over a relational store and an MQTT broker component that consumes product and device credentials. The flaw is CWE-639 (authorization bypass through a user-controlled key): the product detail, credential, edit and delete handlers in ProductController (roughly lines 77-141 of the 2.1.0 tree) looked up records by primary key from the request and checked only permission strings, while the corresponding service and mapper layers (ProductServiceImpl lines 72-92, ProductMapper.xml lines 37-67) applied the caller's tenant scope only to list queries. Because product IDs are auto-increment, a tenant user can walk the key space and reach other tenants' rows; the returned data includes the MQTT account, password and secret used to authenticate the product, and writes can reassign tenant_id or delete a product together with its cascading child rows. The vendor fix introduces an IotDataAccessGuard component invoked at the controller boundary rather than in the service, because service methods are also called from MQTT broker threads and internal flows where no login context exists; the guard treats RuoYi data scope "1" (all-data) roles such as admin, manager and visitor as legitimately global, grants shared users access to devices but deliberately withholds connection credentials, and applies the same ownership check to the device endpoints touched in the same commit. The practical consequence is that product credentials obtained through the IDOR can be used to connect to the broker as the victim's device, bypassing broker-side ACLs.
Know when Fastbee gets its next vulnerability
- 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:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N
Authenticated tenant user (PR:L) over network with trivially enumerable sequential IDs (AC:L); exposes MQTT secrets (C:H), allows config/tenant_id overwrite (I:H), and product deletion gives partial availability impact (A:L); no scope change.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
FastBee through 2.1.0 contains an insecure direct object reference vulnerability in ProductController that allows authenticated tenant users to access other tenants' products by supplying their product IDs. Attackers can enumerate sequential product IDs to read MQTT account, password, and secret values, overwrite product configuration including tenant_id, or delete products with cascading rows.
Executive ViewAI
A cross-tenant access control flaw in FastBee version 2.1.0 allows any authenticated tenant user to read other tenants' MQTT credentials and tamper with their product data. This compromises the confidentiality and integrity of multi-tenant MQTT environments, eroding customer trust and potentially leading to data breaches or operational disruptions. Leadership should prioritize remediation to prevent unauthorized access and protect sensitive IoT device secrets.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
Vulnrichment
GitHub
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
Path traversal vulnerability in kerwincui FastBee up to version 1.2.1 allows authenticated remote attackers to read arbi
Stored cross-site scripting (XSS) in kerwincui FastBee up to version 1.2.1 allows authenticated remote attackers to inje
Insecure direct object reference (IDOR) in FastBee through 2.1.0 allows authenticated low-privilege users-including self
Code injection in the Groovy Script Executor component of beecue FastBee up to and including 2.1.0 lets a remote attacke
Exploit-DB