Kasm Workspaces Exposure Is a Session-Delivery Problem
Kasm Workspaces brokers browser sessions for applications and desktops. The login page can sit in front of user sessions, administrative APIs, and session-casting URLs. The security boundary continues after the initial password check. A valid session may become a launch point into a user workspace, while a developer API key may expose session creation, user management, and deployment controls.
A count-only ZoomEye search on 2026-10-30 returned zero matches for app="Kasm Workspaces" and 40 for title="Kasm Workspaces" between 06:41 and 06:42 China Standard Time. The small title result is a useful candidate list, but it does not prove that any instance is unprotected. The product-specific app fingerprint did not match this dataset.
Session creation is privileged
Kasm's Developer API documentation says API keys and secrets are sent with requests and that API keys have no permissions by default. That least-privilege default is useful. The deployment still needs a review of scopes, because a key created for session reporting may not need authority to create a session for an arbitrary user. The documentation describes a session request that can launch for an existing user or create an anonymous user under a specific scope. Treat that scope as a capability to start work in the environment.
Protect API keys as credentials, not as application configuration that can be shared among teams. Store them in a secret manager, rotate them when an integration is retired, and restrict the source network. Do not place a key in a browser bundle or a public repository. Audit key creation and deletion separately from user login.
Administrative endpoints for users, groups, settings, and infrastructure can be more powerful than the session portal. Put the admin interface on a separate management network or identity-aware proxy. A normal user should not be able to reach the API documentation or admin path merely because the public portal shares the same hostname. Verify the route policy for the root page and every other operation.
Identity provider access needs group mapping
Kasm's OIDC documentation warns that any user who authenticates with the provider gains access to the deployment, even if group permissions later restrict access to specific workspace apps and desktops. That distinction is important. A broad corporate identity provider may authenticate thousands of users; Kasm still needs an allowlist, group mapping, or a provider-side application assignment.
Map groups to roles and sessions explicitly. Test a user who belongs to the provider but not to the Kasm access group. The user may be able to sign in but should not see or start a restricted session. Check the behavior after group removal and after the identity provider session is revoked. A local password or fallback account can bypass the external identity path if it is still enabled.
Session casting and download URLs deserve a separate review. If a link carries a token or grants temporary access, set an expiry, bind it to the intended session, and avoid placing it in logs or chat. Revoke or invalidate the link when the session ends.
Validate the actual delivery path
For each owned title match, confirm the login page, certificate, DNS owner, and network path without starting a session. From outside, verify the expected block. From a management workstation, use test accounts to compare the portal, admin API, and a session-casting URL. Confirm the API key scope by attempting an operation outside its intended role.
Review the worker and agent token configuration. Kasm server settings include a token used between agents and the Manager API. A leaked token can affect infrastructure communication even when user sessions are protected. Keep that token out of container images and support bundles, and rotate it through the documented deployment process.
The 40 title matches are a reminder that a low count is still worth an ownership check. Kasm compresses identity, session delivery, and administration into one product. The access review should follow the same path a session takes, from login to launch to termination.
Query and scope
The standalone SDK used sub_type=all, page 1, page size 1, and returned totals only. app="Kasm Workspaces" returned zero and title="Kasm Workspaces" returned 40. Collection ran from 2026-10-29 22:41:37 to 22:41:40 UTC.
Top comments (0)