---
id: "CVE-2026-113620"
kind: "vulnerability"
aliases: ["CVE-2026-113620"]
title: "Eclipse ioFog Controller: forged token grants admin exec and log access"
severity: "critical"
cvss: 9.8
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: [{"name": "eclipse-iofog-controller", "fixed": ["3.9.2"], "affected": ">= 3.8.0, <= 3.9.1", "ecosystem": "other"}]
ecosystems: []
tags: ["3.8.0-3.9.1", "auth-bypass", "eclipse-iofog-controller", "edge-orchestration", "infrastructure", "other", "self-hosted", "websocket"]
not_affected_if: ["agent-websockets-only", "http-only-usage", "version-outside-3.8.0-3.9.1"]
published_at: "2026-10-20T13:16:41+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-23T23:21:14+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113620", "first_seen_at": "2026-10-23T21:57:20+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-23T23:21:14+00:00"}]
---

# Eclipse ioFog Controller: forged token grants admin exec and log access

ioFog Controller 3.8.0 through 3.9.1 accepts unsigned JWTs on the operator WebSocket exec and log routes and uses the token's groups claim for RBAC. A forged token with groups:[admin] gives an interactive shell in any running microservice container, and live logs, for anyone who can reach the controller API port and knows a microservice or fog UUID. UUIDs can be listed with the same forged admin access. HTTP routes and agent sockets are not affected. Fixed in 3.9.2.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- other:eclipse-iofog-controller affected >= 3.8.0, <= 3.9.1 fixed 3.9.2

## How to check

Check the controller version (3.8.0 to 3.9.1 is affected), for example iofogctl version or the image tag of the controller deployment. Then check whether the controller API port (default 51121) is reachable from untrusted networks. Both ws:// and wss:// upgrades on /api/v3/microservices/exec/<uuid>, /api/v3/microservices/<uuid>/logs and /api/v3/iofog/<uuid>/logs are affected.

## Fix

Upgrade the Controller to 3.9.2. Until then, do not expose the controller API port beyond trusted networks, and block WebSocket upgrades on the exec and logs routes at your proxy.

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-113620
- 2026-10-23T23:21:14+00:00 analyst — Fixed in Controller v3.9.2 (release notes, PR #870). Eclipse report #1270 describes the flaw and a pseudocode PoC, but the report is AI-generated and not human-confirmed. No exploitation reported. x-cli count for ioFog was 0 for the last 7 days. Whether the WebSocket port is exposed beyond the internal network depends on the deployment: the exec and log routes are served on the main API port, 51121 by default.

## Documents

- [advisory] Eclipse vulnerability report #1270: ioFog WebSocket RBAC trusts unverified JWT https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/1270
- [fix] ioFog Controller v3.9.2 release notes https://github.com/eclipse-iofog/Controller/releases/tag/v3.9.2

## From the sources

In Eclipse ioFog Controller versions 3.8.0 through 3.9.1, operator WebSocket upgrades on the exec and log routes do not verify the bearer JWT. The payload is decoded and its groups or roles are used as RBAC subjects. A self-minted token whose groups contain admin matches the built-in admin role, with no account and no RoleBinding. The attacker can open an exec or log session for a microservice or fog whose UUID they already know. HTTP routes are not affected: they verify the token before RBAC. Agent WebSockets verify the fog token and are not affected.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_