Skip to main content

ioFog Operator EUVDEUVD-2026-110758

| CVE-2026-115216 CRITICAL
Improper Certificate Validation (CWE-295)
2026-10-27 eclipse GHSA-mvpf-rh77-cjfw
9.1
CVSS 4.0 · Vendor: eclipse
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain on-path network position between operator and Controller/OIDC
  2. Delivery
    Present forged TLS certificate accepted without verification
  3. Exploit
    Capture OAuth client secret or bootstrap admin password
  4. Execution
    Supply attacker-controlled access token to operator
  5. Impact
    Impersonate operator against Controller API

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
Exploitation Conditions

Exploitation requires the attacker to hold an on-path (man-in-the-middle) position between the ioFog Operator and either the Controller API or the external OIDC issuer; this is the limiting factor that distinguishes it from a fully remote bug and corresponds to the AT:P metric. The underlying flaw is unconditional for affected versions: TLS certificate verification is disabled by default in Operator 3.8.0 through before 3.9.2 on these connections, so no non-default configuration is needed to make the operator accept a forged certificate. Which credential is exposed depends on deployment mode: external mode exposes the OAuth client secret; embedded mode exposes the Controller bootstrap admin password, and only when Controller HTTPS is enabled. No user interaction or prior authentication is required of the attacker beyond the network position.

Impact

This is a genuine high-priority issue, not an inflated CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 9.1 and the vuln.today decision label is act_now, with a vendor patch available (v3.9.2). The single most important nuance is the AT:P metric (Attack Requirements: Present): this is CWE-295 improper certificate validation, so exploitation requires the attacker to achieve an on-path/man-in-the-middle position between the ioFog Operator and either the Controller API or the external OIDC issuer - it is not a purely remote 'send a packet' bug. No EPSS score, no CISA KEV entry, and no POC reference are present in the supplied data; per the precision rules this means 'no public exploit identified at time of analysis.' Absence of EPSS/KEV/POC is not itself evidence of low risk, but it does mean active or widespread exploitation is not demonstrated here. The impact is serious once the on-path condition is met: the operator captures long-lived secrets (OAuth client secret in external mode, or the Controller bootstrap admin password in embedded mode with Controller HTTPS enabled) and accepts an attacker-supplied access token, which is why the 4.0 vector carries VC:H plus subsequent-system impact SC:H/SI:H. Net assessment: treat as act_now because of the credential-theft impact and available patch, while recognizing that the on-path prerequisite makes opportunistic internet-wide exploitation less likely than the raw 9.1 suggests.

Exploit ScenarioDerived

An attacker who can intercept traffic on the network path between the ioFog Operator and the Controller/OIDC issuer (e.g. a compromised segment or rogue gateway in the edge/cluster network) presents any TLS certificate, which the operator accepts because certificate verification is disabled. In external mode the attacker harvests the OAuth client secret, or in embedded mode (Controller HTTPS enabled) the Controller bootstrap admin password, and feeds the operator an attacker-controlled access token used for subsequent Controller API calls. No public exploit code is identified at time of analysis, and the on-path requirement means this is not a one-shot remote exploit against an arbitrary internet host.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 28, 2026

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.

RemediationAI

Vendor-released patch: 3.9.2 - upgrade Eclipse ioFog Operator to v3.9.2, which restores certificate verification for the Controller, OIDC and SDK clients (PR #79) and requires TLS 1.2 on Controller and issuer connections (PR #80); published artifacts include ghcr.io/eclipse-iofog/operator:3.9.2, ghcr.io/eclipse-iofog/operator-bundle:3.9.2, the iofog-operator-3.9.2.tgz Helm chart, and the manifests-datasance-3.9.2 / manifests-iofog-3.9.2 tarballs. Because an on-path attacker on an affected version can capture credentials, rotate the external OIDC OAuth client secret and, in embedded deployments with Controller HTTPS enabled, the Controller bootstrap admin password after upgrading, and review Controller API tokens the operator stored while unpatched. The supplied references do not document a configuration-only workaround that re-enables certificate verification in 3.8.x-3.9.1, so applying 3.9.2 is the complete fix; see https://github.com/eclipse-iofog/iofog-operator/releases/tag/v3.9.2 and https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/1064.

Affected VersionsENISA

Eclipse ioFog 3.8.0 <3.9.2

Affected Packages

euvd eclipse_iofog fix: 3.9.2

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Eclipse ioFog Operator is a Kubernetes operator that deploys and manages ioFog Controller and Agent components, and in the affected range it acts as a TLS client toward two endpoints: the ioFog Controller API and, in external auth mode, an external OIDC issuer. The root cause is CWE-295, improper certificate validation - certificate verification was disabled for these client connections, so chain and hostname checks provided no protection and a forged certificate was accepted. The trusted-boundary consequences are why the assessment scores scope as changed (S:C): the failure lets an attacker impersonate the Controller to the operator and vice versa, influence the token the operator stores, and expose a credential that the operator legitimately handles. Release v3.9.2 fixes this through PR #79 ("tls verify for controller oidc and sdk client, helm chart update") and PR #80, which additionally requires TLS 1.2 on the Controller and issuer clients. The vendor notes that v3.8 removed Keycloak and that the credential exposed here is not a Keycloak realm-admin secret - the material at risk is the OAuth client secret (external mode) or the Controller bootstrap admin password (embedded mode, Controller HTTPS enabled).

Know when Eclipse Iofog gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (eclipse) PRIMARY 9.1 CRITICAL
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:N
vuln.today AI 8.1 HIGH

On-path MITM position needed so AC:H; no privileges/interaction (PR:N/UI:N); captured secrets give C:H; token injection yields limited I/A; compromise of the separate Controller justifies S:C.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:L
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:N

Primary rating from Vendor (eclipse).

CVSS VectorVendor: eclipse

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
Low
Vulnerable system: Availability
Low
Subsequent system: Confidentiality
High
Subsequent system: Integrity
High
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch available
Oct 27, 2026 - 12:01 EUVD
CVE Published
Oct 27, 2026 - 11:34 cve.org
CRITICAL 9.1

DescriptionCVE.org

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.

Executive ViewAI

Why It Matters

Eclipse ioFog Operator versions 3.8.0 through 3.9.1 ship with TLS certificate verification disabled by default, allowing an attacker positioned on the network path to intercept and trust any certificate, thereby capturing OAuth client secrets or Controller bootstrap admin passwords and injecting access tokens. This undermines the trust chain for Controller API communications, potentially granting unauthorized control over edge orchestration infrastructure. Leadership should care because exploitation, while requiring a man-in-the-middle position, can lead to full compromise of the ioFog control plane and exposure of sensitive credentials.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 85% exploitable
Prevalence
Low
Eclipse ioFog is a niche open-source edge/fog computing platform
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

46
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +46
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy