@orbisai0security thanks for the submission. Before merging, I'd like to clarify the threat model, because the current description doesn't match what I see in the code.

On "any unauthenticated user": the pre-PR endpoint already required a valid JWT or API key via Depends(get_current_subject) (studio/backend/main.py:206). Unauthenticated requests are rejected by HTTPBearer before the handler runs. Could you point to the path you believe bypasses authentication entirely?

On "CRITICAL": in Studio's current design, auth_user only ever contains the default admin unsloth — ensure_default_admin() is the only user-creation path and there is no public registration endpoint. For a non-admin subject to reach the handler at all, an attacker would need one of:

1. Write access to auth.db (host compromise),
2. Code execution in the backend process (host compromise), or
3. A leaked admin credential — in which case the PR's check passes for them anyway.

In every case the attacker is already inside the trust boundary, which is not a critical remote DoS.

Ask: please share a working PoC that demonstrates a remote, non-admin caller reaching {"status":"shutting_down"} on an unmodified main. Not a scanner report, not a description — an actual runnable script or curl sequence we can execute against a stock unsloth studio run instance and observe the server exit.

If you can't, there is no actual need to merge this PR.

Fair point, you're correct. I looked at the code more carefully, and the endpoint was already gated behind Depends(get_current_subject) + HTTPBearer before this PR, and there's only ever one user in auth.db anyway.

I can't produce a PoC because the scenario I described doesn't actually exist. The scanner flagged it, I didn't verify the full auth chain before opening the PR, and the "CRITICAL" label was wrong. Happy to close this, or reframe it as defence-in-depth for if multi-user support ever lands, your call.

@orbisai0security thank you for confirming! and thank you for the effort. Closing this after confirmation.

What This PR Changes

This PR adds an extra permission check to the "shutdown server" button in the app's UI. Specifically, it now verifies that the person clicking shutdown is the admin account before allowing the server to stop. If anyone else tries to trigger it, they get a "403 Forbidden" error.

What the Code Actually Does

Before: Any logged-in user could hit the shutdown endpoint and stop the entire server.

After: Only the admin account can shut down the server. Other logged-in users are blocked with a clear error message.

Important Context From the Discussion

The PR's original description overstated the severity. As the repo owner (@rolandtannous) pointed out:

• The endpoint was never open to unauthenticated users — it already required a valid login token before this PR
• The submitter (@orbisai0security) acknowledged this and confirmed they couldn't produce a real exploit

So the actual fix is more modest: it upgrades the check from "any logged-in user" to "only the admin user" — which is a reasonable improvement, but not the critical vulnerability it was described as.

Minor Code Note

A separate reviewer noted that the new code could be written slightly more cleanly by using the already-imported storage module reference, rather than adding a redundant local import — but this is a minor style point, not a functional issue.