Naxclow Platform EUVD-2026-36533

The attacker must reach the Naxclow cloud registration endpoint over a standard network connection and must be able to construct a structurally valid signed request containing both a batch prefix field and an arbitrary account identifier field. No authentication, existing account, or prior device ownership is required - the vulnerability exists precisely because the server performs no ownership validation between the caller and the account identifier supplied. The CVSS 4.0 vector confirms PR:N (no privileges required) and UI:N (no user interaction). Exploitation is constrained only by the attacker's ability to produce valid request signatures; if signing keys are embedded in the mobile application binary or device firmware (common in IoT ecosystems), this barrier is easily overcome through static analysis or instrumentation. No non-default configuration is required: the vulnerable endpoint is part of the standard device registration flow shared by all four affected products.

The CVSS 4.0 base score of 6.9 (Medium) is consistent with the attack profile: network-accessible, zero-privilege, low-complexity, with limited confidentiality impact and no integrity or availability consequences (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N). EPSS data was not provided in the available intelligence and cannot be inferred. The vulnerability is not listed in the CISA KEV catalog, and no public exploit code has been identified - these are meaningful mitigating signals. However, the ICS-CERT reporting context is a risk amplifier: Naxclow devices serve physical security roles in residential and potentially small-business environments, and a precise fleet enumeration capability provides low-cost reconnaissance for adversaries seeking to identify high-value targets, correlate device density with geographic or organizational profiles, or enumerate potential pivot points before a more destructive follow-on campaign. The primary technical constraint on exploitation is the requirement to produce structurally valid signed requests; given that signing material is typically embedded in mobile applications or firmware, this barrier is likely low for a motivated attacker.

An unauthenticated external attacker extracts the request signing material from the Naxclow mobile application or firmware and crafts a series of valid signed API requests to the cloud registration endpoint, supplying an arbitrary account identifier and iterating across batch prefixes. Each call returns a new sequential device ID and the current batch high-water counter, allowing the attacker to calculate registered device counts per batch with arithmetic precision. After automated iteration across all batch prefixes, the attacker produces a near-complete map of the active Naxclow fleet, which can be used to identify specific device owners, profile deployment density by region, or select high-value targets for follow-on physical or network attacks.