This CVE gives you remote, unauthenticated account creation on a file sync server. That's the headline. The technical chain: base64-encoded XML hits an unauthenticated CentreStack endpoint, gets deserialized, and flows directly to InternalImportAdUserByUPN() in GSNamespace.dll, which invokes the Windows NetUserAdd API. No authorization gate exists anywhere in that call chain. No input validation on the deserialized payload. Nothing between 'attacker-controlled string' and 'create a Windows user with whatever privileges you want.'
The CVSS 7.5 is misleading. Score the vulnerability in isolation and you get a number. Score it against what this product actually is — an internet-facing file sync appliance, typically domain-joined, sitting at the intersection of storage and identity — and you have something closer to a 9.0. An anonymous internet attacker gains the ability to create OS-level accounts on infrastructure that holds corporate data and often participates in Active Directory. That's not a lateral movement opportunity; that's a direct jump to privileged access on a hub asset.
Two things to check right now. First: verify your CentreStack version. This affects versions before 17.3. If you're on an older build, assume compromise — audit existing accounts and look for unfamiliar local users or domain accounts created around the time this server was exposed. Second: treat any base64-encoded parameter flowing to deserialization logic as a red flag. The encoding is irrelevant to the security boundary; it's a transport format. The real question is whether attacker-controllable data reaches privileged APIs without an explicit authorization check upstream. Given this product's architecture, assume all 'internal' APIs are reachable from untrusted networks until proven otherwise — file sync products live on network perimeters by design.