CVE-2026-7411 in Eclipse BaSyx Java Server SDK - from those bugs that make you think about the state of security in the entire Industry 4.0 stack. An unauthenticated attacker through one HTTP request to the Submodel API records files in the host directory and receives full code execution. CISA-ADP (SSVC) has classified operation: automatable=yes, technical impact=total, pit. EPSS-scor0 0.0368 (88th Percentage) - the probability of active operation is higher than that of 88% of all registered CVE. Below is a complete analysis of the vulnerability, a step-by-step method of operation and countermeasures for those who pentest industrial APIs.
Business logic of the attack: why break Asset Administration Shell
Eclipse BaSyx - open-source implementation of Asset Administration Shell (AAS), one of the central components of the Industry 4.0 stack. AAS is a digital twin of a physical asset: a CNC machine, an industrial robot, a conveyor line. Through the AAS-interface ERP systems and engineering workstations, manual processes, read telemetry, update hardware configurations.
Compromise of the BaSyx-server - not "an more hacked web service". The attacker receives:
arbitrary recording of files on the host where the Java process BaSyx rotates
potential pivot in the OT segment, if the BaSyx is deployed on the gateway between IT and OT (a complete map of threats and protection of such environments - in a review of cybersecurity critical infrastructure)
the ability to replace the parameters of the digital twin, which in the production environment can lead to physical effects on the equipment
The financial impact is tangible: the stoppage of the production line of the medium enterprise costs hundreds of thousands of rubles per hour. Substitution of AAS parameters can lead to the release of defective products or equipment damage long before the incident is detected.
Eclipse BaSyx and Submodel HTTP API: architecture of the entry point
BaSyx implements the AAS specification as defined by the Industrial Digital Twin Association (IDTA). Main components:
AAS Server - stores asset descriptions (Asset Administration Shells)
Submodel Server - stores subspecies data: parameters, files, hardware configurations
Registry - a catalog of all AAS and sub-submarines that allows you to detect them over the network
Submodel HTTP API gives a REST-interface for CRUD-operations with submodels. Among the operations is the attachment upload, which accepts the parameter fileName to specify the name of the saved file.
In a typical, crash BaSyx works as a Docker container or standalone Java application on standard HTTP ports. On industrial pentests, I regularly find such instances in the configuration "out of the box" - without authentication on the API, with the argument "internal network who will climb here". Detection via Shodan by the characteristic JSON structures of AAS answers is a matter of minutes.
Technical anatomy CVE-2026-7411 Eclipse BaSyx Vulnerability
CVSS 10.0 and CWE-22 - vector analysis
Vulnerability is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). According to the MITRE CWE catalog - the basic type of weakness with the status of Stable and high probability of operation. Executé Unauthorized Code or Commands, Modify Files or Directories, Read Files or Directories.
CVSS-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Let's examine each component:
AV:N (Network) - attack on the network, physical access is not needed
AC:L (L) - no special conditions or configurations required
PR:N (No Privileges) - authentication is not needed
UI:N (No User Interaction) - The victim should not do anything
S:C (Changed Scope) - an attack goes beyond the boundaries of a vulnerable component, from BaSyx SDK to host OS
C:H/I:H/A:H - complete compromising confidentiality, integrity and availability
The final 10.0 points is an accurate reflection of an architectural catastrophe: a remote unautrified attacker records files anywhere on the host. And from writing files to RCE is one technical step.
The correction is available from version 2.0.0-milestone-10.
Root Cause: FileName Without Normalization of Paths
In vulnerable versions when processing file upload in Submodel HTTP API fileName It does not normalize. Java-code does not cause File.getCanonicalPath() to bring the path to the canonical appearance and does not test that the resulting path remains within the target directory of the storage.
The attacker substitutes in fileName Sequence ../ and goes beyond the boundaries of the storage directory. The file is recorded anywhere in the file system to which the Java process has access.
Classic pattern similar to CVE 2021-41381 - directory traversal in Payara Micro Community 5.2021.6 (CVSS 7.5, CWE-22) The fundamental difference: in BaSyx we are talking about a record, not a reading. The Arbitrary file write is directly converted to RCE – and it’s more critically dangerous.
To bypass possible filtering on WAF or reverse proxy, standard coding techniques are used (described in OWASP Testing Guide): URL-encoding %2e%2e%2f Instead of ../, double encoding %252e%252e%252f, mixed slashes ..\/..\/ for Windows hosts, overlong UTF-8 sequence.
Place CVE-2026-7411 the Attack Chain
Adjustments to the environment
For playback on the test stand:
OS: GNU/Linux (Ubuntu 22.04+) or Windows 10/11 with Docker
RAM: at least 4 GB (2 GB for the Docker container BaSyx + attacker tools)
Software: Docker, curl, nmap or masscan, Burp Suite (optional for manual inspection)
Target version: Eclipse BaSyx Java Server SDK < 2.0-milestone-10
Network: Direct Network Access to BaSyx HTTP Port (online-mode)
The concept of application: the technique works both on an external pentest (if BaSyx sticks out on the Internet is less common) and on the internal (main scenario, BaSyx in a corporate or industrial network).
Detection of BaSyx-instantias
On the external pentest, BaSyx is detected via Shodan by characteristic HTTP headers. On the internal - through nmap with the definition of services:
Bash:
nmap -sV --script http-title -p 80,443,8080-8082 target_range/24
BaSyyx returns the characteristic JSON structures of the AAS API on the endpoints /shells and /submodels. Fingerprinting is more reliable in response structure than on a specific port - on real BaSyx pentests often lives on a reverse proxy on standard ports.
Path traversal via file upload
The essence of operation: send multipart file upload request to the Submodel API downloading endpoint, replacing fileName on the path of ../ sequences. The specific URL of the endpoint depends on the version and configuration of the BaSyx - it needs to be determined at the intelligence stage through the study of API answers.
Bash:
curl -X POST "http://target/submodels/{id}/submodel-elements/{elem}/attachment" -F "fileName=../../../tmp/proof.txt" -F "[email protected]"
Practical checking: if file proof.txt appeared in /tmp/ on the host - path traversal confirmed. Further, the attacker chooses the escalation vector to RCE.
From writing files to code execution
The most direct vector: if BaSyx works on top of Tomcat or Jetty, .jsp- the webapps directory file allows you to perform an arbitrary code when you contact this HTTP file. The most versatile vector for GNU/Linux hosts - writing a script in /etc/cron.d/ or SSH keys in ~/.ssh/authorized_keys user of the Java process.
Predictions and limitations of technology
Works if:
Eclipse BaSyx Java Server SDK version < 2.0-milestone-10
Submodel HTTP API is available over the network without authentication
Java-process has the right to record as a target directory on the host
No WAF with active rules on path traversal in multipart body
Does not work if:
SDK version >= 2.0.0-milestone-10 (path-cycle application used)
Docker container launched with flag --read-only(read-only filesystem)
AppArmor or SELinux restricts Java-process recording outside the work directory
Reverse proxy (Nginx, Apache) normalizes the paths before the query to the backend
API Gateway adds mandatory authentication on top of BaSyx
In practice: from the industrial environment where I found BaSyx, the container was often without --read-only, without AppArmor, and the API sticking out without authentication - the standard Docker Compose of the GitHub repository of BaSyx without a single change in the configa. Just copied docker-compose.yml and launched. Working? Works. In production.
How OT-context differs from IT in operation
For pentesters who work mainly with corporate networks, the industrial environment with BaSyx is another planet.
Protocols without authentication. BaSyx often interacts with OPC UA servers and MQTT brokers in the OT segment. OPC UA in industrial networks is often set up with Security Mode "None". MQTT brokers work without TLS and authentication. The BaSyx compromise gives the attacker access to these protocols: reading and writing PLC tags, including Modbus registers (FC3 Read Holding Registers, FC16 Write Multiple Registers), if BaSyx is a gateway.
Physical impact. In IT, server compreeting - data leakage or encryption. In OT - substitution of pressure, temperature, rotation speed. TRITON (2017, attack on the Safety Controlled Systems petrochemical enterprise in the Middle East) and Industroyer (2016, attack on the energy system of Ukraine) showed that cyber attacks on OT lead to physical consequences, up to the threat to the life of personnel.
Patching is not possible by the IT schedule. Updating the BaSyx in the industrial environment may require the shutdown of the production line, coordination with the ACSAV vendor and the FAT/SAT testing. It's not "apt upgrade on the night window."
Segmentation on paper. The Purdue model separates IT (Level 4-5) and OT (Level 0-3). In practice, BaSyx is often placed in DMZ between Level 3 (Operations) and Level 4 (USICE) - to integrate ERP with manufacturing equipment. This makes BaSyx the perfect pivot point from the corporate network in the OT segment. On one project, we found that through BaSyx in DMZ it was possible to reach Modbus-devices directly - segmentation existed only in the documentation.
Detecting attempts to operate
Logs are reverse proxy and BaSyx. Search for queries to file upload endpoint Submodel API, where the parameter fileName contains sequences ../, %2e%2e, %252e. Any request with such patterns in the body of a multipart-request is an indicator of an attempt at operation.
WAF. Rules on path traversal for multipart form data. Standard OWASP CRS (group 930 - LFI) cover the basic patterns, but require adaptation under multipart upload - by default, many WAF do not inspect the body of multipart queries. This is a sore spot: I have seen ModSecurity with CRS 3.x miss ../ in multipart body in default configuration.
Host monitoring. Auditd with a rule for operations write from the user under whom the BaSyx Java process works, outside the work directory. Appearance of new files in /etc/cron.d/, /tmp/, ~/.ssh/ from the BaSyx process - direct IoC.
SIEM-correlation. HTTP POST to the BaSyx API+ create a new Java-process file outside of a regular data storage directory - to generate a high priority alexer.
Business logic of the attack: why break Asset Administration Shell
Eclipse BaSyx - open-source implementation of Asset Administration Shell (AAS), one of the central components of the Industry 4.0 stack. AAS is a digital twin of a physical asset: a CNC machine, an industrial robot, a conveyor line. Through the AAS-interface ERP systems and engineering workstations, manual processes, read telemetry, update hardware configurations.
Compromise of the BaSyx-server - not "an more hacked web service". The attacker receives:
arbitrary recording of files on the host where the Java process BaSyx rotates
potential pivot in the OT segment, if the BaSyx is deployed on the gateway between IT and OT (a complete map of threats and protection of such environments - in a review of cybersecurity critical infrastructure)
the ability to replace the parameters of the digital twin, which in the production environment can lead to physical effects on the equipment
The financial impact is tangible: the stoppage of the production line of the medium enterprise costs hundreds of thousands of rubles per hour. Substitution of AAS parameters can lead to the release of defective products or equipment damage long before the incident is detected.
Eclipse BaSyx and Submodel HTTP API: architecture of the entry point
BaSyx implements the AAS specification as defined by the Industrial Digital Twin Association (IDTA). Main components:
AAS Server - stores asset descriptions (Asset Administration Shells)
Submodel Server - stores subspecies data: parameters, files, hardware configurations
Registry - a catalog of all AAS and sub-submarines that allows you to detect them over the network
Submodel HTTP API gives a REST-interface for CRUD-operations with submodels. Among the operations is the attachment upload, which accepts the parameter fileName to specify the name of the saved file.
In a typical, crash BaSyx works as a Docker container or standalone Java application on standard HTTP ports. On industrial pentests, I regularly find such instances in the configuration "out of the box" - without authentication on the API, with the argument "internal network who will climb here". Detection via Shodan by the characteristic JSON structures of AAS answers is a matter of minutes.
Technical anatomy CVE-2026-7411 Eclipse BaSyx Vulnerability
CVSS 10.0 and CWE-22 - vector analysis
Vulnerability is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). According to the MITRE CWE catalog - the basic type of weakness with the status of Stable and high probability of operation. Executé Unauthorized Code or Commands, Modify Files or Directories, Read Files or Directories.
CVSS-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Let's examine each component:
AV:N (Network) - attack on the network, physical access is not needed
AC:L (L) - no special conditions or configurations required
PR:N (No Privileges) - authentication is not needed
UI:N (No User Interaction) - The victim should not do anything
S:C (Changed Scope) - an attack goes beyond the boundaries of a vulnerable component, from BaSyx SDK to host OS
C:H/I:H/A:H - complete compromising confidentiality, integrity and availability
The final 10.0 points is an accurate reflection of an architectural catastrophe: a remote unautrified attacker records files anywhere on the host. And from writing files to RCE is one technical step.
The correction is available from version 2.0.0-milestone-10.
Root Cause: FileName Without Normalization of Paths
In vulnerable versions when processing file upload in Submodel HTTP API fileName It does not normalize. Java-code does not cause File.getCanonicalPath() to bring the path to the canonical appearance and does not test that the resulting path remains within the target directory of the storage.
The attacker substitutes in fileName Sequence ../ and goes beyond the boundaries of the storage directory. The file is recorded anywhere in the file system to which the Java process has access.
Classic pattern similar to CVE 2021-41381 - directory traversal in Payara Micro Community 5.2021.6 (CVSS 7.5, CWE-22) The fundamental difference: in BaSyx we are talking about a record, not a reading. The Arbitrary file write is directly converted to RCE – and it’s more critically dangerous.
To bypass possible filtering on WAF or reverse proxy, standard coding techniques are used (described in OWASP Testing Guide): URL-encoding %2e%2e%2f Instead of ../, double encoding %252e%252e%252f, mixed slashes ..\/..\/ for Windows hosts, overlong UTF-8 sequence.
Place CVE-2026-7411 the Attack Chain
Adjustments to the environment
For playback on the test stand:
OS: GNU/Linux (Ubuntu 22.04+) or Windows 10/11 with Docker
RAM: at least 4 GB (2 GB for the Docker container BaSyx + attacker tools)
Software: Docker, curl, nmap or masscan, Burp Suite (optional for manual inspection)
Target version: Eclipse BaSyx Java Server SDK < 2.0-milestone-10
Network: Direct Network Access to BaSyx HTTP Port (online-mode)
The concept of application: the technique works both on an external pentest (if BaSyx sticks out on the Internet is less common) and on the internal (main scenario, BaSyx in a corporate or industrial network).
Detection of BaSyx-instantias
On the external pentest, BaSyx is detected via Shodan by characteristic HTTP headers. On the internal - through nmap with the definition of services:
Bash:
nmap -sV --script http-title -p 80,443,8080-8082 target_range/24
BaSyyx returns the characteristic JSON structures of the AAS API on the endpoints /shells and /submodels. Fingerprinting is more reliable in response structure than on a specific port - on real BaSyx pentests often lives on a reverse proxy on standard ports.
Path traversal via file upload
The essence of operation: send multipart file upload request to the Submodel API downloading endpoint, replacing fileName on the path of ../ sequences. The specific URL of the endpoint depends on the version and configuration of the BaSyx - it needs to be determined at the intelligence stage through the study of API answers.
Bash:
curl -X POST "http://target/submodels/{id}/submodel-elements/{elem}/attachment" -F "fileName=../../../tmp/proof.txt" -F "[email protected]"
Practical checking: if file proof.txt appeared in /tmp/ on the host - path traversal confirmed. Further, the attacker chooses the escalation vector to RCE.
From writing files to code execution
The most direct vector: if BaSyx works on top of Tomcat or Jetty, .jsp- the webapps directory file allows you to perform an arbitrary code when you contact this HTTP file. The most versatile vector for GNU/Linux hosts - writing a script in /etc/cron.d/ or SSH keys in ~/.ssh/authorized_keys user of the Java process.
Predictions and limitations of technology
Works if:
Eclipse BaSyx Java Server SDK version < 2.0-milestone-10
Submodel HTTP API is available over the network without authentication
Java-process has the right to record as a target directory on the host
No WAF with active rules on path traversal in multipart body
Does not work if:
SDK version >= 2.0.0-milestone-10 (path-cycle application used)
Docker container launched with flag --read-only(read-only filesystem)
AppArmor or SELinux restricts Java-process recording outside the work directory
Reverse proxy (Nginx, Apache) normalizes the paths before the query to the backend
API Gateway adds mandatory authentication on top of BaSyx
In practice: from the industrial environment where I found BaSyx, the container was often without --read-only, without AppArmor, and the API sticking out without authentication - the standard Docker Compose of the GitHub repository of BaSyx without a single change in the configa. Just copied docker-compose.yml and launched. Working? Works. In production.
How OT-context differs from IT in operation
For pentesters who work mainly with corporate networks, the industrial environment with BaSyx is another planet.
Protocols without authentication. BaSyx often interacts with OPC UA servers and MQTT brokers in the OT segment. OPC UA in industrial networks is often set up with Security Mode "None". MQTT brokers work without TLS and authentication. The BaSyx compromise gives the attacker access to these protocols: reading and writing PLC tags, including Modbus registers (FC3 Read Holding Registers, FC16 Write Multiple Registers), if BaSyx is a gateway.
Physical impact. In IT, server compreeting - data leakage or encryption. In OT - substitution of pressure, temperature, rotation speed. TRITON (2017, attack on the Safety Controlled Systems petrochemical enterprise in the Middle East) and Industroyer (2016, attack on the energy system of Ukraine) showed that cyber attacks on OT lead to physical consequences, up to the threat to the life of personnel.
Patching is not possible by the IT schedule. Updating the BaSyx in the industrial environment may require the shutdown of the production line, coordination with the ACSAV vendor and the FAT/SAT testing. It's not "apt upgrade on the night window."
Segmentation on paper. The Purdue model separates IT (Level 4-5) and OT (Level 0-3). In practice, BaSyx is often placed in DMZ between Level 3 (Operations) and Level 4 (USICE) - to integrate ERP with manufacturing equipment. This makes BaSyx the perfect pivot point from the corporate network in the OT segment. On one project, we found that through BaSyx in DMZ it was possible to reach Modbus-devices directly - segmentation existed only in the documentation.
Detecting attempts to operate
Logs are reverse proxy and BaSyx. Search for queries to file upload endpoint Submodel API, where the parameter fileName contains sequences ../, %2e%2e, %252e. Any request with such patterns in the body of a multipart-request is an indicator of an attempt at operation.
WAF. Rules on path traversal for multipart form data. Standard OWASP CRS (group 930 - LFI) cover the basic patterns, but require adaptation under multipart upload - by default, many WAF do not inspect the body of multipart queries. This is a sore spot: I have seen ModSecurity with CRS 3.x miss ../ in multipart body in default configuration.
Host monitoring. Auditd with a rule for operations write from the user under whom the BaSyx Java process works, outside the work directory. Appearance of new files in /etc/cron.d/, /tmp/, ~/.ssh/ from the BaSyx process - direct IoC.
SIEM-correlation. HTTP POST to the BaSyx API+ create a new Java-process file outside of a regular data storage directory - to generate a high priority alexer.
