CVE-2026-115216 in ioFog
Summary
by MITRE • 10/27/2026
In Eclipse ioFog Operator versions 3.8.0 before 3.9.2, TLS certificate verification is disabled when the operator contacts the Controller API and when it logs in to an external OIDC issuer. An on-path attacker can present any certificate, capture the OAuth client secret (external mode) or the Controller bootstrap admin password (embedded mode with Controller HTTPS enabled), and supply the access token the operator stores for later Controller API calls. v3.8 removed Keycloak. The exposed credential is not a Keycloak realm-admin secret.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability in Eclipse ioFog Operator versions prior to 3.9.2 represents a critical failure in transport layer security implementation, specifically categorized under CWE-295 Improper Certificate Validation and aligned with the MITRE ATT&CK technique T1078 Valid Accounts for credential harvesting via man-in-the-middle attacks. The core technical flaw lies in the operator's configuration of TLS connections to two distinct external services: the Controller API and an external OpenID Connect (OIDC) issuer used for authentication. In these affected versions, the application explicitly disables certificate verification during the handshake process. This misconfiguration effectively neutralizes the primary defense mechanism against on-path attackers who can intercept network traffic between the operator and these remote endpoints. By ignoring server identity validation, the client accepts any presented TLS certificate without verifying its authenticity or chain of trust, allowing an attacker to perform a classic SSL stripping or man-in-the-middle interception attack with impunity.
The operational impact of this vulnerability is severe due to the high-value credentials exposed during the authentication and initialization phases. When operating in external mode, the ioFog Operator communicates with an OIDC provider to authenticate users and obtain access tokens for API calls. During this login process, if certificate verification is disabled, a man-in-the-middle attacker can intercept the OAuth client secret or other sensitive authentication parameters transmitted by the operator. Similarly, in embedded mode where the Controller runs locally but utilizes HTTPS, the initial bootstrap phase involves transmitting an admin password to establish administrative access. Without proper TLS validation, this plaintext credential exchange becomes vulnerable to interception. The attacker does not merely gain read-only access; they can capture these secrets and subsequently generate valid OAuth tokens or authenticate as the administrator, effectively taking full control of the ioFog infrastructure.
The context of version 3.8 is relevant because it removed Keycloak from the default stack, shifting reliance toward external OIDC issuers for identity management. The vulnerability description clarifies that the exposed credential in this scenario is not a Keycloak realm-admin secret, which might imply different privilege levels or recovery procedures. Instead, the attacker gains access to the specific OAuth client credentials or the Controller bootstrap password depending on the deployment mode. This distinction is crucial for incident response, as it indicates that compromising these secrets allows direct impersonation of the operator service itself rather than just gaining administrative rights within a separate identity provider's realm. The captured access token stored by the operator can then be reused to make authenticated API calls to the Controller, enabling the attacker to deploy malicious foglets, exfiltrate data from edge devices, or disrupt critical IoT operations managed through the ioFog platform.
Mitigation strategies must prioritize immediate patching and network segmentation until updates are applied. The primary remediation is upgrading Eclipse ioFog Operator to version 3.9.2 or later, where certificate verification has been restored as a mandatory step in TLS connections. For environments that cannot immediately upgrade, strict network controls should be implemented to prevent unauthorized devices from positioning themselves between the operator and its external dependencies. This includes isolating management traffic on dedicated VLANs and enforcing mutual TLS authentication if supported by the infrastructure components. Additionally, organizations should audit their OIDC issuer configurations to ensure they support robust certificate pinning or alternative mechanisms that do not rely solely on standard PKI validation which can be bypassed in vulnerable client implementations. Regular security audits of edge computing deployments are essential to detect any unauthorized modifications to TLS settings and to monitor for anomalous authentication patterns that might indicate credential theft via this vector.