The CVSS 5.5 rating almost certainly understates the operational risk in this ICS/SCADA context because this isn't simply a missing authentication check — it's a configuration toggle that promises security but delivers none, creating a dangerous false sense of protection for operators of critical systems.
FUXA's secureEnabled flag is documented as the mechanism for controlling access to sensitive operational data. The vulnerability reveals this control is functionally broken across a specific version range — when operators set secureEnabled=true, the software still permits unauthenticated enumeration of project configurations, alarm states, and scheduler logic. This is architecturally distinct from a typical 'missing authentication' finding because it represents a trust violation: the security control claims to do something and demonstrably does not.
In a SCADA/HMI context, these APIs expose topology details, process parameters, and control sequencing logic — exactly the operational intelligence an adversary needs for targeted intrusion or sabotage. The medium CVSS reflects a data confidentiality issue in a general web context, but ICS deployments carry elevated consequence if this data is exposed, even if the technical vector is 'just reading APIs.' The exposed data isn't abstract — project configurations likely contain device mappings, tag names, and control sequences that tell an attacker exactly which actuator to target and when. An operator who enabled secureEnabled believing they'd hardened their topology will integrate FUXA more deeply into their control network rather than isolating it, making this enumeration a potential beachhead for lateral movement into control plane infrastructure.
The 1.3.1 patch speed raises a subsidiary question: was this a regression introduced during development, or a long-standing flaw only now discovered? If it's a regression, it means someone touched the auth flow and accidentally exposed what was previously protected — a CI/CD gap that allowed a broken security check to ship. If it's long-standing, it suggests the auth layer was never systematically audited despite being the primary access control mechanism. Either answer affects how you assess exposure duration and whether other FUXA security claims warrant scrutiny.
The specific enumeration of 'project, alarms, and scheduler' as affected endpoints likely indicates an initial probe rather than a complete scope — a competent attacker enumerating the API surface won't stop at those three endpoints, and the patch itself may have blind spots in adjacent code paths. Understand which data flows remain protected before trusting this fix in a production control environment.