PT-2026-141570
CVE-2026-120295
·
Published
2026-11-10
·
Updated
2026-11-10
Description by
CVSS 4.0
7.1
HighMetricsAV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Summary
Incorrect Authorization vulnerability in the devices page bulk move in nerves-hub nerves hub web allows an authenticated user with the
manage role in one organization and only the view role in another to move devices into the second organization's product via the "Move device(s) to product" action. The target-product event in NervesHubWeb.Live.Devices.Index looks the product up with NervesHub.Products.get by id/2, which checks that the user is a member of the product's organization at any role, and move-devices-product then changes each selected device's organization and product. The device API's move requires manage in the target organization, and an earlier fix added the check on the organization the devices leave but not on the one they enter.A moved device keeps its key and certificate, joins the target organization's matching deployment groups, and is sent their firmware with a download URL, which the
view role cannot otherwise obtain. The user cannot change or control devices that already belong to the other organization.This issue affects nerves hub: from 1.0.0 before 2.5.3.
Details
1. Target selection. The bulk actions sidebar (
NervesHubWeb.Components.BulkActionsSidebar) lists the products of every organization in current scope.user.orgs. Choosing one sends target-product to NervesHubWeb.Live.Devices.Index, which requires device:update in the current organization and then calls NervesHub.Products.get by id/2. That query joins the product's organization to its org users rows and filters on the user's id only, so any membership in the target organization satisfies it, including the view role.2. The move.
move-devices-product passes the selected devices, or every device matching the current filter, to NervesHub.Devices.BulkActions.move many/3, which calls Devices.move/3 for each one and rewrites its org id and product id. No check of the user's role in the target organization happens on this path, while the API's move in NervesHubWeb.API.DeviceController requires manage there.3. Effect. The moved device still authenticates with its own certificate. On its next connection it is matched against the target product's deployment groups by platform, architecture and tags, joins one, and is sent that group's firmware with a download URL.
Proof of concept
As a user with
manage in organization A and view in organization B, where B has an active deployment group:- On A's devices page, give a device you control the tags B's deployment group asks for. A
viewmember can see the group's conditions. - Select the device, choose B's product under "Move device(s) to product" and press Move. The page reports the move as successful, and the device is now in B's product.
- Connect the device, reporting the platform and architecture of the group's firmware. It joins the group and is sent B's firmware with a download URL.
Impact
A user who manages devices in one organization and holds only the view role in another can move their own devices into the second organization. The devices join its matching deployment groups and receive its firmware, which the view role cannot otherwise download, and they report health, logs and alarms into that organization. Devices already belonging to the other organization are not affected.
Solutions
Every move is recorded in the target product's audit log as "User moved device to : ". After upgrading, review the
audit logs rows with resource type NervesHub.Products.Product and a description containing "moved device" whose actor does not hold the manage or admin role in that organization, and move or remove the devices they brought in. Roles may have changed since a move, and entries older than the retention period are gone when TRUNCATE AUDIT LOGS ENABLED is on. Found an issue in the description? Have something to add? Feel free to write us 👾