EUVD-2026-43635
GHSA-4w7g-2ph6-pm6g
Severity by source
AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Network unauthenticated (AV:N/PR:N) but AC:H due to required MongoDB backend and two-step trigger; primary impact is arbitrary write (I:H) with potential RCE (A:H), limited direct read (C:L), and S:C for writing outside the intended store.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
Lifecycle Timeline
3DescriptionCVE.org
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.
Articles & Coverage 2
AnalysisAI
Unauthenticated arbitrary file write in Eclipse BaSyx Java Server SDK (2.0.0-milestone-05 through 2.0.0-milestone-12) lets remote attackers plant files anywhere the Java process can write when the server is deployed with the MongoDB file backend, potentially escalating to remote code execution. The AAS thumbnail API trusts a client-supplied fileName that is later reused as a filesystem path, so a traversal or absolute-path filename lands attacker-controlled bytes outside the intended directory. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, but the vendor-fixed release (2.0.0-milestone-13) is available.
Technical ContextAI
Eclipse BaSyx is an open-source implementation of the Industrie 4.0 Asset Administration Shell (AAS), and this flaw lives in the AAS repository's thumbnail upload/retrieval feature. The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / path traversal): a single client-controlled fileName parameter is overloaded as both a repository key and a local filesystem path. With the MongoDB (GridFS) file repository, the value is treated as an opaque GridFS key and is never normalized or constrained to a base directory, so during thumbnail retrieval the same string is used to write to disk at an attacker-chosen location. The CPE cpe:2.3:a:eclipse_foundation:eclipse_basyx_-_java_server_sdk confirms the affected component is the Java Server SDK. The default InMemory backend is not exploitable through this path because it normalizes and confines paths to its temporary directory.
RemediationAI
Upgrade to Eclipse BaSyx Java Server SDK 2.0.0-milestone-13, which contains the vendor fix (Vendor-released patch: 2.0.0-milestone-13); this is the primary and recommended action. If you cannot upgrade immediately, the most effective compensating control is to switch the file repository from the MongoDB backend to the default InMemory backend, which normalizes and confines file paths and is not affected - the trade-off is loss of MongoDB-backed persistence for AAS files. Additional interim measures include restricting network access to the AAS thumbnail upload/retrieval endpoints to trusted clients only (via a reverse proxy or network ACL, accepting reduced accessibility for legitimate integrations) and running the BaSyx Java process under a least-privilege account so any successful write is confined to non-sensitive directories, reducing but not eliminating RCE potential. Track remediation details via https://gitlab.eclipse.org/security/cve-assignment/-/work_items/159.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same weakness CWE-22 – Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today