CVE-2026-57898 in BaSyx
Summary
by MITRE • 07/14/2026
In Eclipse BaSyx Java Server SDK versions 2.0.0-milestone-05 to 2.0.0-milestone-12, deployments using the MongoDB backend are vulnerable to an unauthenticated arbitrary file write through the AAS thumbnail API.
The AAS thumbnail upload path accepted a client-controlled fileName request parameter and passed it through repository file handling as both a repository key and, during thumbnail retrieval, a local filesystem path. With the MongoDB file repository, the supplied filename was treated as an opaque GridFS key and was not normalized or restricted as a filesystem path. A remote attacker could upload thumbnail content using an absolute or traversal-style filename, then trigger thumbnail retrieval so that the uploaded bytes were written to the attacker-chosen path on the server filesystem.
This could allow writing files anywhere the Java process has permission to write and may lead to remote code execution. The default InMemory backend is not affected by this specific path because it normalizes and restricts file paths to its temporary directory.
The issue is fixed in Eclipse BaSyx Java Server SDK 2.0.0-milestone-13.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/14/2026
The vulnerability exists within the Eclipse BaSyx Java Server SDK version range 2.0.0-milestone-05 through 2.0.0-milestone-12 when deployed with MongoDB backend configurations. This represents a critical security flaw that enables unauthenticated arbitrary file writing through the Administration Shell (AAS) thumbnail API functionality. The vulnerability stems from improper input validation and sanitization of user-supplied filename parameters within the file handling mechanisms.
The technical implementation flaw occurs in how the system processes client-controlled filename inputs during thumbnail upload operations. When a client submits a thumbnail through the AAS API, the system accepts a fileName parameter that gets used in two distinct contexts: first as a repository key for MongoDB's GridFS storage mechanism and second as a local filesystem path during thumbnail retrieval operations. The MongoDB file repository treats the supplied filename as an opaque GridFS key without applying any normalization or path restriction measures that would typically be required when dealing with filesystem paths.
This design oversight creates a path traversal vulnerability where attackers can manipulate the fileName parameter to include absolute paths or directory traversal sequences such as "../" or "/etc/passwd". When the system later retrieves and processes this thumbnail, it uses the same manipulated filename as a local filesystem path, allowing malicious actors to write content to arbitrary locations on the server's filesystem. The vulnerability specifically affects MongoDB backend deployments because they lack the path sanitization measures that would normally prevent such attacks.
The operational impact of this vulnerability is severe and potentially catastrophic for affected systems. Remote attackers can leverage this vulnerability to write files anywhere within the filesystem where the Java process has write permissions, which could include system directories, configuration files, or even executable locations. This arbitrary file writing capability represents a direct pathway to potential remote code execution, privilege escalation, and complete system compromise. The attack vector does not require authentication, making it particularly dangerous as any external party can exploit this vulnerability without prior access credentials.
The default InMemory backend remains unaffected by this specific vulnerability because it implements proper path normalization and restriction mechanisms that confine file operations to a designated temporary directory. This distinction highlights the importance of secure coding practices in different implementation contexts and demonstrates how backend-specific security controls can either mitigate or exacerbate vulnerabilities. The fix implemented in Eclipse BaSyx Java Server SDK 2.0.0-milestone-13 addresses this by introducing proper input sanitization and path validation measures that prevent malicious filename manipulation.
This vulnerability aligns with CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-73 (External Control of File Name or Path) categories, representing a classic path traversal attack vector. From an ATT&CK framework perspective, this maps to T1059.007 (Command and Scripting Interpreter: JavaScript) and T1499.004 (Constitutional Manipulation: File and Directory Permissions) techniques, as attackers can manipulate file system permissions and potentially execute code through malicious file placement. The vulnerability demonstrates the critical importance of input validation, proper path handling, and secure file operation practices in enterprise software development environments where multiple backend storage mechanisms are supported.