CVE-2026-25894: 
JavaScript vulnerability analysis and mitigation

CVE-2026-25894 is an unauthenticated remote code execution vulnerability in FUXA, a web-based SCADA/HMI/Dashboard Process Visualization software, caused by an insecure default JWT configuration. When authentication is enabled but the administrator JWT secret is not explicitly configured, FUXA falls back to a publicly known hardcoded key, allowing any unauthenticated remote attacker to forge administrative tokens and execute arbitrary code on the server. The vulnerability affects FUXA through version 1.2.9 and was disclosed on February 9, 2026, with a patch released in version 1.2.10. It carries a CVSS v3.1 base score of 9.8 (Critical) and a CVSS v4.0 base score of 9.5 (Critical) (GitHub Advisory GHSA-32cc-x95p-fxcg, Red Hat CVE).

The root cause is classified under CWE-321 (Use of Hard-coded Cryptographic Key) and CWE-1188 (Insecure Default Initialization of Resource). FUXA's documentation allowed administrators to manually set a JWT secret when enabling authentication, but this option was not exposed in the UI prior to version 1.2.10, meaning deployments with authentication enabled would silently use a publicly known default key. An attacker can exploit this by crafting a JWT signed with the known default secret, presenting it to the FUXA API to obtain administrative access without any credentials. With administrative access, the attacker can interact with privileged APIs — including automation and scripting features — to execute arbitrary code in the context of the FUXA service process (GitHub Advisory GHSA-32cc-x95p-fxcg, Patch Commit).

Successful exploitation grants an unauthenticated remote attacker full administrative control over the FUXA instance, resulting in complete compromise of confidentiality, integrity, and availability. Beyond the FUXA server itself, attackers can interact with connected ICS/SCADA environments, potentially enabling unauthorized control of industrial processes, data exfiltration, and disruption of operational technology (OT) systems. Depending on deployment permissions, this may escalate to full host system compromise and lateral movement into adjacent industrial networks (GitHub Advisory GHSA-32cc-x95p-fxcg).

As of the time of disclosure, there is no public proof-of-concept exploit and no confirmed evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.0022 (0.22%), indicating a currently low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. However, the attack requires no authentication, no user interaction, and is remotely exploitable over the network, making it highly automatable if a public exploit were to emerge.

1. Reconnaissance: Identify internet-facing or network-accessible FUXA instances (versions ≤ 1.2.9) using tools like Shodan or Censys, searching for the FUXA web interface (default port 1881).
2. Confirm vulnerable configuration: Verify that authentication (secureEnabled) is active on the target instance by attempting to access protected API endpoints and observing JWT-based authentication challenges.
3. Forge administrative JWT: Using the publicly known default JWT secret (used when no secretCode is configured), craft a JWT token with administrative role claims using a tool such as jwt_tool or a custom script:

   jwt_tool -p <known_default_secret> -I -pc role -pv admin

4. Authenticate as administrator: Include the forged JWT in the Authorization: Bearer <token> header of API requests to the FUXA server, bypassing all authentication controls.
5. Execute arbitrary code: Leverage FUXA's administrative APIs — including automation, scripting, or project management endpoints — to execute arbitrary commands in the context of the FUXA service account, enabling reverse shell establishment, data exfiltration, or further lateral movement into connected ICS/SCADA systems (GitHub Advisory GHSA-32cc-x95p-fxcg, Patch Commit).

• Network: Unexpected or anomalous HTTP requests to FUXA API endpoints (default port 1881) from external or unauthorized IP addresses; outbound connections from the FUXA server to unknown external hosts (potential reverse shell or C2 activity).
• Logs: FUXA access logs showing API calls with JWT tokens that were not issued by the legitimate authentication flow; repeated administrative API access without corresponding login events; requests to scripting or automation endpoints from unauthenticated or unexpected sources.
• File System: New or modified files in the FUXA installation directory, particularly application code, startup scripts, or configuration files; unexpected scripts or executables written to the server filesystem.
• Process: Unusual child processes spawned by the FUXA Node.js process (e.g., bash, sh, cmd.exe, curl, wget, python); unexpected network listeners or new scheduled tasks/cron jobs created under the FUXA service account.

The primary remediation is to upgrade FUXA to version 1.2.10 or later, which adds a UI-configurable JWT secret field and enforces that a secret code must be set before authentication can be enabled (FUXA Release v1.2.10, Patch Commit). For deployments that cannot immediately upgrade, implement network segmentation to restrict access to the FUXA service (port 1881) to only authorized internal hosts, and consider disabling authentication temporarily until the secret can be properly configured. After upgrading, ensure the administrator JWT secret (secretCode) is explicitly set to a strong, unique value via the application settings UI.

The vulnerability was reported by researcher "wodzen" and disclosed through coordinated disclosure with the FUXA maintainers (GitHub Advisory GHSA-32cc-x95p-fxcg). The advisory notes that GitHub independently assigned CVE-2025-69971 to the same issue out of band before coordinated disclosure concluded, but the FUXA team clarified that CVE-2026-25894 and GHSA-32cc-x95p-fxcg contain the accurate description and affected version range. Security community discussion was observed on Mastodon (infosec.exchange) and a technical write-up was published at infinitsec.net shortly after disclosure. Red Hat also tracked the vulnerability in their security advisory database.