| Título | Magma master @ 76d9dc0ebc (Magma 1.8.0-era) Missing Authorization |
|---|
| Descripción | ================================================================================
REPORT ID : MAGMA-2026-001
TITLE : Host Routes RBAC Bypass - any host-org user can create a
SUPERUSER in any organization
VENDOR : Magma (Linux Foundation)
PRODUCT : Magma NMS (magmalte)
COMPONENT : nms/server/host/middleware.ts, nms/server/host/routes.ts
CWE : CWE-862 Missing Authorization
GHSA : GHSA-c35w-v4hx-v834 (private)
CVSS 3.1 : 9.9 CRITICAL
CVSS 4.0 : 9.4 CRITICAL
REPORTER : Aymen Benlamari (GitHub: aymencdm)
AFFECTED : Magma 1.8.0-era master @ 76d9dc0ebc (tested); all builds that
contain the cited code
EMBARGO : 2026-11-09
CHAIN ROLE : Root of the chain described in MAGMA-2026-005
================================================================================
--------------------------------------------------------------------------------
1. SUMMARY
--------------------------------------------------------------------------------
The NMS "host" organization is the super-administration organization. Routes
under /host/* are protected by hostOrgMiddleware, which only verifies that the
request's current organization is the host organization. It never checks the
authenticated user's role.
As a result, any authenticated user who belongs to the host organization -
including a role=0 USER - can call the host organization-management endpoints.
Those handlers accept the role field directly from the request body. A single
POST to /host/organization/async/<org>/add_user with "role": 3 creates a
SUPERUSER account in any existing organization. The attacker can then log in as
that account and has full NMS administrative control, including the NMS mTLS
proxy to the Orc8r API.
No race condition, no victim interaction, and no special configuration is
required. This is an application-layer authorization bug.
--------------------------------------------------------------------------------
2. AFFECTED COMPONENT / VERSIONS
--------------------------------------------------------------------------------
Product : Magma NMS (the "magmalte" / nms/server Node.js application)
Files : nms/server/host/middleware.ts (authorization gate)
nms/server/host/routes.ts (add_user / organization update)
Tested on : master @ 76d9dc0ebc (Magma 1.8.0-era), Docker lab
Likely : every release containing the same middleware and handlers. The
tested revision has no role check in this middleware; determine the
exact introduction commit with git log -S before publication if a
precise range is required.
--------------------------------------------------------------------------------
3. ROOT CAUSE
--------------------------------------------------------------------------------
nms/server/host/middleware.ts:16-27
export const hostOrgMiddleware = asyncHandler(async (req, res, next) => {
if (req.organization) {
const organization = await req.organization();
if (organization.isHostOrg) { next(); return; }
}
return res.redirect(req.access?.loginUrl || '/user/login');
});
The gate answers only "is this request scoped to the host organization?". It
does not answer "is this user allowed to administer the host organization?".
There is no comparison against req.user.role, no permission lookup, and no
separation between read and write host operations.
The route handlers then trust the body. nms/server/host/routes.ts:194-268
performs mass assignment and passes the caller-supplied role into User.create:
// PUT /organization/async/:name (line 194)
const updated = await organization.update(req.body); // mass assignment
// POST /organization/async/:name/add_user (line 220)
const props = await getPropsToUpdate(USER_PROPS, {...req.body}, ...);
const user = await User.create(props); // role comes from body
Because hostOrgMiddleware already admitted the request, the handler has no
independent authorization decision to fall back on. A role=0 user therefore
supplies role=3 and the server creates a SUPERUSER.
The same missing check exposes the other /host/* write endpoints (organization
create/update, network management, user management).
--------------------------------------------------------------------------------
4. ATTACKER MODEL / PRECONDITIONS
--------------------------------------------------------------------------------
- The attacker holds any valid NMS account (role=0 USER is sufficient).
- That account belongs to the host organization. This is the normal situation
for host-org staff and for accounts created by an administrator there.
- The target organization already exists. Creating one is also possible through
the same unprotected route family, so this is not a real constraint.
- The NMS is reachable over HTTP(S). No internal network position is needed.
The attacker does not need: a SUPERUSER account, a valid client certificate,
access to Orc8r, a race window, or user interaction.
--------------------------------------------------------------------------------
5. IMPACT (standalone)
--------------------------------------------------------------------------------
A role=0 user becomes role=3 SUPERUSER in the target organization. From there:
- list, create, modify and delete users in the organization
- create and delete networks
- reach the admin panel and full system configuration
- use the NMS mTLS proxy (/nms/apicontroller/magma/v1/*) to call Orc8r
- reach Grafana, which stores the Orc8r mTLS private key
Confidentiality, integrity and availability are all High within the NMS, and
the escalation crosses into the Orc8r control plane because the NMS holds a
trusted Orc8r client identity.
--------------------------------------------------------------------------------
6. CHAINED IMPACT
--------------------------------------------------------------------------------
MAGMA-2026-001 is the first step of the chain in MAGMA-2026-005:
001 RBAC bypass -> SUPERUSER in NMS
003 hardcoded gRPC token -> dump Orc8r operator certificate serials
004 certificate header spoofing -> full Orc8r REST API as admin_operator
The chain does not increase the CVSS base score of 001; it removes the need to
route Orc8r calls through the NMS proxy and provides a direct, persistent path
into the Orc8r control plane. See MAGMA-2026-005 for the end-to-end evidence.
--------------------------------------------------------------------------------
7. CVSS 3.1 - 9.9 CRITICAL
--------------------------------------------------------------------------------
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Metric Value Why
------ ----- ----------------------------------------------------------------
AV N The attack is an HTTP request to the NMS; no local or physical
access is required.
AC L One POST. No race, no timing window, no special conditions. The
CSRF token is read from a normal authenticated page.
PR L Any authenticated role=0 account in the host organization.
UI N The attacker acts alone; no victim has to click or visit
anything.
S C The escalation crosses a security boundary: an NMS user gains
the NMS's Orc8r control-plane identity, so impact is not limited
to the vulnerable component.
C H Read all users, networks, subscriber data and Orc8r state.
I H Create/modify/delete users, networks, ACLs and configuration.
A H Delete users, networks and gateways; disrupt the deployment.
If a reviewer does not accept the scope change, the same vector with S:U is
8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The scope-change reading is
preferred because the NMS SUPERUSER can reach Orc8r through the NMS proxy.
--------------------------------------------------------------------------------
8. CVSS 4.0 - 9.4 CRITICAL
--------------------------------------------------------------------------------
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Metric Value Why
------ ----- ----------------------------------------------------------------
AV N Network-reachable web endpoint.
AC L A single request; no bypass of a mitigation is needed.
AT N No additional attack requirements beyond a valid low-priv
account; no race, no configuration prerequisite.
PR L Role=0 account in the host organization.
UI N No user interaction.
VC H Full read of NMS/Orc8r data available to a SUPERUSER.
VI H Full write: users, networks, ACLs, configuration.
VA H Ability to delete resources and disrupt service.
SC H Orc8r is a subsequent system outside the NMS security scope;
the NMS SUPERUSER reaches it with the NMS client identity.
SI H Same: Orc8r configuration and |
|---|
| Fuente | ⚠️ https://github.com/aymencdm/magma_pocs/blob/main/01-rbac-poc.sh |
|---|
| Usuario | aymencdm (UID 101800) |
|---|
| Sumisión | 2026-10-19 21:59 (hace 26 días) |
|---|
| Moderación | 2026-11-14 07:50 (25 days later) |
|---|
| Estado | Aceptado |
|---|
| Entrada de VulDB | 437420 [Linux Foundation Magma hasta 1.9.0 Host Middleware middleware.ts hostOrgMiddleware role escalada de privilegios] |
|---|
| Puntos | 20 |
|---|