Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSelf-register low-privilege tenant account
-
ExploitEnumerate sequential deviceId/serialNumber values
-
ExecutionInvoke DeviceController IDOR endpoint
-
ImpactOverwrite user_id/tenant_id to hijack device
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 low-privilege FastBee tenant account, which an attacker can obtain themselves where self-registration is enabled (the description explicitly cites 'self-registered attackers'); the instance must be reachable and running FastBee 2.1.0 or earlier. Exploitation then depends only on supplying sequential device identifiers to the DeviceController device endpoints - no special feature toggle, no victim interaction, and no elevated role are needed. The practical LIMITING factors are: an account is required (so PR:L, not fully unauthenticated), the deployment must be multi-tenant for cross-tenant impact to matter, and open self-registration being disabled would raise the bar to needing any pre-existing user credential. |
| Impact | This is a genuine, prioritizable authorization flaw, though not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N, 8.6 HIGH) is internally consistent with the description: network-reachable, low attack complexity, low privileges (a self-registered tenant account), no user interaction, with high confidentiality and integrity impact and no availability impact - matching CWE-639 (IDOR / authorization bypass via user-controlled key). The low PR:L is realistic because any self-registered user can obtain the needed account, which effectively lowers the barrier close to unauthenticated in deployments that allow open registration. No EPSS score, CISA KEV entry, or SSVC decision data was provided in the input, so exploitation-probability and automatability signals are UNKNOWN and cannot be used here; absence of these is not evidence of low risk. No exploit code is referenced, but a detailed public technical write-up exists (hackmd.io) plus a VulnCheck advisory, which substantially lowers the effort for an attacker to reproduce the issue. The flaw is sequential-ID enumeration against a documented endpoint - trivially automatable in practice even though no SSVC 'automatable' flag is supplied. Net: a real priority for anyone running FastBee in a multi-tenant mode, tempered mainly by the product's limited deployment footprint rather than by any technical difficulty. |
| Exploit ScenarioDerived | An attacker self-registers a normal low-privilege tenant account on an internet-facing FastBee instance, then issues authenticated requests to the DeviceController device endpoints while incrementing deviceId or serialNumber values to read other tenants' device owner, IP, and location data. Using the same endpoints they overwrite the user_id and tenant_id fields on a victim's device to reassign ownership to themselves, taking control of the device. No public exploit code is identified, but a step-by-step technical write-up and a vendor-style VulnCheck advisory are publicly available, making reproduction straightforward. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
Authenticated low-privilege FastBee users can read and seize control of IoT devices belonging to other tenants: the DeviceController endpoints accept a caller-supplied device ID or serial number and never verify that the requesting account actually owns that device (CWE-639). Because identifiers are sequential and easy to guess, anyone who can self-register on a FastBee 2.1.0-or-earlier instance can enumerate devices, harvest owner, IP and location metadata, and then overwrite the stored user_id and tenant_id fields to permanently take over the target device. Confirmed exploitation has not been reported (no CISA KEV entry), and no public exploit code was identified at time of analysis, but a detailed third-party technical writeup of the flaw exists, and the independent assessment rates it a genuine, prioritizable authorization defect rather than a drop-everything emergency, since a valid tenant account is a prerequisite (PR:L in the vector) and cross-tenant impact only materializes on multi-tenant deployments.
RemediationAI
No vendor-released patch identified at time of analysis: the disclosure names no fixed version beyond the 'through 2.1.0' ceiling, and the only remediation-adjacent references are source-file links, so there is no exact patched release to cite. The definitive fix must be applied in the application itself - add a server-side ownership/tenant predicate to every DeviceController lookup and update (scope queries by the authenticated principal's tenant_id and user_id rather than trusting the client-supplied deviceId/serialNumber, and never accept user_id or tenant_id from the request body on update) - and this should be requested from the maintainer at the project repository (https://github.com/kerwincui/FastBee) or back-ported as a local patch. Until that is possible, the highest-value compensating control is to disable open self-registration so that an attacker must already hold a valid credential; the trade-off is loss of self-service onboarding and continued exposure to any legitimate low-privilege insider, since the underlying IDOR remains. Where the instance is reachable from untrusted networks, place the device API behind a VPN or an authenticating reverse proxy and restrict it to known management networks, accepting reduced accessibility for legitimate mobile/IoT clients. Because the flaw is driven by enumerable sequential identifiers, add WAF or application-level rate limiting and alerting on rapid, sequential device-ID access patterns per session; this detects rather than prevents abuse. Finally, since attackers can overwrite ownership fields, generate a baseline of device user_id/tenant_id assignments and audit for unexpected reassignments, treating the flaw as a data-integrity as well as confidentiality risk. A public technical writeup of the issue is available at https://hackmd.io/@1ExmmukzRMWN7B4gQ4W-4Q/fastbee-device-ownership-idor for defenders validating exposure.
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 that manages devices under a multi-tenant data model in which every device record carries owner (user_id) and tenant (tenant_id) fields. The reported flaw is an insecure direct object reference / authorization-through-user-controlled-key (CWE-639) in DeviceController: the referenced source at springboot/fastbee-open-api/src/main/java/com/fastbee/data/controller/DeviceController.java (lines 119-211, mirrored in the older v1.2.1 wumei-iot controller at lines 118-213) passes attacker-controllable deviceId and serialNumber parameters into DeviceServiceImpl (fastbee-iot-service, lines 105-125), where the lookup and update operations are keyed on those identifiers without a tenant/owner scoping predicate. Standard Spring Security authentication still applies, so an account is required, but authorization is never re-checked against the object's ownership, letting a low-privileged account operate on records outside its tenant. The CVSS 4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N describes network-reachable, low-complexity exploitation with low privileges and no user interaction, high confidentiality and integrity impact, no availability impact, and no subsequent-system (scope) impact beyond FastBee itself; our independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) is consistent with this read-and-rewrite profile and confirms the same precondition of an authenticated low-privilege account.
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:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Remote low-privilege self-registered user (PR:L) exploits an IDOR with no interaction, gaining high confidentiality and integrity over other tenants' devices but no availability impact (A:N).
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
FastBee through 2.1.0 contains an insecure direct object reference vulnerability in DeviceController that allows authenticated low-privilege users to read and modify other tenants' devices by supplying sequential device IDs. Self-registered attackers can enumerate deviceId or serialNumber values to read owner, IP, and location data, and overwrite user_id and tenant_id to take over devices.
Executive ViewAI
A broken object-level authorization flaw in FastBee (versions 2.1.0 and earlier) allows any user who can self-register on a shared instance to enumerate, harvest metadata from, and permanently seize control of IoT devices belonging to other tenants. Because this is a multi-tenant platform, a single low-privilege account can escalate into cross-customer device takeover, creating customer-trust, privacy, and potential safety exposure well beyond the affected account. Leadership should treat this as a priority multi-tenant isolation failure in a product already deployed with real customer devices, even though no exploitation has been observed to date.
No vendor-released patch identified at time of analysis. Interim mitigations: disable or tightly control self-registration and new tenant onboarding on affected FastBee 2.1.0-or-earlier instances; enforce server-side ownership checks at a reverse proxy or API gateway for DeviceController requests; replace sequential device identifiers with non-guessable values; alert on cross-tenant device lookups and on modifications to user_id/tenant_id fields; restrict device management endpoints to trusted administrative roles; and segment or isolate tenants onto separate instances until a vendor fix is available.
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-98889
GHSA-pv4m-4fcw-r33m
NVD
CVE.org
EPSS
Exploit-DB