Live › vulnerability › CVE-2026-115216
Go to dashboardThe Eclipse ioFog Operator versions 3.8.0 before 3.9.2 does not verify TLS certificates when it contacts the Controller API or logs in to an external OIDC issuer. An on-path attacker can present any certificate, capture the OAuth client secret or the Controller bootstrap admin password, and use the access token the operator stores.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 12:31 UTC. All times on this page are UTC.
Teams running the Eclipse ioFog Operator from 3.8.0 up to 3.9.2 that talk to the Controller API over a network an attacker could sit on, or that log in to an external OIDC issuer. Deployments on a trusted, isolated network still carry risk from anyone who can intercept traffic between the operator and the Controller. Teams on 3.9.2 or later, or running a version before 3.8.0, are not affected by this flaw.
No product ranges from the sources yet.
3.8.0 up to but not including 3.9.23.9.2 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-115216")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.