CVE-2026-7412 Overview
CVE-2026-7412 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in the Eclipse BaSyx Java Server SDK. The flaw exists in the Operation Delegation feature, which fails to validate the destination Uniform Resource Identifier (URI) of delegated requests. An unauthenticated remote attacker can coerce the BaSyx server into issuing blind HTTP POST requests to arbitrary internal or external endpoints. This breaks network segmentation boundaries and enables pivoting into isolated Information Technology (IT) and Operational Technology (OT) infrastructure. Attackers can also target Cloud Metadata services such as the Instance Metadata Service (IMDS) to harvest cloud credentials. The vulnerability affects Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10.
Critical Impact
Unauthenticated SSRF allowing attackers to bypass network segmentation, pivot into OT environments, and exfiltrate cloud credentials from IMDS endpoints.
Affected Products
- Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10
- Operation Delegation feature within BaSyx server components
- Industry 4.0 deployments using BaSyx as an Asset Administration Shell (AAS) middleware
Discovery Timeline
- 2026-05-05 - CVE-2026-7412 published to the National Vulnerability Database (NVD)
- 2026-05-06 - Last updated in NVD database
Technical Details for CVE-2026-7412
Vulnerability Analysis
Eclipse BaSyx is an open-source middleware implementing the Asset Administration Shell standard for Industry 4.0. The Operation Delegation feature lets a BaSyx server forward operation invocations to a remote endpoint defined by a URI. The server accepts attacker-controlled URIs without applying allow-list checks, scheme restrictions, or destination validation. This design flaw lets remote callers redirect outbound traffic anywhere reachable from the server.
Because the request is issued server-side, the attacker abuses the trust boundary of the BaSyx host. The HTTP POST is blind, meaning the attacker does not need to read the response to achieve impact. Side effects on internal services, metadata endpoints, and OT controllers create the harm.
Root Cause
The root cause is missing validation of the delegated request destination. The Operation Delegation handler treats the configured URI as trusted input and forwards traffic without enforcing scheme, host, or network-zone restrictions. No authentication is required to trigger the delegated request, which compounds exposure on internet-facing deployments.
Attack Vector
The attack vector is network-based and unauthenticated. An attacker sends a crafted request that causes the BaSyx server to invoke Operation Delegation against a target of the attacker's choosing. Common abuse paths include POST requests to http://169.254.169.254/ to extract cloud Identity and Access Management (IAM) credentials from AWS, Azure, or GCP metadata services. Attackers can also reach internal management interfaces, Programmable Logic Controllers (PLCs), and Supervisory Control and Data Acquisition (SCADA) systems that rely on network isolation rather than authentication.
No verified exploit code is publicly available. Refer to the Eclipse Vulnerability Report Issue for technical details.
Detection Methods for CVE-2026-7412
Indicators of Compromise
- Outbound HTTP POST requests from the BaSyx server process to 169.254.169.254, metadata.google.internal, or fd00:ec2::254
- Unexpected BaSyx-originated traffic to internal RFC1918 ranges, OT VLANs, or PLC management ports
- Operation Delegation configuration entries referencing unfamiliar external hosts in BaSyx logs
Detection Strategies
- Inspect BaSyx application logs for Operation Delegation invocations and record the destination URI of each delegated request
- Deploy egress firewall logging on BaSyx hosts and alert on connections leaving the segment where the server resides
- Correlate web access logs showing unauthenticated requests to BaSyx Operation endpoints with subsequent outbound POST traffic
Monitoring Recommendations
- Block or alert on traffic from application servers to cloud metadata IP addresses unless explicitly required
- Monitor BaSyx process network behavior for connections to OT subnets, ICS protocols, or administrative interfaces
- Track the rate of Operation Delegation invocations and flag anomalies tied to specific source IPs or User-Agent strings
How to Mitigate CVE-2026-7412
Immediate Actions Required
- Upgrade Eclipse BaSyx Java Server SDK to version 2.0.0-milestone-10 or later
- Restrict inbound network access to BaSyx Operation endpoints using a reverse proxy with authentication
- Apply IMDSv2 with hop-limit 1 on AWS instances hosting BaSyx to defeat metadata theft via SSRF
- Audit BaSyx configuration for any pre-existing Operation Delegation entries pointing to unexpected destinations
Patch Information
The fix is delivered in Eclipse BaSyx Java Server SDK 2.0.0-milestone-10. Coordination details are tracked in the Eclipse CVE Assignment Issue and the Eclipse Vulnerability Report Issue. Operators should validate the upgrade in a staging environment before promoting to production OT-adjacent deployments.
Workarounds
- Place BaSyx behind an egress proxy that allow-lists specific delegation targets and blocks link-local, loopback, and RFC1918 destinations
- Run BaSyx in a network segment with no route to cloud metadata services or OT control networks
- Disable the Operation Delegation feature in environments where it is not required
- Enforce authentication on all BaSyx HTTP endpoints using a Web Application Firewall (WAF) or API gateway until the patch is applied
# Example egress restriction using iptables on the BaSyx host
iptables -A OUTPUT -m owner --uid-owner basyx -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner basyx -d 10.0.0.0/8 -p tcp --dport 502 -j REJECT
iptables -A OUTPUT -m owner --uid-owner basyx -d 192.168.0.0/16 -p tcp --dport 44818 -j REJECT
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
