Scotty security advisories · Updated 11 November 2026

Three access control flaws, fixed in Scotty 0.4.0 and 0.5.0.

An internal security review found three ways to do more than a role allows. Users with create rights could overwrite apps in other scopes (fixed in 0.5.0). Read-only users could download files from containers, and task details leaked across scopes and to unauthenticated clients (both fixed in 0.4.0). Upgrade to 0.5.0.

3published advisories
8.7highest CVSS 4.0 score
0.4.0last affected version
0.5.0fixes all three
Advisories

What was affected

All three advisories are published on GitHub with full details. None has a CVE ID yet.

app:create could overwrite an existing app, across scopes

high · CVSS 8.7CWE-639CWE-285GHSA-x7p6-8ffj-5xgc

Creating an app never checked whether an app with that name already existed. The permission check only looked at the scopes in the request, so a user with create in any scope could replace an app in a scope they had no access to. Affects 0.4.0 and earlier.

scottyctl app:create shop --folder ./evil --service web:80 --scope staging
# shop lived in production; it now runs the caller's compose file in staging
  • Impact: the attacker's containers get the replaced app's named volumes and public domain, and the app moves into the attacker's scope with view, manage, shell and destroy rights.
  • Fix (0.5.0): app:create is create-or-update. Re-creating an app can't change its scopes, and the user needs create rights in every one of the existing app's scopes (403 otherwise).
  • Workaround before upgrading: give create only to users you trust with every app on the server, or block POST /api/v1/authenticated/apps/create at your reverse proxy.

Read GHSA-x7p6-8ffj-5xgc on GitHub

Read-only users could download any file from app containers

high · CVSS 7.1CWE-285GHSA-x4gp-9359-wj3r

Affects 0.3.4 and earlier. The endpoint behind scottyctl app:cp streams any path inside a container as a tar archive. It only required the view permission, which is meant as read-only access to app metadata.

GET /api/v1/apps/{app_id}/services/{service}/files?path=<container-path>
  • Impact: a user with only the viewer role in a scope could read any file from every running container of the apps in that scope: .env files, credentials, private keys, database files and uploaded user data.
  • Fix (#934): downloading files from a container now requires the shell permission, the same as opening a shell.
  • Workaround before upgrading: remove view from users who must not read container files, or block the files endpoint at your reverse proxy.

Read GHSA-x4gp-9359-wj3r on GitHub

Task details visible across scopes and to unauthenticated WebSocket clients

medium · CVSS 6.9CWE-200CWE-639GHSA-fjmq-qjgv-5jp3

Affects 0.3.4 and earlier. Every task state change went to every WebSocket client as a TaskInfoUpdated message, including connections that never authenticated. The REST task endpoints returned all tasks of all apps to any authenticated user.

  • Impact: anyone who could reach /ws learned app names, the commands being run, task state, timestamps and exit codes across all scopes. Task output was not included.
  • Fix (#936): a task is visible only to users with view on its app, to admin_read for tasks without an app, and to the user who started it. A hidden task answers like a missing one (404).
  • Workaround before upgrading: none besides restricting network access to the Scotty server to trusted users.

Read GHSA-fjmq-qjgv-5jp3 on GitHub

Also in 0.4.0

Further hardening

The same review tightened more permission checks. These shipped in 0.4.0 together with the two fixes above, and 0.4.0 adds an authorization test matrix for REST and WebSocket operations.

WebSocket

Authenticated sessions only

Session messages require authentication and ownership. Parse errors go only to the client that sent them.

Shell

Shell permission for WebSocket shells

Opening a shell session over the WebSocket requires the shell permission.

Notifications

Manage permission to change notifications

Changing an app's notification settings requires manage.

Custom actions

Permission check before lookup

Scotty checks the action permission before it looks up a custom action, so users without it learn nothing about which actions exist.

What to do

Upgrade and review roles

Run Scotty 0.5.0. It has breaking changes of its own, so read its release notes before you upgrade.

Upgrade

  • Move every Scotty server to 0.5.0.
  • Update scottyctl on the machines and CI jobs that use it.

Check roles

  • Users who copied files with app:cp using only view now need a role with shell.
  • Give shell only to people who should read container files.
  • Check which apps users with create could have replaced in other scopes before the upgrade.

Report a finding

  • Report vulnerabilities privately through GitHub's security advisory form, not as a public issue.
  • See SECURITY.md in the repository for the policy.

factorial-io/scotty on GitHub

See all security advisories