CVE-2026-113620: Eclipse ioFog operator WebSocket accepts an unverified JWT
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.
Affected Software
Event History
Frequently Asked Questions
Which interfaces are vulnerable and which are not?
Only operator WebSocket upgrades on the exec and log routes are affected in Controller versions 3.8.0 through 3.9.1. HTTP routes verify tokens before RBAC, and agent WebSockets verify the fog token, so they are not affected.
What does an attacker need to exploit this?
An attacker needs network access to the vulnerable operator WebSocket endpoint and the UUID of a target microservice or fog. They can use a self-minted bearer JWT whose groups claim contains admin; no legitimate account or RoleBinding is required.
What access can successful exploitation provide?
A successful attacker can open exec or log sessions for a microservice or fog identified by a known UUID. The forged token is treated as an RBAC subject because its groups or roles are decoded without JWT verification.