EEF-CVE-2026-120295

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:

1. On A's devices page, give a device you control the tags B's deployment group asks for. A view member can see the group's conditions.
2. 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.
3. 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.