SECURITYCRITICALCVE-2026-105039

CVE-2026-105039: EnergizeLab Station-Middleware Missing Admin Role Checks

EnergizeLab station-middleware admin APIs skip role checks — any low-privilege user can steal AI provider keys and alter config (CVSS 9.6).

Dylan H.

Security Team

October 16, 2026
9 min read
CVE-2026-105039: EnergizeLab Station-Middleware Missing Admin Role Checks

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • EnergizeLab station-middleware (Docker) 1.6.5 - 1.8.2

Executive Summary

CVSS Score: 9.6 (Critical)

A critical broken-access-control vulnerability has been disclosed in EnergizeLab's station-middleware, the NestJS-based Docker service that backs EnergizeLab's cloud/station infrastructure (used by the Eilik/EilikO companion-robot product line). Tracked as CVE-2026-105039, the flaw is simple and severe: the service's administrative APIs do not check the caller's role. Any account that can authenticate at all — including an ordinary, low-privilege registered user — can call admin-only endpoints and walk away with AI provider API keys, plus the ability to change configuration and object-store contents.

In other words, the only "privilege" an attacker needs is a normal account. There is no separate admin-escalation exploit required — the role check that should gate these endpoints from regular users simply isn't there.

CVE-2026-105039 was published 2026-10-15 as part of a larger batch of EnergizeLab vulnerabilities disclosed by the same independent researcher, which also produced the sibling CVEs covered below.

Vulnerability Overview

FieldValue
CVE IDCVE-2026-105039
CVSS Score9.6 (Critical) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
CWECWE-862: Missing Authorization (cited as the primary classification by Strix.ai and OffSeq Radar; VulDB's listing title — "Administrative API privileges management" — lines up with the related CWE-269, Improper Privilege Management — both describe the same underlying root cause: no role check in front of admin endpoints)
Attack VectorNetwork
Attack ComplexityLow
AuthenticationRequired — but only a standard, low-privilege account
Privileges RequiredLow
ScopeChanged
Affected Product/VersionsEnergizeLab station-middleware (NestJS) Docker images, versions 1.6.5 ≤ v ≤ 1.8.2

Affected Versions and Patches

All public sources reviewed for this article — NVD, Strix.ai, OffSeq Radar, VulDB, and the AHA!/takeonme.org disclosure writeup — agree on the vulnerable range: station-middleware Docker images 1.6.5 through 1.8.2. None of them list a confirmed patched version. The original disclosure repository for this research batch describes a vendor that did not engage with the researcher's reports across multiple retests between September and October 2026, and the sibling CVE-2026-105038 advisory on this site notes the same pattern for a related EnergizeLab component.

Treat this as unpatched until EnergizeLab publishes version-specific fix information. Do not assume a later image tag has quietly fixed it without a vendor changelog or advisory confirming the fix.

How the Vulnerability Works

Per the NVD description, EnergizeLab station-middleware's administrative APIs do not check the requesting user's role before honoring the request. Concretely, that means:

  • The service clearly has a notion of roles (otherwise there would be nothing to "not check") — but the administrative endpoints never enforce it.
  • Any account that can successfully authenticate to the middleware, regardless of its intended privilege level, can reach those admin endpoints and have requests processed as if it were an admin.
  • No public source reviewed for this article names the specific vulnerable route path(s). What is consistently documented across the NVD description, Strix.ai, OffSeq Radar, and the AHA! writeup is the category of impact: retrieval of AI provider keys, and the ability to change configuration and object-store contents. If you operate this middleware, don't wait for a published route name — audit every endpoint under whatever your admin/management namespace is (commonly something like an /admin or /management prefix in NestJS apps) and confirm each one independently enforces a role guard, rather than assuming a shared decorator or guard is actually wired up everywhere it needs to be. This class of bug (CWE-862) is frequently caused by exactly that: a role-guard decorator that exists in the codebase but isn't applied — or is misapplied — on some subset of routes.
  • Because the CVSS vector lists Scope: Changed, exploiting this flaw affects resources beyond the vulnerable component itself — consistent with the described impact of reaching into configuration and object-store contents that sit outside the admin API's own security scope.

The specific sensitive data named in the NVD description is AI provider API keys. station-middleware, as part of an AI-powered product's cloud backend, stores credentials for whatever upstream AI provider(s) it calls on the product's behalf. With broken admin access control, a low-privilege authenticated user can pull those provider credentials directly out of the configuration the admin API exposes.

Impact Assessment

  • Confidentiality: High, Integrity: High, Availability: None per the CVSS vector — attackers can read and modify sensitive data, but the vulnerability as described doesn't itself cause a denial of service.
  • AI provider key theft enables downstream abuse. Once an attacker has the AI provider's API key(s), they can use them outside the context of EnergizeLab's own product — running up usage/billing charges on the vendor's account, or using the stolen credentials against the AI provider's API for unrelated purposes (model misuse, data exfiltration from whatever that provider's API exposes, etc.). The researcher's broader disclosure on this product line separately documents a related finding where exposed cloud AI-provider keys were used to generate billions of tokens of usage at the vendor's expense — illustrating the kind of abuse that unprotected provider keys invite, even though that specific finding is not this CVE.
  • Configuration and object-store tampering. Beyond key theft, the same missing role check lets a low-privilege user alter middleware configuration and object-store contents — meaning this isn't just an information-disclosure bug. An attacker could potentially reconfigure how the service behaves or tamper with stored objects it manages.
  • Chains with CVE-2026-105037. The sibling vulnerability CVE-2026-105037, disclosed the same day against the same station-middleware image range (1.6.5–1.8.2), is an arbitrary file-read flaw (CVSS 9.9) that lets a registered low-privilege account read arbitrary server files, exposing further secrets. Researchers covering this disclosure batch specifically describe the two bugs together as enabling a broader cloud-to-fleet escalation path — a low-privilege account can use the file-read bug to pull additional secrets, while this CVE's broken admin-API access control hands over AI provider keys and configuration/object-store write access directly. An attacker doesn't need to pick one or the other.
  • No special access needed. With AC:L and PR:L in the vector, any already-registered low-privilege user — not a privileged insider, not someone who has already escalated — can exploit this immediately.

Recommendations

  1. Patch immediately if and when EnergizeLab publishes a fixed version. As of this writing, no confirmed patched release has surfaced in public advisories — monitor the vendor directly rather than assuming a routine image update has resolved it.
  2. Enforce role checks at a proxy/gateway layer as a stopgap. If you operate station-middleware and cannot wait on an upstream fix, put an authenticating reverse proxy or API gateway in front of the admin namespace that independently verifies caller role/claims before traffic ever reaches the application's own (currently ineffective) authorization logic.
  3. Rotate any AI provider keys stored in the middleware now, on the assumption they may already be exposed, regardless of whether you have evidence of exploitation. Treat any key that has lived in this middleware's configuration since before a confirmed patch as compromised.
  4. Audit object-store access logs for unexpected reads, writes, or deletions from accounts that shouldn't have admin-level object-store access — this flaw's "no role check" means normal low-privilege account activity and malicious admin-API abuse can look identical in access logs unless you specifically cross-reference account privilege level against the actions taken.
  5. Restrict low-privilege account creation/registration where feasible until a fix is confirmed — every account capable of authenticating to the service is a potential exploitation path for this bug.
  6. Review exposure alongside CVE-2026-105037 on the same product — the two flaws are most dangerous combined, so mitigating one without addressing the other leaves the escalation path open.

Key Takeaways

  1. CVE-2026-105039 (CVSS 9.6) lets any authenticated low-privilege user on EnergizeLab station-middleware reach admin-only APIs and retrieve AI provider keys, plus change configuration and object-store contents — no admin role or escalation exploit required.
  2. Root cause is a missing role check (CWE-862/CWE-269 territory) on administrative endpoints — the role model exists in the application, it just isn't enforced where it matters.
  3. No confirmed patched version is publicly documented as of 2026-10-16; the vendor reportedly did not engage with the disclosing researcher across multiple retests.
  4. Stolen AI provider keys create downstream risk beyond this product — billing abuse and model misuse against the upstream AI provider are realistic consequences of key theft, independent of anything else EnergizeLab does.
  5. This chains with CVE-2026-105037 (arbitrary file read, same image range, CVSS 9.9) for a broader cloud-to-fleet escalation path — treat the two together, not in isolation.
  6. If you operate this middleware, rotate provider keys and front the admin API with independent role enforcement now — don't wait on a vendor patch timeline to reduce exposure.

Related Vulnerabilities

CVE-2026-105039 was disclosed as part of a batch of EnergizeLab Eilik/EilikO and station-middleware vulnerabilities released the same day. Related CVEs covering the same or adjacent EnergizeLab components:

These are covered in their own dedicated advisories; this article's technical focus is CVE-2026-105039 only.

Sources