Speckle Server provides server, frontend, 3D viewer, and other JavaScript utilities for the Speckle 3D data platform. A vulnerability in versions prior to 2.17.6 affects users who: authorized an application which requested a token write scope or, using frontend-2, created a Personal Access Token (PAT) with token write scope. When creating a new token an agent needs to authorise the request with an existing token (the requesting token). The requesting token is required to have token write scope in order to generate new tokens. However, Speckle server was not verifying that other privileges granted to the new token were not in excess of the privileges of the requesting token. A malicious actor could use a token with only token write scope to subsequently generate further tokens with additional privileges. These privileges would only grant privileges up to the existing privileges of the user. This vulnerability cannot be used to escalate a users privileges or grant privileges on behalf of other users.
This has been patched as of version 2.17.6. All operators of Speckle servers should upgrade their server to version 2.17.6 or higher. Any users who authorized an application with token write scope, or created a token in frontend-2 with token write scope should review existing tokens and permanently revoke any they do not recognize, revoke existing tokens and create new tokens, and review usage of their account for suspicious activity. No known workarounds for this issue exist.
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Speckle_server | Specklesystems | * | 2.17.6 (excluding) |
Integrated circuits and hardware engines can expose accesses to assets (device configuration, keys, etc.) to trusted firmware or a software module (commonly set by BIOS/bootloader). This access is typically access-controlled. Upon a power reset, the hardware or system usually starts with default values in registers, and the trusted firmware (Boot firmware) configures the necessary access-control protection. A common weakness that can exist in such protection schemes is that access controls or policies are not granular enough. This condition allows agents beyond trusted agents to access assets and could lead to a loss of functionality or the ability to set up the device securely. This further results in security risks from leaked, sensitive, key material to modification of device configuration.