CVE-2026-113619 in ioFoginfo

Summary

by MITRE • 10/20/2026

In Eclipse ioFog Controller versions 3.8.0 through 3.9.1, POST, PUT, and PATCH bodies on routes that enable template substitution are rendered by an uncapped Liquid engine before authentication and RBAC. The bearer check does not reject a missing or invalid token, and the auth rate limit applies only to user login routes. A small JSON body can stall or abort the Controller process. The anonymous caller does not receive the rendered result; the impact is availability of the control plane, including the agent API and in-process WebSocket relays on that process.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 10/20/2026

The vulnerability identified in Eclipse ioFog Controller versions 3.8.0 through 3.9.1 represents a critical failure in authentication enforcement combined with unsafe template rendering logic. The core technical flaw lies in the processing order of HTTP requests targeting routes that support Liquid template substitution. Specifically, POST, PUT, and PATCH request bodies are passed to an uncapped Liquid engine for rendering before any form of authentication or Role-Based Access Control (RBAC) validation occurs. This architectural misalignment means that unauthenticated actors can trigger complex parsing operations within the controller process without first proving their identity or authorization status. The bearer token verification mechanism is fundamentally broken in this context, as it fails to reject requests containing missing or invalid tokens when they are directed at these specific template-enabled endpoints. Furthermore, existing rate-limiting protections do not apply to anonymous callers because such limits were only configured for user login routes, leaving the vulnerable API endpoints effectively unprotected against high-volume automated attacks.

The operational impact of this vulnerability is primarily centered on service availability and resource exhaustion rather than data confidentiality or integrity in the traditional sense. Because the Liquid engine processes request bodies without size caps or complexity restrictions, an attacker can craft a small JSON payload designed to trigger catastrophic backtracking or infinite loops within the template parser. This results in the stalling or complete abortion of the ioFog Controller process. Since this controller serves as the central management plane for the Eclipse ioFog ecosystem, its compromise leads to a widespread denial of service. The outage affects not only the direct API endpoints but also disrupts critical infrastructure components such as agent APIs and in-process WebSocket relays that depend on the stability of the main controller process. Consequently, connected IoT agents lose their ability to receive commands or report status, effectively paralyzing the managed edge computing environment.

From a classification perspective, this vulnerability aligns with CWE-798, which describes the use of hardcoded credentials or weak authentication mechanisms, although in this case it is more accurately characterized by CWE-20: Improper Input Validation and CWE-1345: Denial of Service via Resource Exhaustion. The lack of input validation on template complexity allows for resource exhaustion attacks that bypass standard security controls. In terms of the MITRE ATT&CK framework, this behavior maps to T1496: Resource Hijacking, where an attacker consumes system resources to degrade performance or cause a denial of service. Additionally, it reflects aspects of T1078: Valid Accounts if we consider the exploitation of missing authentication checks as a form of privilege escalation through bypass, although strictly speaking, no valid account is required due to the pre-authentication rendering flaw. The attack vector is classified as Network-based with Low complexity, requiring only network access and minimal payload construction skills.

Mitigation strategies must address both the immediate technical flaws and broader architectural security principles. The most urgent remediation involves upgrading to a version of Eclipse ioFog Controller where this vulnerability has been patched, ensuring that authentication checks are performed before any template rendering logic is invoked. If an upgrade is not immediately feasible, network-level controls should be implemented to restrict access to the affected API endpoints exclusively from trusted IP ranges or through a reverse proxy that enforces strict rate limiting and token validation prior to forwarding requests to the controller. Input validation must also be strengthened by implementing size limits on request bodies and disabling template substitution features if they are not strictly required for business operations. Security teams should monitor logs for unusual spikes in POST, PUT, and PATCH activity targeting these specific routes, as such patterns may indicate active exploitation attempts aimed at causing denial of service conditions within the control plane infrastructure.

Responsible

Eclipse

Reservation

10/20/2026

Disclosure

10/20/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

medium

Sources

Interested in the pricing of exploits?

See the underground prices here!