Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.
CVE-2026-105037: EnergizeLab Path Traversal
TL;DR - CVE-2026-105037 is a critical authenticated path-traversal and arbitrary-file-read vulnerability in EnergizeLab station-middleware Docker images 1.6.5–1.8.2. - Any registered low-privilege account may be able to read files accessible to the middleware process. - No fixed version or confirmed in-the-wild exploitation was identified. Restrict access and rotate potentially exposed secrets while seeking vendor guidance.
Vulnerability at a Glance
| Field | Detail |
|---|---|
| CVE ID | CVE-2026-105037 |
| Component | EnergizeLab station-middleware |
| Technology and distribution | NestJS application distributed as Docker images |
| Affected versions | 1.6.5 through 1.8.2, inclusive |
| CVSS | 9.9 Critical |
| Attack vector | Network-facing service access is implied; the official vector string was not available in the reviewed NVD data |
| Authentication | Required; a registered, low-privilege account is reportedly sufficient |
| Privileges required | Low |
| Patch available | No vendor-confirmed fixed version identified |
The vulnerability affects middleware associated with the EnergizeLab Eilik and EilikO platform ecosystem. The available record describes an authenticated user supplying an attacker-controlled file path to the service. That file read may expose application files, configuration data, credentials, API keys, and other secrets readable by the container or host process.
Analyst’s Take: The authentication requirement does not make this a low-priority issue when a registered, low-privilege account is reportedly sufficient. The first response should be to restrict access, identify affected image deployments, and determine whether readable secrets require rotation while waiting for a vendor-confirmed image.
Administrators should not treat the authentication requirement as low operational risk. A normal registered account may be easier to obtain or compromise than an administrative account. If the middleware stores session secrets, service credentials, or signing keys locally, arbitrary file read can become a stepping stone to account takeover, privilege escalation, or compromise of connected systems.
What Is CVE-2026-105037?
CVE-2026-105037 is an authenticated path-traversal vulnerability classified as CWE-73, External Control of File Name or Path. The service reportedly accepts a user-controlled path and uses it in a file-access operation without adequately restricting the resolved location. An attacker could attempt traversal sequences or other path-manipulation techniques to move outside the directory the application intended to expose.
The retrieved material does not include source code or patch details, so the precise vulnerable function and exact traversal syntax are not confirmed. The likely security failure involves one or more missing controls:
- Canonicalizing the requested path.
- Rejecting traversal components.
- Enforcing an allowlisted base directory.
- Confirming that the resolved path remains below that directory.
- Replacing file paths with fixed application-side file identifiers.
The described impact is arbitrary file disclosure rather than direct arbitrary code execution. The practical severity depends on what the middleware process can read. Environment files, application configuration, private keys, session-signing material, database credentials, and cloud or platform tokens could enable follow-on attacks beyond the original read primitive.
For broader context on network isolation as a defensive control, see our guide to how network segmentation reduces PCI scope.
Who Is Affected?
The affected product is EnergizeLab station-middleware, described as a NestJS-based service distributed through Docker images. The reported affected version range is 1.6.5 through 1.8.2, inclusive. Deployments associated with the Eilik and EilikO platforms should inventory their middleware images rather than relying only on the product name shown in a web interface.
The available evidence does not identify a confirmed fixed release. No validated patched image tag was provided in the reviewed NVD record or related reference material. Organizations running any image in the affected range should therefore treat it as vulnerable until EnergizeLab or the relevant platform operator supplies a confirmed remediation version.
Check running containers and image inventories. A container may report a generic application version while the underlying image tag, digest, or deployment manifest identifies the actual vulnerable build. Account for replicas, staging environments, backup hosts, and offline appliances that may not appear in the primary production inventory.
CVSS Score Breakdown
The reported base score is 9.9 Critical. That score indicates a severe vulnerability with potentially broad confidentiality, integrity, and availability consequences. The available NVD information did not include the CVSS vector string, so the individual metric selections cannot be independently reconstructed with confidence.
The available description establishes several practical characteristics. Exploitation requires authentication, but only a low-privilege registered account is reportedly needed. The service is accessed through a networked application interface, and the result is arbitrary file disclosure from the server environment. Use the score as a prioritization signal, while avoiding any representation of an unavailable vector as confirmed.
| CVSS-related characteristic | What is known |
|---|---|
| Base score | 9.9 Critical |
| Vector string | Not provided in the retrieved NVD record |
| Authentication | Required |
| Required privilege | Low-privilege registered account |
| Primary impact | Arbitrary file disclosure |
| Potential secondary impact | Credential theft, secret exposure, session forgery, lateral movement |
| Metric certainty | Exact component values cannot be independently verified |
Exploitation Status
CVE-2026-105037 was not listed in CISA’s Known Exploited Vulnerabilities catalog at the time of review. The available record reports on_kev: false, and no CISA due date or required remediation action applies. This shows that CISA had not cataloged confirmed exploitation; it does not prove that exploitation is impossible or that private targeting has not occurred.
A GitHub reference is associated with the CVE: https://github.com/xn0tsa/your-secrets-are-safe-with-me. The retrieved content did not provide enough detail to independently verify whether the repository contains a functioning exploit, a proof of concept, research notes, or unrelated material. A public GitHub reference exists, but a publicly validated proof of concept could not be confirmed from the reviewed evidence.
No primary-source evidence confirming active exploitation in the wild was identified. Treat the issue as exploitable based on its technical description, and assume that exposed secrets may be abused if logs or other evidence show successful file reads. Preserve evidence before rebuilding affected systems.
How to Detect CVE-2026-105037 Exploitation
Detection should combine application logs, reverse-proxy telemetry, container activity, and account auditing. Look for authenticated requests to file-serving or file-inspection endpoints where the path parameter contains traversal sequences, encoded separators, absolute paths, or references to sensitive operating-system and application files. Because the exact endpoint and parameter name were not provided, search all request fields rather than monitoring one assumed route.
A successful exploit may not produce a distinctive error. Review response sizes, status codes, and authenticated activity by low-privilege users. An unexpectedly large text response, configuration content, environment variables, or source code warrants investigation. Correlate these events with subsequent authentication failures, token use from new locations, and access to connected services.
Technical Notes
A generic reverse-proxy search can identify common traversal indicators. Adapt the field names and log format to the local platform:
grep -Eai \
'(\.\./|%2e%2e|%252e%252e|/etc/passwd|/etc/shadow|/proc/self/environ|(^|[?&])(path|file|filename)=/|%2fetc%2f)' \
/var/log/nginx/access.log /var/log/nginx/access.log*
For structured logs in Elasticsearch or OpenSearch, a starting query is:
http.request.method: * AND
(
url.query: "../" OR
url.query: "%2e%2e" OR
url.query: "/etc/passwd" OR
url.query: "/proc/self/environ" OR
url.query: "filename=/"
)
These patterns are indicators, not proof. URL decoding may occur at the proxy, application, or logging layer, so search both raw and normalized fields. Retain the source IP, authenticated username or subject, endpoint, status code, response size, and request identifier for incident correlation.
Mitigation and Patching
The affected range is 1.6.5–1.8.2. No specific fixed version was confirmed in the reviewed sources, so do not assume that a later-looking tag is safe without vendor validation. Contact EnergizeLab or the platform operator for a patched image digest or release advisory, and record the digest rather than relying solely on a mutable tag.
Until a confirmed fix is available, restrict access to the middleware API and management interfaces through network policy, VPN, firewall rules, or an authenticated gateway. Remove unnecessary registered accounts, review account-creation controls, and ensure ordinary users cannot reach administrative or diagnostic routes. These measures reduce exposure but do not repair the vulnerable file-access logic.
If the vulnerability may have exposed credentials, store replacement secrets in a managed vault or password manager rather than leaving them in shared configuration files. A business password manager such as Try 1Password → can help centralize access controls, rotation workflows, and audit records, but it does not replace patching or incident response.
Technical Notes
Inventory running containers and image references before changing the deployment:
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.ID}}'
docker inspect --format '{{.Name}} {{.Config.Image}} {{.Image}}' <container_name>
docker image ls --digests | grep -E 'station-middleware|energizelab'
After obtaining a vendor-confirmed fixed image, pull it by the supplied tag or digest, stop the affected deployment, and recreate it using the normal deployment manifest:
docker pull <vendor-confirmed-image>@sha256:<vendor-confirmed-digest>
docker compose up -d --force-recreate
docker image prune
Do not substitute an unverified version for <vendor-confirmed-image> or the digest. If the vendor provides only a version tag, validate the image digest and release documentation before production rollout.
Assume that secrets readable by the middleware may have been exposed. Rotate application credentials, API keys, database passwords, session or signing secrets, cloud tokens, and service-account credentials. Review downstream systems for use of those credentials, invalidate active sessions where appropriate, and preserve logs and filesystem evidence before redeploying or deleting the affected container.
Incident-Response Checklist
Organizations operating an affected image should:
- Identify every running
station-middlewarecontainer and record its image tag and digest. - Restrict access to the middleware service and disable unnecessary accounts.
- Preserve reverse-proxy, application, identity, and container logs.
- Search for traversal indicators and unusual file-read responses.
- Determine which files and secrets were readable by the middleware process.
- Rotate potentially exposed credentials, tokens, keys, and session-signing material.
- Obtain and validate a vendor-confirmed fixed image.
- Redeploy the corrected image and verify that the vulnerable version is no longer running.
- Review downstream authentication and API activity for signs of credential misuse.
- Document the incident, remediation evidence, and any remaining exposure.
References
The NVD references include a technical report concerning multiple EnergizeLab Eilik and EilikO platform vulnerabilities. The report is available at https://takeonme.org/cves/multiple-energizelab-eilik-eiliko-platform-vulnerabilities/. It provides the contextual product and vulnerability information used to identify the affected middleware and version range.
Additional references include the GitHub repository https://github.com/xn0tsa/your-secrets-are-safe-with-me and a related technology report at https://www.theverge.com/tech/1010727/eiliko-robot-hack-energize-lab. The CISA Known Exploited Vulnerabilities catalog is available at https://www.cisa.gov/known-exploited-vulnerabilities-catalog.
Check these sources for later vendor advisories, a confirmed fixed image, exploit validation, or a change in exploitation status.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.