CVE-2026-85199 in aeriOS
Summary
by MITRE • 09/03/2026
Eclipse aeriOS Self-orchestrator versions prior to 1.2.1 contain a path traversal vulnerability in the REST API. User-controlled identifiers used to create, update, or delete Self-orchestrator resources were incorporated into filesystem paths without adequate validation or sanitization. An unauthenticated remote attacker able to access the Self-orchestrator API could therefore supply specially crafted identifiers containing path traversal sequences to write or delete JSON files outside the intended application directories, subject to the filesystem permissions of the Self-orchestrator process.
The impact is increased by the absence of authentication on the affected API and by the container running with elevated privileges in the affected deployment configuration.
The issue has been addressed in version 1.2.1 by introducing validation and sanitization of user-controlled identifiers before they are used to construct filesystem paths, preventing path separator characters from being used to escape the intended directories.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
Eclipse aeriOS Self-orchestrator versions prior to release 1.2.1 contain a critical path traversal vulnerability within its REST API interface that allows for unauthorized file system manipulation. This flaw stems directly from CWE-22, which is defined as Improper Limitation of a Pathname to a Restricted Directory. The core technical deficiency lies in the application's handling of user-controlled identifiers when performing create, update, or delete operations on Self-orchestrator resources. Instead of validating these inputs against an allowlist or strictly sanitizing them for directory traversal sequences such as dot-dot-slash characters, the software incorporates these raw values directly into filesystem path construction logic. This lack of adequate input validation permits an attacker to manipulate the intended file location by injecting malicious path components that break out of the designated application directories and access arbitrary locations on the host or container file system.
The operational impact of this vulnerability is significantly amplified by two critical environmental factors present in many deployment configurations: the absence of authentication mechanisms on the affected API endpoints and the execution context of the running process. Because the vulnerable REST endpoint does not require any form of user authentication, an unauthenticated remote attacker can interact with the service directly over the network without needing valid credentials to initiate exploitation attempts. Furthermore, if the container or application is deployed with elevated privileges, such as running under a root account or possessing broad file system permissions, the consequences of successful path traversal become severe. An attacker could potentially overwrite critical configuration files, inject malicious code into executable scripts, delete essential data structures stored in JSON format, or establish persistence mechanisms by writing web shells to accessible directories. This scenario aligns with ATT&CK technique T1083, which covers File and Directory Discovery, as well as T1564, Hidden Files and Directories, if the attacker uses these capabilities to obscure their modifications within the system.
The resolution for this vulnerability was implemented in version 1.2.1 of Eclipse aeriOS Self-orchestrator through rigorous input validation and sanitization measures. The developers introduced checks that specifically target user-controlled identifiers before they are utilized in any filesystem path construction operations. These controls ensure that dangerous characters, including path separators like forward slashes or backslashes depending on the operating system environment, are either rejected outright or safely encoded so they cannot be interpreted as directory navigation commands by the underlying file system API. This fix effectively neutralizes the ability of an attacker to escape the intended application directories and restricts all resource modifications to their designated secure locations. Organizations running affected versions must upgrade immediately to version 1.2.1 or later to mitigate this risk, while also reviewing deployment configurations to ensure that containers do not unnecessarily run with elevated privileges, thereby reducing the blast radius of any potential future vulnerabilities.