Summary
FastBee contains an insecure direct object reference vulnerability in DeviceController that allows authenticated low-privilege users to access devices belonging to other tenants by supplying predictable device IDs. Attackers who can register accounts may read sensitive device details and, under affected conditions, modify ownership fields to take over devices.
FastBee contains an insecure direct object reference vulnerability in DeviceController that allows authenticated low-privilege users to access devices belonging to other tenants by supplying predictable device IDs. Attackers who can register accounts may read sensitive device details and, under affected conditions, modify ownership fields to take over devices.
Affected context
The issue occurs in FastBee deployments through version 2.1.0 where DeviceController accepts client-supplied device identifiers without consistently verifying that the referenced device belongs to the requesting user's tenant. It is particularly risky in multi-tenant environments that permit self-registration and expose device lookup or update operations.
The issue occurs in FastBee deployments through version 2.1.0 where DeviceController accepts client-supplied device identifiers without consistently verifying that the referenced device belongs to the requesting user's tenant. It is particularly risky in multi-tenant environments that permit self-registration and expose device lookup or update operations.
Exploit preconditions
- Attack surface: Authenticated DeviceController read and update endpoints - Required access: A valid low-privilege account; self-registration may be
sufficient where enabled
- Trigger point: Supplying another device's sequential deviceId or
serialNumber to a device lookup or modification request
- Why exploitation is possible: Object-level authorization does not
adequately bind the requested device to the caller's tenant or permitted
ownership scope
- Attack surface: Authenticated DeviceController read and update endpoints - Required access: A valid low-privilege account; self-registration may be
sufficient where enabled
- Trigger point: Supplying another device's sequential deviceId or
serialNumber to a device lookup or modification request
- Why exploitation is possible: Object-level authorization does not
adequately bind the requested device to the caller's tenant or permitted
ownership scope
Why this happens
The underlying bug is an authorization failure in which the application treats a user-controlled object identifier as sufficient authority to access or update a device. Predictable identifiers make enumeration easier, while missing tenant and ownership checks allow cross-tenant object access and unauthorized field changes. This behavior maps to CWE-639, Authorization Bypass Through User-Controlled Key.
The underlying bug is an authorization failure in which the application treats a user-controlled object identifier as sufficient authority to access or update a device. Predictable identifiers make enumeration easier, while missing tenant and ownership checks allow cross-tenant object access and unauthorized field changes. This behavior maps to CWE-639, Authorization Bypass Through User-Controlled Key.
Potential impact
- Attackers may read device owner, IP address, and location information.
- Attackers could enumerate devices across tenant boundaries.
- Unauthorized users may modify device ownership or tenant associations.
- Attackers could take over devices or disrupt legitimate administration.
- Compromised device records can contribute to broader tenant or operational
impact.
- Attackers may read device owner, IP address, and location information.
- Attackers could enumerate devices across tenant boundaries.
- Unauthorized users may modify device ownership or tenant associations.
- Attackers could take over devices or disrupt legitimate administration.
- Compromised device records can contribute to broader tenant or operational
impact.
General mitigation guidance
Mitigation generally centers on enforcing server-side, object-level authorization for every device operation. Authorization checks should derive the caller's tenant and permitted scope from trusted session or identity context rather than request parameters, and should apply consistently to reads, updates, and sensitive ownership fields. Device identifiers should not be treated as secrets; opaque identifiers can reduce enumeration risk but do not replace authorization. Sensitive fields such as user_id and tenant_id should be protected from ordinary user updates, with least-privilege service roles and secure-by-default tenant isolation. Input validation, rate limits, and controlled registration policies can further reduce abuse.
Mitigation generally centers on enforcing server-side, object-level authorization for every device operation. Authorization checks should derive the caller's tenant and permitted scope from trusted session or identity context rather than request parameters, and should apply consistently to reads, updates, and sensitive ownership fields. Device identifiers should not be treated as secrets; opaque identifiers can reduce enumeration risk but do not replace authorization. Sensitive fields such as user_id and tenant_id should be protected from ordinary user updates, with least-privilege service roles and secure-by-default tenant isolation. Input validation, rate limits, and controlled registration policies can further reduce abuse.
How teams detect issues like this
Detection approaches include static and dynamic checks for controller methods that load objects directly from request-supplied IDs without a corresponding tenant or ownership authorization check. Code review should flag direct repository lookups followed by responses or updates, predictable identifier enumeration, and client-controlled assignment of user_id or tenant_id. Integration tests can verify that users from one tenant cannot read or modify objects belonging to another tenant. API policy enforcement, authorization middleware, audit logging, and automated review tools can help identify and monitor these patterns.
Detection approaches include static and dynamic checks for controller methods that load objects directly from request-supplied IDs without a corresponding tenant or ownership authorization check. Code review should flag direct repository lookups followed by responses or updates, predictable identifier enumeration, and client-controlled assignment of user_id or tenant_id. Integration tests can verify that users from one tenant cannot read or modify objects belonging to another tenant. API policy enforcement, authorization middleware, audit logging, and automated review tools can help identify and monitor these patterns.
