Eclipse Iofog
Monthly
TLS certificate verification is disabled by default in Eclipse ioFog Operator 3.8.0 through 3.9.1 on the connections it makes to the Controller API and to an external OIDC issuer, so an unauthenticated on-path attacker can present any certificate and be trusted. That position lets the attacker capture the OAuth client secret in external mode, or the Controller bootstrap admin password in embedded mode with Controller HTTPS enabled, and supply the access token the operator stores for later Controller API calls. Exploitation is gated by the requirement to already sit in the traffic path (CVSS 4.0 AT:P), which is the main limiting factor; vendor priority is act_now, and no public exploit has been identified at time of analysis.
Unauthenticated attackers can bypass JWT signature verification in Eclipse ioFog Controller 3.8.0 through 3.9.1 on the operator WebSocket upgrade handlers for the exec and log routes, allowing them to open privileged sessions for any microservice or fog node whose UUID they know. By crafting a token with an 'admin' group claim, the attacker matches the built-in admin role without needing an account or RoleBinding. No public exploit identified at time of analysis, but the flaw is rated CVSS 9.8 and requires immediate attention.
Unauthenticated remote attackers can exhaust Eclipse ioFog Controller 3.8.0 through 3.9.1 by sending small JSON bodies to POST, PUT, or PATCH routes that perform template substitution, stalling or aborting the control-plane process before bearer-token and RBAC checks run. The bearer check does not reject missing or invalid tokens and the DoS rate limit covers only login routes, so a reachable templating route is enough to disrupt the agent API and in-process WebSocket relays. No public exploit was identified at time of analysis, and the impact is limited to availability with no confidentiality or integrity effect; reporting is consistent with a genuine, impact-limited availability threat.
OS command injection in the Eclipse ioFog iofogctl CLI lets whoever can alter the ioFog Controller API response slip shell metacharacters into the provisioning key or CA certificate, which the CLI concatenates into the `edgelet provision` / `edgelet config cert` (or legacy `iofog-agent provision` / `iofog-agent cert`) commands it runs over SSH on the agent host and in the local shell. The issue affects iofogctl 1.0.0 through 3.7.0 and 3.8.0-rc.1 through 3.9.1, and triggering it requires an operator to actively deploy or attach an agent (user interaction) while talking to a Controller whose response has been tampered with; a trusted, authentic Controller is not vulnerable to this path. There is no CISA KEV entry and no public exploit identified at time of analysis, and the vendor fixed the flaw in iofogctl 3.9.2.
TLS certificate verification is disabled by default in Eclipse ioFog Operator 3.8.0 through 3.9.1 on the connections it makes to the Controller API and to an external OIDC issuer, so an unauthenticated on-path attacker can present any certificate and be trusted. That position lets the attacker capture the OAuth client secret in external mode, or the Controller bootstrap admin password in embedded mode with Controller HTTPS enabled, and supply the access token the operator stores for later Controller API calls. Exploitation is gated by the requirement to already sit in the traffic path (CVSS 4.0 AT:P), which is the main limiting factor; vendor priority is act_now, and no public exploit has been identified at time of analysis.
Unauthenticated attackers can bypass JWT signature verification in Eclipse ioFog Controller 3.8.0 through 3.9.1 on the operator WebSocket upgrade handlers for the exec and log routes, allowing them to open privileged sessions for any microservice or fog node whose UUID they know. By crafting a token with an 'admin' group claim, the attacker matches the built-in admin role without needing an account or RoleBinding. No public exploit identified at time of analysis, but the flaw is rated CVSS 9.8 and requires immediate attention.
Unauthenticated remote attackers can exhaust Eclipse ioFog Controller 3.8.0 through 3.9.1 by sending small JSON bodies to POST, PUT, or PATCH routes that perform template substitution, stalling or aborting the control-plane process before bearer-token and RBAC checks run. The bearer check does not reject missing or invalid tokens and the DoS rate limit covers only login routes, so a reachable templating route is enough to disrupt the agent API and in-process WebSocket relays. No public exploit was identified at time of analysis, and the impact is limited to availability with no confidentiality or integrity effect; reporting is consistent with a genuine, impact-limited availability threat.
OS command injection in the Eclipse ioFog iofogctl CLI lets whoever can alter the ioFog Controller API response slip shell metacharacters into the provisioning key or CA certificate, which the CLI concatenates into the `edgelet provision` / `edgelet config cert` (or legacy `iofog-agent provision` / `iofog-agent cert`) commands it runs over SSH on the agent host and in the local shell. The issue affects iofogctl 1.0.0 through 3.7.0 and 3.8.0-rc.1 through 3.9.1, and triggering it requires an operator to actively deploy or attach an agent (user interaction) while talking to a Controller whose response has been tampered with; a trusted, authentic Controller is not vulnerable to this path. There is no CISA KEV entry and no public exploit identified at time of analysis, and the vendor fixed the flaw in iofogctl 3.9.2.