Skip to main content

CVE-2026-43946

HIGH
Incorrect Authorization (CWE-863)
2026-05-26 https://github.com/frangoteam/FUXA GHSA-fwcm-rqvw-j3p7
Share

Lifecycle Timeline

2
Source Code Evidence Fetched
May 27, 2026 - 00:02 vuln.today
Analysis Generated
May 27, 2026 - 00:02 vuln.today

DescriptionCVE.org

Summary

An authorization bypass in the /api/getTagValue endpoint allows unauthenticated access to tag values when the referenced script does not exist.

Details

The issue is caused by the combination of these code paths:

  • server/api/apikeys/verify-api-or-token.js:45 sends requests without x-api-key to authJwt.verifyToken(req, res, next).
  • server/api/jwt-helper.js:46-64 creates a signed guest token when no x-access-token is provided:

if (!token) { token = getGuestToken(); } and then populates req.userId / req.userGroups from that guest token.

  • server/api/command/index.js:76-105 exposes /api/getTagValue.
  • server/runtime/scripts/index.js:106-111 returns true when the referenced script does not exist:

if (!script) { return true; }

As a result, an unauthenticated request reaches /api/getTagValue as guest, and the authorization check is bypassed because isAuthorisedByScriptName() returns true when sourceScriptName is omitted or does not match a real script. The endpoint then returns arbitrary tag values by ID.

PoC

Requests to /api/getTagValue without authentication could succeed when the authorization logic evaluated a non-existent sourceScriptName as authorized.

AnalysisAI

Here is the multi-source synthesis for CVE-2026-43946:

json
{
  "product_name": "FUXA",
  "summary": "Unauthenticated disclosure of arbitrary industrial tag values in FUXA 1.3.0 lets remote actors read live process data through the /api/getTagValue endpoint. Per the vendor advisory (GHSA-fwcm-rqvw-j3p7), the API mints a signed 'guest' identity when no API key or access token is supplied, and the per-script authorization check fails open when the referenced sourceScriptName points to a non-existent script, so the guest request is treated as authorized. No CISA KEV listing and no weaponized public exploit code were identified, though the advisory documents the exact vulnerable code paths; the flaw is fixed in v1.3.1.",
  "technical_context": "FUXA is an open-source, web-based SCADA/HMI and IoT gateway platform whose server component ships as the npm package fuxa-server. The disclosure is a chain of three server-side code paths: server/api/apikeys/verify-api-or-token.js routes any request lacking an x-api-key header into JWT verification; server/api/jwt-helper.js then creates and signs a guest token when no x-access-token is present (`if (!token) { token = getGuestToken(); }`), populating req.userId and req.userGroups with that guest principal; and server/runtime/scripts/index.js (isAuthorisedByScriptName) returned `true` when the referenced script could not be found. The endpoint server/api/command/index.js:76-105 (/api/getTagValue) relies on that script-name authorization, so an omitted or bogus sourceScriptName resolves to 'authorized.' This is a textbook CWE-863 (Incorrect Authorization) fail-open: the authorization decision defaults to allow on a missing object rather than deny. The fix flips the default to `return false`, tightens the Node-RED public-route check to `req.baseUrl === '/dashboard'`, and corrects the unauthorized response from HTTP 400 to 401.",
  "risk_assessment": "No CVSS vector or EPSS score was provided, so severity cannot be independently quantified from the input — this is a notable data gap. The vulnerability is not listed in CISA KEV, and no weaponized exploit code was identified, though the GitHub advisory provides advisory-grade methodology (exact code paths and the triggering request), lowering the effort to reproduce. Weighing the signals: technical impact is a confidentiality breach (read access to arbitrary tag values by ID), with no indication of write/RCE; attack complexity is low because exploitation requires only a single crafted unauthenticated request to a known endpoint. The mitigating reality is exposure scope — FUXA is an OT/SCADA dashboard frequently deployed on segmented or air-gapped industrial networks, so widespread internet-facing exploitation is less likely than targeted access to reachable instances. Net: a real and easily-actioned priority for any FUXA 1.3.0 instance reachable from an untrusted network, but lower urgency where the server is network-isolated. Because no CVSS vector is available, severity ranking should be treated as inferred from the advisory rather than confirmed.",
  "affected_products": "The affected component is the FUXA server distributed as the npm package fuxa-server (CPE pkg:npm/fuxa-server), from the frangoteam/FUXA project. The vendor advisory GHSA-fwcm-rqvw-j3p7 lists version 1.3.0 as vulnerable and 1.3.1 as the fixed release; whether versions prior to 1.3.0 are also affected is not stated in the available data. The vendor advisory is at https://github.com/frangoteam/FUXA/security/advisories/GHSA-fwcm-rqvw-j3p7 and the GitHub advisory mirror at https://github.com/advisories/GHSA-fwcm-rqvw-j3p7.",
  "remediation": "Vendor-released patch: 1.3.1 — upgrade fuxa-server to v1.3.1 (release tag https://github.com/frangoteam/FUXA/releases/tag/v1.3.1), which corresponds to PR https://github.com/frangoteam/FUXA/pull/2260 and commit https://github.com/frangoteam/FUXA/commit/78534da61a91613712b44bb63c8d7da8c5df5ca4. If immediate upgrade is not possible, place the FUXA server behind a reverse proxy or network ACL that restricts the /api/ surface (including /api/getTagValue) to trusted, authenticated management hosts, since the abused path is the unauthenticated guest-token fallback; note the trade-off that FUXA's public dashboard routes legitimately rely on guest access, so broad blocking of guest traffic can break unauthenticated dashboard viewing. As a network-level compensating control, ensure the FUXA server is not exposed to untrusted networks or the internet and is reachable only from the OT management segment. Full details are in the vendor advisory at https://github.com/frangoteam/FUXA/security/advisories/GHSA-fwcm-rqvw-j3p7.",
  "exploit_scenario": "An attacker with network reachability to a FUXA 1.3.0 server sends a request to /api/getTagValue with no x-api-key and no x-access-token and either omits the sourceScriptName or supplies one that does not match a real script. The server issues a guest token, the script-name authorization check returns true for the non-existent script, and the endpoint returns tag values by ID — exposing live industrial sensor readings, setpoints, and equipment state. The advisory documents the exact request behavior, so reproduction effort is low.",
  "exploitation_conditions": "Exploitation requires network access to the FUXA server's HTTP API and a request to /api/getTagValue that (1) omits the x-api-key header and (2) omits the x-access-token, so the server falls back to the signed guest token, and (3) either omits sourceScriptName or supplies a name that does not resolve to an existing script, which causes isAuthorisedByScriptName() to fail open. Affected build is FUXA 1.3.0. Limiting factors that reduce realistic risk: the FUXA server must be network-reachable from the attacker (many SCADA/HMI deployments sit on isolated OT networks), and to read a specific value the attacker must know or enumerate valid tag IDs. The vendor advisory explicitly characterizes the access as unauthenticated; note that no CVSS vector is available in the input to independently corroborate privilege requirements.",
  "attack_chain": "Reach FUXA API over network → Omit API key and access token → Server issues signed guest token → Reference non-existent script to bypass authz → Read arbitrary tag values by ID",
  "confidence_notes": "Confirmed by the vendor GitHub Security Advisory GHSA-fwcm-rqvw-j3p7, PR #2260, and the linked commit: the vulnerable code paths, the vulnerable version (1.3.0), the fixed version (1.3.1), and the unauthenticated/guest-token nature of the bypass. Inferred (not vendor-quantified): overall severity and exploitability ranking, because no CVSS vector and no EPSS score were provided. Unknown/missing: whether versions before 1.3.0 are affected, EPSS probability, and any active exploitation — the CVE is not in CISA KEV and no weaponized public exploit code was identified, though the advisory itself documents the exact triggering request."
}

A few synthesis notes worth flagging explicitly, since they affect how you should weight this analysis:

  • Auth qualifier basis: I used "unauthenticated" because the vendor advisory's title and description explicitly state it — not because of a CVSS vector, which was N/A. I called this out in confidence_notes so the claim is traceable to vendor confirmation rather than inferred from loose description text.
  • POC vs. active exploitation: The advisory's "PoC" section is a prose description of the triggering request, not weaponized exploit code, and there's no KEV listing — so I stated "no weaponized public exploit code identified" while crediting the advisory's detailed methodology. These are kept as distinct signals.
  • Missing data stated explicitly: No CVSS vector and no EPSS, so I marked severity ranking as inferred, not confirmed.

Share

CVE-2026-43946 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy