| Title | Magma Magma 1.8.0-era master @ 76d9dc0ebc (tested); non-TLS Authentication Bypass by Spoofing |
|---|
| Description | ================================================================================
REPORT ID : MAGMA-2026-004
CHAIN ROOT : MAGMA-2026-001 (#1043997) - Host Routes RBAC Bypass
TITLE : Client certificate spoofing via HTTP header in Orc8r Obsidian
VENDOR : Magma (Linux Foundation)
PRODUCT : Magma Orc8r (obsidian REST API)
COMPONENT : orc8r/cloud/go/services/obsidian/access/operator.go
CWE : CWE-290 Authentication Bypass by Spoofing
GHSA : GHSA-3227-q56x-v5gp (private)
CVSS 3.1 : 9.8 CRITICAL
CVSS 4.0 : 9.3 CRITICAL
REPORTER : Aymen Benlamari (GitHub: aymencdm)
AFFECTED : Magma 1.8.0-era master @ 76d9dc0ebc (tested); non-TLS
deployments and direct/in-cluster access to obsidian
EMBARGO : 2026-11-09
RELATED : MAGMA-2026-001 (#1043997) (chain root), MAGMA-2026-003 (serial source),
MAGMA-2026-005 (chain)
================================================================================
--------------------------------------------------------------------------------
0. CHAIN RELATIONSHIP
--------------------------------------------------------------------------------
This finding is the third step of the chain described in MAGMA-2026-005:
MAGMA-2026-001 role=0 host-org user -> NMS SUPERUSER
MAGMA-2026-003 hardcoded gRPC token -> dump operator certificate serials
MAGMA-2026-004 spoof the serial on the REST API -> full Orc8r access
MAGMA-2026-001 is the chain root. This finding is nevertheless a distinct root
cause: Obsidian derives the caller's operator identity from a client-supplied
HTTP header and does not verify that the header was set by a trusted mTLS
terminating proxy. It is exploitable by any caller that can reach Obsidian
directly and knows a valid serial, regardless of how that serial was obtained.
--------------------------------------------------------------------------------
1. SUMMARY
--------------------------------------------------------------------------------
Obsidian is the Orc8r northbound REST API. In non-TLS mode it reads the
operator identity from the X-Magma-Client-Cert-Serial header:
csn := req.Header.Get(CLIENT_CERT_SN_KEY)
It then looks up that serial in the certifier and authorizes the request as the
associated operator. There is no check that the request arrived over a verified
mTLS connection, no check that the header was set by nginx, and no shared secret
between nginx and Obsidian.
An attacker who knows any valid operator certificate serial - for example by
dumping the certifier with the hardcoded token in MAGMA-2026-003 - can set the
header and act as that operator. With the admin_operator serial this yields full
read/write access to the Orc8r REST API: networks, tiers, gateways, ACLs, and
gateway commands.
When Obsidian is reached directly (without nginx, or in a non-TLS deployment),
it trusts whatever client-supplied header it receives. The shipped NetworkPolicy
that would restrict access to nginx is disabled by default, and Obsidian does
not authenticate nginx.
--------------------------------------------------------------------------------
2. AFFECTED COMPONENT / VERSIONS
--------------------------------------------------------------------------------
Product : Magma Orc8r (obsidian)
Files : orc8r/cloud/go/services/obsidian/access/operator.go:35
orc8r/cloud/go/services/obsidian/access/identity.go
Deployment: non-TLS mode, or any topology where a caller other than nginx can
reach Obsidian's HTTP port
Tested on : master @ 76d9dc0ebc (Magma 1.8.0-era), Docker lab, port 9081
Likely : every release that reads the client-cert header unconditionally.
--------------------------------------------------------------------------------
3. ROOT CAUSE
--------------------------------------------------------------------------------
orc8r/cloud/go/services/obsidian/access/operator.go:35:
csn := req.Header.Get(CLIENT_CERT_SN_KEY)
// No verification that the header was set by mTLS termination.
// No check of the TLS connection state or peer certificate.
The header constant is the client-controlled X-Magma-Client-Cert-Serial. The
value is treated as an authenticated identity. The code path does not
distinguish:
(a) a request that arrived through nginx after client-certificate
verification, where nginx set the header, from
(b) a direct request to Obsidian where the client set the header itself.
In TLS mode the correct behavior is to derive the serial from
r.TLS.PeerCertificates and ignore the header. In non-TLS mode there is no
authenticated channel at all, so the header is the only input and is fully
attacker-controlled.
The deployment assumes network isolation instead: only nginx should be able to
reach Obsidian. That assumption is not enforced by default. The orc8r Helm
chart ships networkPolicy.enabled=false, and Obsidian does not require a proxy
secret, so any in-cluster caller (a compromised pod, an SSRF, a sidecar) can
make the same request.
--------------------------------------------------------------------------------
4. ATTACKER MODEL / PRECONDITIONS
--------------------------------------------------------------------------------
- Network access to Obsidian's HTTP port (9081 in the lab; the in-cluster
service port in production). This is the same internal position needed for
MAGMA-2026-003.
- A valid, unrevoked operator certificate serial. Serial numbers are
identifiers, not secrets: they appear in certificates, logs and API
responses. MAGMA-2026-003 provides a direct way to dump them.
- No client certificate, no operator account, and no user interaction.
The attacker does not need to break TLS: in non-TLS mode there is no TLS to
break. In TLS mode, the peer certificate wins over the header, so the finding
is specifically about non-TLS/direct-access deployments and about the trust
boundary between nginx and Obsidian.
--------------------------------------------------------------------------------
5. IMPACT
--------------------------------------------------------------------------------
With the admin_operator serial (or any operator with broad ACLs):
- list, create, modify and delete networks, tiers and gateways
- read and modify operator ACLs
- issue gateway commands, including generic commands that can lead to
remote execution on gateways
- reach Grafana and the Orc8r mTLS private key
- persist by creating new operator credentials or configuration
Confidentiality, integrity and availability are High. Scope is Unchanged: the
impact is within the Orc8r control plane, which is the component being
attacked.
--------------------------------------------------------------------------------
6. CVSS 3.1 - 9.8 CRITICAL
--------------------------------------------------------------------------------
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Metric Value Why
------ ----- ----------------------------------------------------------------
AV N Obsidian is a network REST service. In non-TLS deployments the
port is reachable over the network, not only locally.
AC L One HTTP request with one header. No race, no crypto, no special
condition.
PR N No account or certificate is required. The serial is an
identifier, not an authentication secret; the service trusts
whatever the client sends.
UI N No user interaction.
S U The vulnerable component and the impacted API are the same
Orc8r service.
C H Full read of Orc8r state and configuration.
I H Full write: networks, tiers, gateways, ACLs.
A H Gateways and services can be disrupted.
Conservative alternative: if obtaining a valid serial is treated as an attack
prerequisite, AC:H gives 8.1; if it is treated as requiring an initial
low-privilege position, PR:L gives 8.8. The 9.8 score reflects the root cause:
the service authenticates on a client-controlled header, and serials are not
secrets. The chain report documents how the serial is obtained in practice.
--------------------------------------------------------------------------------
7. CVSS 4.0 - 9.3 CRITICAL
--------------------------------------------------------------------------------
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Metric Value Why
------ ----- ----------------------------------------------------------------
AV N Network REST endpoint.
AC L Deterministic single request.
AT N No additional attack requirements in the non-TLS/direct-access
configuration; the header is enough.
PR N No credentials; the serial is an identifier.
UI N No user interaction.
VC H Full read of the Orc8r API.
VI H Full write.
VA H Service/gateway disruption.
SC N No subsequent system beyond Orc8r.
SI N Sam |
|---|
| User | aymencdm (UID 101800) |
|---|
| Submission | 10/19/2026 22:12 (25 days ago) |
|---|
| Moderation | 11/14/2026 07:50 (25 days later) |
|---|
| Status | Accepted |
|---|
| VulDB entry | 437423 [Linux Foundation Magma up to 1.9.0 Obsidian REST operator.go X-Magma-Client-Cert-Serial authentication spoofing] |
|---|
| Points | 17 |
|---|