Cube Studio CVE-2026-111671

Requires a valid authenticated account on a Cube-studio instance (PR:L) - any registered low-privileged user suffices; no admin role, user interaction, or non-default configuration is needed. The platform must expose the notebook and serving lifecycle endpoints (stop/reset/clear/redeploy in view_notebook.py, view_inferenceserving.py, view_serving.py) and host resources belonging to multiple users, since the impact is cross-tenant. The only real limiting factors are the need for authentication and the presence of other users' notebooks/inference services to target; sequential/guessable object ids make enumeration trivial once logged in.

This is a genuine but bounded authorization (IDOR) risk rather than a top-tier emergency. The CVSS 4.0 base score of 7.1 (High) is driven almost entirely by availability: the vector VC:N/VI:L/VA:H plus CWE-639 shows the real impact is a low-privileged tenant being able to stop, reset, clear or redeploy OTHER tenants' notebooks and production inference services by manipulating object ids. AV:N/AC:L/UI:N make the mechanics trivial once you can reach the endpoints, but PR:L is the key dampener - exploitation requires a valid authenticated account on the Cube-studio platform, so this is an insider / compromised-credential / multi-tenant abuse scenario, not an internet-wide unauthenticated takeover. No EPSS score and no CISA KEV entry are present in the provided data, and there is no flag indicating weaponized exploit code; however, a detailed public technical writeup (hackmd) and VulnCheck advisory with exact vulnerable source line ranges substantially lower the research barrier for an attacker. There is no signal conflict between the CVSS vector and the description - both agree on network-reachable, authenticated, availability-centric impact. Net: prioritize for any multi-tenant Cube-studio deployment where untrusted or numerous users share the platform (account abuse → cross-tenant production outage), but it is not a drop-everything remote-root issue.

A low-privileged but authenticated user (or an attacker who has phished/compromised any single account) on a shared Cube-studio instance iterates sequential numeric ids against the notebook and serving lifecycle endpoints. By calling stop/reset/clear/redeploy on ids they do not own, they delete the underlying Kubernetes pods of other tenants and knock production inference endpoints offline. A public technical writeup documenting the exact endpoints and parameters exists, so no novel research is required to reproduce it.