CVE-2026-113620
9.8CriticalPublished 20 Oct 2026 · NVD status: Received · AI triage by gemini-3.8-flash
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
- Impact
- Full C/I/A compromise
- Weakness
- CWE-347
Impact
Remote, unauthenticated attackers can execute commands or read logs across microservices and fogs. They only need network access to the Controller and the target entity's UUID to forge an admin JWT.
Root cause
WebSocket upgrade handlers for exec and log endpoints decode bearer JWTs and evaluate RBAC claims without validating the token signature.
Affected systems
Eclipse ioFog Controller 3.8.0 through 3.9.1
CVSS v3.1 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Fix & remediation
Upgrade to ioFog Controller version > 3.9.1 once released; until patched, block external WebSocket upgrade requests targeting the exec and log paths at your reverse proxy or ingress.
AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
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.