CVE-2026-65985 Overview
FUXA is a web-based Process Visualization software used for SCADA, HMI, and dashboard workloads. CVE-2026-65985 is a Server-Side Request Forgery (SSRF) vulnerability affecting FUXA version 1.3.2 and earlier. The device-webapi-request Socket.IO handler in server/runtime/index.js allows an authenticated non-admin runtime user to control the property.address field. The FUXA server then issues an outbound HTTP or HTTPS request and returns the response body to the requesting socket. Attackers can turn the server into a read-based SSRF oracle against internal services and cloud metadata endpoints. The issue is fixed in version 1.3.3.
Critical Impact
Authenticated non-admin users can coerce the FUXA server into making arbitrary outbound HTTP/HTTPS requests and receive the response, enabling reconnaissance of internal networks and theft of cloud instance metadata credentials.
Affected Products
- FUXA version 1.3.2 and earlier
- FUXA server component server/runtime/index.js
- Deployments exposing the Socket.IO device-webapi-request handler to non-admin runtime users
Discovery Timeline
- 2026-08-18 - CVE-2026-65985 published to NVD
- 2026-08-19 - Last updated in NVD database
Technical Details for CVE-2026-65985
Vulnerability Analysis
The flaw is classified as Server-Side Request Forgery under [CWE-918]. FUXA exposes a Socket.IO event named device-webapi-request that accepts a device property object from connected clients. The handler reads property.address and uses it as the target URL for an outbound HTTP or HTTPS request made by the FUXA server process. The server then relays the response body back to the socket that issued the request.
Because the handler does not validate or restrict the target URL, an authenticated runtime user without administrative privileges can direct the server to fetch arbitrary internal or cloud-hosted resources. Impact depends on the FUXA host's network position. In cloud environments, an attacker can query the instance metadata service (IMDS) to retrieve temporary IAM credentials. In on-premises deployments, reachable internal HTTP services, admin consoles, and IPC endpoints become enumerable through the FUXA server.
Root Cause
The root cause is missing allowlist validation on user-controlled URL input in the Socket.IO device request path. The handler trusts property.address supplied by authenticated clients and forwards it directly to the HTTP client. There is no scheme restriction, host allowlist, private-IP filter, or role check gating the operation to admin users.
Attack Vector
Exploitation requires network access to the FUXA Socket.IO endpoint and a valid non-admin runtime account. The attacker connects, emits the device-webapi-request event, and sets property.address to a target such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS or http://127.0.0.1:<port> for loopback services. The FUXA server issues the request and returns the response body over the socket.
The upstream fix (release v1.3.3, pull request #2379) also hardens the JWT lifecycle and Socket.IO admin operations. The client-side portion of the patch updates token refresh handling in auth.service.ts:
return false;
}
- setNewToken(token: string) {
+ setNewToken(token: string, userData?: Partial<UserProfile>) {
if (!this.currentUser) {
return;
}
+ if (userData) {
+ this.currentUser.username = userData.username ?? this.currentUser.username;
+ this.currentUser.fullname = userData.fullname ?? this.currentUser.fullname;
+ this.currentUser.groups = userData.groups ?? this.currentUser.groups;
+ this.currentUser.info = userData.info ?? this.currentUser.info;
+ if (this.currentUser.info) {
+ this.currentUser.infoRoles = JSON.parse(this.currentUser.info)?.roles;
+ } else {
+ this.currentUser.infoRoles = null;
+ }
+ }
this.currentUser.token = token;
this.saveUserToken(this.currentUser);
+ this.currentUser$.next(this.currentUser);
}
Source: GitHub FUXA Commit 4fa47d0
Detection Methods for CVE-2026-65985
Indicators of Compromise
- Outbound HTTP/HTTPS connections from the FUXA server process to 169.254.169.254, 127.0.0.1, or RFC1918 addresses not associated with configured devices.
- Socket.IO events named device-webapi-request originating from non-admin user sessions.
- FUXA application logs showing WebAPI device reads targeting hosts that are not defined as SCADA devices in the project.
Detection Strategies
- Inspect egress traffic from FUXA hosts for requests to cloud metadata endpoints (169.254.169.254, metadata.google.internal, metadata.azure.com).
- Correlate Socket.IO handler invocations with the authenticated user role. Alert when non-admin users trigger device-webapi-request.
- Baseline the set of legitimate device URLs configured in FUXA and flag runtime requests to any URL outside that allowlist.
Monitoring Recommendations
- Enable verbose logging on the FUXA runtime and forward logs to a centralized analytics platform for retention and query.
- Monitor cloud IAM credential usage for anomalous source IPs, focusing on the roles attached to FUXA host instances.
- Track FUXA version inventory across environments and alert on any host still running 1.3.2 or earlier.
How to Mitigate CVE-2026-65985
Immediate Actions Required
- Upgrade all FUXA deployments to version 1.3.3 or later, published as FUXA Release v1.3.3.
- Audit runtime user accounts and remove any non-admin accounts that no longer require access.
- Rotate any cloud IAM credentials associated with FUXA host instance profiles if exposure is suspected.
Patch Information
The vulnerability is fixed in FUXA 1.3.3. The upstream fix is tracked in GitHub Pull Request #2379 and applied in commit 4fa47d0. Additional context is available in the GitHub Security Advisory GHSA-wrg6-49wh-46pw.
Workarounds
- Restrict network reachability of the FUXA server so it cannot reach cloud metadata services or sensitive internal endpoints.
- Enforce IMDSv2 with hop limit 1 on AWS EC2 instances hosting FUXA to blunt metadata exfiltration.
- Place FUXA behind an authenticating reverse proxy and limit Socket.IO access to trusted operators until the upgrade is applied.
# AWS IMDSv2 enforcement to blunt SSRF-based metadata theft
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required \
--http-put-response-hop-limit 1 \
--http-endpoint enabled
# Egress restriction example (iptables) - block link-local metadata IP
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

