The token didn't matter. The origin assumption did.

The token was the part that looked like the secret. It was not.

FortiOS’s REST API tier authenticated CLI requests by inferring that the caller was already privileged when the request appeared to come from localhost. The Node.js WebSocket module at /ws/cli/ sat in front of that REST tier and accepted any value as local_access_token because the validating tier downstream was not the layer that checked the token — it was the layer that checked the apparent origin. The WebSocket front-end’s job was to proxy external requests into the management plane. The proxying step was the step that translated an external caller into a request the REST tier read as localhost. The attacker did not need to guess a secret; the attacker needed to send the request through the front door the architecture had built to make remote management work.

This is not a string-comparison bug. It is a category of design assumption that recurs in network-edge equipment: the runtime cannot verify the property the authentication design treats as load-bearing. SAP NetWeaver’s CVE-2025-31324 carried the same shape on the Visual Composer servlet — the deployment endpoint trusted that requests were coming from authenticated developers because the developer tier was behind the portal, and the portal was the boundary the runtime believed it was inside. SharePoint’s CVE-2025-49706 carried the same shape on the ToolPane endpoint — the auth check trusted a Referer header the protocol layer cannot itself verify. CVSS scores each of these in isolation against confidentiality, integrity, and availability impact. None of those columns names the property the runtime cannot enforce. On a perimeter SSL-VPN concentrator, that property is the entire security model.

The Arctic Wolf campaign analysis traced the operational shape of the bypass post-foothold: scan, login as super-admin via the WebSocket bypass, create local accounts and SSL-VPN portal users, harvest credentials, then pivot. Forescout tied the same chain to Mora_001 and the SuperBlack ransomware build. Console Chaos and SuperBlack are the exploitation labels; the underlying pattern is that on a FortiGate the management plane was reachable from the same network the SSL-VPN terminated on, and the front-end translating external requests into internal ones did not preserve the distinction the authentication layer relied on.

The narrow remediation is the one Fortinet’s advisory describes: upgrade to 7.0.17, 7.2.11, 7.4.7, or 7.6.2, then hunt for the documented IOCs (new local admin accounts, SSL-VPN portal-user changes that do not reconcile against change tickets, the symlink persistence mechanism Fortinet later addressed under CVE-2024-21762’s post- exploitation advisory). The single upgrade on the 7.0.x branch closes this CVE, CVE-2025-24472, and the symlink backdoor in one step — which is the rare case where applying the patch is also the cleanup, and only because researcher pressure forced disclosure of the persistence mechanism alongside the bug. The companion field note covers the five-CVE-in-twenty-eight-months pattern in full, including the silent-patching disclosure failures and the persistence problem that survives the upgrade itself.

The wider lesson is that the perimeter appliance class shares the trust-origin assumption FortiOS made here. Ivanti Connect Secure’s CVE-2024-21887 chained an auth-bypass with a command-injection on the same logic. PAN-OS’s CVE-2024-3400 reached a CVSS 10.0 because the GlobalProtect portal trusted a session-cookie path the portal itself controlled. Cisco ASA’s recurring web-VPN CVEs sit on the same family. The score column rates the bug; it does not rate the trust assumption the bug invalidates. Until the advisory ecosystem starts naming the assumption alongside the CVSS vector, the next perimeter bug will read the same way as this one.