Eclipse ioFog Controller CVE-2026-113620

Exploitation targets specifically the operator WebSocket upgrade handlers on the 'exec' and 'log' routes of Eclipse ioFog Controller 3.8.0-3.9.1, which decode the bearer JWT and use its 'groups'/'roles' claims as RBAC subjects without verifying the token signature; a forged token containing a group named 'admin' matches the built-in admin role with no account and no RoleBinding required. The key limiting factor is that the attacker must already know the UUID of the target microservice or fog node to open a session. Not exploitable via this path: HTTP routes (they verify the token before RBAC) and agent WebSockets (they verify the fog token), so only the operator exec/log WebSocket surface is at risk.

All available signals point to a genuinely high-priority flaw rather than an inflated CVSS score. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H, score 9.8) is well-supported by the description: the exec and log WebSocket upgrade routes decode the bearer JWT without verifying its signature, so a remote, unauthenticated attacker can forge a token whose 'groups' claim contains 'admin' and be mapped to the built-in admin role - a textbook CWE-347 cryptographic-signature verification failure. No EPSS score, CISA KEV entry, or public POC was provided in the input, so there is no evidence of active exploitation or mass scanning yet. The one real-world dampener is that the attacker must already know the target microservice or fog UUID, which the CVSS AC:L metric does not capture; this makes opportunistic internet-wide exploitation harder than the 9.8 implies and nudges practical risk toward targeted attackers with prior knowledge of the environment. Conflicting signal to note: the input tag set labels this 'Information Disclosure', but an exec session grants command execution on the targeted workload, i.e. integrity and availability impact well beyond disclosure - verify scope with the Eclipse advisory. Net: real priority for anyone running affected ioFog Controller versions, but absent EPSS/KEV/POC the exploitation is best characterized as plausible/targeted rather than confirmed or widespread.

An attacker who has learned the UUID of a target microservice or fog node (e.g. from prior reconnaissance or insider knowledge) crafts a JWT locally with a 'groups' claim of 'admin', no valid signature required. They open a WebSocket upgrade to the exec route on the ioFog Controller; because the signature is never checked, the forged admin claim is accepted and they obtain an interactive exec session on the workload. No public exploit code was identified at time of analysis, but the attack requires only standard tooling to mint a token.