Eclipse aeriOS CVE-2026-84736

Exploitation requires the attacker to occupy a man-in-the-middle network position on the path between the Eclipse aeriOS Federator and any external HTTPS service it contacts (OAuth servers, federated identity endpoints, external APIs). This network interception position is the sole non-trivial prerequisite. The vulnerable condition is active by default in all Docker Compose and Helm chart deployments, since TLS_CERTIFICATE_VALIDATION was explicitly set to false in the shipped docker-compose.yaml and helm-chart/values.yaml. No authentication or Federator account is required on the attacker side. Exploitation is limited to environments running pre-release Eclipse aeriOS Federator builds, and to network topologies where the attacker can intercept outbound HTTPS traffic - isolated or private-cluster deployments with no untrusted network adjacency are not practically exploitable.

The CVSS 4.0 score of 8.3 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N) is broadly consistent with the vulnerability's character, though AT:P correctly captures the non-trivial prerequisite of a network interception position. EPSS data is not available in the source intelligence, and the product's pre-release status means its installed base is extremely small, keeping realistic exploitation probability low despite the high theoretical impact. There is no CISA KEV listing and no known public exploit code. The credential types at risk - OAuth client secrets and bearer tokens - are high-value targets that could enable downstream compromise of federated identity services, so even a mid-sized municipal IT team in bytom piloting this component in a shared network segment should treat TLS validation as a non-negotiable configuration requirement before any production exposure. The primary real-world risk limiter is the pre-release deployment footprint: organizations running development builds of Eclipse aeriOS in non-isolated network environments are the realistic affected population.

An attacker with access to a shared network segment - or control of an intermediate router - between the Federator and an external OAuth authorization server performs a standard MITM attack using tooling such as mitmproxy or Bettercap, presenting a self-signed or attacker-controlled TLS certificate. Because the Federator skips all certificate validation, it establishes the TLS session without complaint and transmits OAuth client credentials and access tokens directly to the attacker. No public exploit code is known; the attack requires only network positioning and off-the-shelf MITM tooling.