Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When secureEnabled=true, FUXA 1.3.0-2773 still allows guest and invalid-token requests to read project, alarms, and scheduler APIs. Details In secure mode, requests with no token or an explicitly invalid token were still able to access protected read endpoints. Confirmed behavior: - guest GET /api/project returned 200 OK - invalid-token requests to /api/project also returned successful responses containing project data - guest and invalid-token requests also returned 200 OK on: - /api/alarms - /api/scheduler Relevant code paths identified during analysis: - server/api/jwt-helper.js - verifyToken() converts missing-token or invalid-token states into guest context instead of rejecting the request - server/api/projects/index.js - server/api/alarms/index.js - server/api/scheduler/index.js These handlers accepted the guest context and returned sensitive data in secure mode. PoC Tested only against isolated local lab instances under the original tester's control. No…
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GET /api/project endpoint exposes sensitive project configuration data to guest-context requests even when secureEnabled is enabled. Details File: server/api/projects/index.js The endpoint uses the secureFnc middleware, but this middleware calls verifyToken in server/api/jwt-helper.js which auto-generates a valid guest JWT when no token is provided (line 49-51): The guest token is signed with the server's secret and passes verification. The handler then calls getProject which returns the full project data. The filterProjectPermission function (line 924 of server/runtime/project/index.js) filters some UI elements for non-admin users, but it does not remove scripts, devices, alarms, or other sensitive configuration data. PoC Environment - FUXA v1.3.0-2773 (frangoteam/fuxa:latest) - secureEnabled: true with a random secretCode Retrieve full project data without authentication: No authentication token, API key, or cookie was provided. The response includes: - Server-side…
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: When a script has no…
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in the path sanitization logic allows an authenticated attacker with administrative privileges to bypass directory traversal protections. By using nested traversal sequences (e.g., ....//), an attacker can write arbitrary files to the server filesystem, including sensitive directories like runtime/scripts. This leads to Remote Code Execution (RCE) when the server reloads the malicious scripts. It is a new vulnerability a patch bypass for the sanitization in the last release . Details This report describes a new, distinct vulnerability that differs from previous Path Traversal advisories (such as CVE-2023-31718) in several ways: Patch Bypass (Regression): The vulnerability circumvents the existing sanitization logic implemented to fix previous traversal issues. The current "single-pass" regex approach is insufficient against nested sequences. Expansion of Scope: Unlike previous reports that focused primarily on /api/download, this bypass affects multiple critical…
Recommended action: Upgrade to 1.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authorization bypass vulnerability in the FUXA allows an unauthenticated, remote attacker to create and modify arbitrary schedulers, exposing connected ICS/SCADA environments to follow-on actions. This vulnerability affects FUXA version 1.2.8 through version 1.2.10. This has been patched in FUXA version 1.2.11. Impact This affects all deployments, including those with runtime.settings.secureEnabled set to true. Exploitation allows an unauthenticated, remote attacker to automatically authenticate as guest and create, modify or delete schedules. These schedules can be configured to trigger immediately or cyclically, forcing connected devices to specific states or values, or executing existing scripts on the server. Patches This issue has been patched in FUXA version 1.2.11. Users are strongly encouraged to update to the latest available release.
Recommended action: Upgrade to 1.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description An authentication bypass vulnerability in FUXA allows an unauthenticated, remote attacker to execute arbitrary code on the server when the Node-RED plugin is enabled. This affects FUXA version 1.2.8 through version 1.2.10. This has been patched in FUXA version 1.2.11. Impact This affects all deployments with the Node-RED plugin enabled, including those with runtime.settings.secureEnabled set to true. Exploitation allows an unauthenticated, remote attacker to send a specially crafted request to the /nodered/flows endpoint to bypass authentication checks, granting the attacker administrative access to the Node-RED deployment API. By submitting a malicious flow configuration, an attacker can execute arbitrary code in the context of the FUXA service. Depending on deployment configuration and permissions, this may lead to full system compromise and could further expose connected ICS/SCADA environments to follow-on actions. Patches This issue has been patched in FUXA…
Recommended action: Upgrade to 1.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description An authorization bypass vulnerability in FUXA allows an unauthenticated, remote attacker to modify device tags via WebSockets. This affects FUXA through version 1.2.9. This issue has been patched in FUXA version 1.2.10. Impact This affects all deployments, including those with runtime.settings.secureEnabled set to true. Exploitation allows an unauthenticated, remote attacker to bypass role-based access controls and overwrite arbitrary device tags or disable communication drivers, exposing connected ICS/SCADA environments to follow-on actions. This may allow an attacker to manipulate physical processes and disconnected devices from the HMI. Patches This issue has been patched in FUXA version 1.2.10. Users are strongly encouraged to update to the latest available release.
Recommended action: Upgrade to 1.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description A path traversal vulnerability in FUXA allows an unauthenticated, remote attacker to write arbitrary files to arbitrary locations on the server filesystem. This affects FUXA through version 1.2.9. This issue has been patched in FUXA version 1.2.10. Impact This affects all deployments, including those with runtime.settings.secureEnabled set to true. Exploitation allows an unauthenticated, remote attacker to overwrite application and system files. If the attacker can overwrite application code, startup scripts, or configuration files that are later executed/loaded, RCE is likely. Depending on deployment configuration and permissions, this may lead to full system compromise and could further expose connected ICS/SCADA environments to follow-on actions. Patches This issue has been patched in FUXA version 1.2.10. Users are strongly encouraged to update to the latest available release. Notes GitHub stated this vulnerability is identical to CVE-2025-69981, which was…
Recommended action: Upgrade to 1.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An insecure default configuration in FUXA allows an unauthenticated, remote attacker to gain administrative access and execute arbitrary code on the server. This affects FUXA through version 1.2.9 when authentication is enabled, but the administrator JWT secret is not configured. This issue has been patched in FUXA version 1.2.10. Impact The FUXA documentation allows administrators to manually update a hardcoded JWT secret when enabling authentication. This feature was not available in the UI. This results in a fail-open security posture, where the application can report or appear to be operating in secureEnabled mode while still accepting tokens signed with a publicly known key. Exploitation allows an unauthenticated, remote attacker to forge JWTs to bypass all authentication mechanisms and obtain administrative access to the FUXA instance. With these elevated privileges, the attacker can interact with administrative APIs, including intended features designed for…
Recommended action: Upgrade to 1.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An information disclosure vulnerability in FUXA allows an unauthenticated, remote attacker to retrieve sensitive administrative database credentials. This affects FUXA through version 1.2.9. This issue has been patched in FUXA version 1.2.10. Impact This affects all deployments, including those with runtime.settings.secureEnabled set to true. Exploitation allows an unauthenticated, remote attacker to obtain the full system configuration, including administrative credentials for the InfluxDB database. Possession of these credentials may allow an attacker to authenticate directly to the database service, enabling them to read, modify, or delete all historical process data, or perform a Denial of Service by corrupting the database. Patches This issue has been patched in FUXA version 1.2.10. Users are strongly encouraged to update to the latest available release.
Recommended action: Upgrade to 1.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Note GitHub incorrectly stated this vulnerability is identical to CVE-2025-69970, which describes the fact that authentication is disabled by default. This advisory describes an exploit chain that enables authentication bypass via the heartbeat refresh endpoint when authentication is enabled. This misleads users into thinking that enabling authentication would mitigate this vulnerability. Please see the patch for more information: https://github.com/frangoteam/FUXA/commit/fe82348d160904d0013b9a3e267d50158f5c7afb. Description An authentication bypass vulnerability in FUXA allows an unauthenticated, remote attacker to gain administrative access via the heartbeat refresh API and execute arbitrary code on the server. This affects FUXA through version 1.2.9 when authentication is enabled. This issue has been patched in FUXA version 1.2.10. Impact Affected deployments are those with runtime.settings.secureEnabled set to true. Exploitation allows an unauthenticated, remote attacker to…
Recommended action: Upgrade to 1.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.