The canonical narrative of OT security has been about legacy. Unsupported Windows versions running SCADA software. PLCs with 20-year-old firmware that cannot be updated without shutting down production for a week. Historian servers running SQL Server 2008. The security debt of operational technology environments has been framed as a problem inherited from an era when industrial systems were air-gapped and security was not part of the design brief.
Eclipse BaSyx’s CVSS 10.0 vulnerability tells a different story. BaSyx is not legacy software. It is a modern, actively maintained, open-source project developed by the Eclipse Foundation in response to current Industry 4.0 and Industrial IoT standards. It is the reference implementation of a current IEC standard for industrial digital twins. Organisations deploying it are making an architectural choice to integrate their OT and IT environments using current technology — not maintaining legacy systems because they cannot change them.
And it has a CVSS 10.0 vulnerability in its file upload endpoint.
What Changed in the OT Architecture
A decade ago, the boundary between IT and OT was largely a network segmentation question. Operational technology systems were physically separated or connected via unidirectional data diodes. The attack surface was limited by air-gap — an attacker who compromised an IT system could not directly reach OT equipment.
Industry 4.0, smart manufacturing, and Industrial IoT have systematically dismantled that boundary in pursuit of operational benefits: real-time production data feeding analytics platforms, remote monitoring reducing maintenance costs, predictive models requiring direct access to sensor data. Each of these capabilities requires bidirectional network connectivity between IT and OT.
The new architecture creates new attack surface that did not exist in the legacy model. Asset Administration Shell servers, IIoT gateways, industrial data historians with cloud synchronisation, and MES systems with ERP integration all sit at the IT/OT boundary with network access in both directions. These components are modern, maintained software — but they are being deployed into network positions that were previously occupied by deliberately isolated, no-external-connectivity infrastructure.
The security scrutiny applied to that deployment is often insufficient for the risk.
The Integration Layer as Attack Surface
CVE-2026-7411’s CVSS 10.0 score reflects the combination of two factors: maximum impact (arbitrary code execution on a system that bridges IT and OT networks) and maximum exploitability (unauthenticated, remotely accessible, via a standard HTTP endpoint). That combination should have been caught in a security review before the software was deployed at an OT/IT boundary.
The pattern BaSyx represents is not unique. IIoT middleware platforms, industrial API gateways, and OT data integration components generally receive lighter pre-deployment security review than equivalent IT-layer software. The justification is usually some variation of “it’s only accessible from internal networks” — which is true right up until the point where the network access control assumption proves incorrect, or the component needs to be externally accessible for a specific integration requirement, or the external network access assumption was wrong from the start.
The result is a growing population of software components deployed in privileged OT-adjacent network positions that have been reviewed for functional correctness but not for the security properties their network position demands.
What Good Looks Like
Middleware components deployed at OT/IT boundaries should be treated as high-risk attack surface, not as internal infrastructure. Concretely:
The authentication model should match the network position. A component with network access to both OT and IT environments should require strong authentication for all functions — not just administrative functions. “Internal access only” is not equivalent to “unauthenticated is acceptable.”
The principle of least privilege should be enforced at the network layer. BaSyx’s file upload vulnerability is exploitable because the file upload endpoint is network-accessible. If file upload capability is not required for the core integration function, the endpoint should not exist on the network-accessible interface. Network access control at the component level — not just at the perimeter — limits the exploitable surface.
Procurement and deployment processes for OT-adjacent middleware should include security assessment. “Is this Eclipse Foundation open-source software with an active community?” is not a security review. The same SBOM, vulnerability scan, and architecture assessment required for IT-layer components should apply to integration middleware, with additional attention to the OT network access context.
The ICS security problem has not been solved by modernising from legacy OT to Industry 4.0. It has been transformed from a legacy debt problem into an active deployment decision problem — which is, in some ways, more tractable. But only if the security community treats it as such.
Share this article