GHSA-r2pq-mqwg-m575: 
Python vulnerability analysis and mitigation

Problem (H-1 — the entire /api/secrets API is unauthenticated by default)

auth.enabled=false ships as the default (settings.toml:164). require_auth (server/auth/dependencies.py:255) only raises when auth is enabled, so with the default it returns None and every route passes through. The secrets router (server/main.py:1725) relies solely on require_auth, so list / create / update / delete / resolve are all open. CORS is simultaneously set to allow_origins=["*"] with credentials, and some launch helpers (app_manager.start_demo / start_registry) bind 0.0.0.0. The per-secret ownership check also collapses because every anonymous caller is treated as user "local".

Attack

POST /api/secrets  {"id":"openai-api-key","value":"attacker-key"}   # hijack the LLM key
GET  /api/secrets                                                   # enumerate every secret id
DELETE /api/secrets/openai-api-key                                  # DoS

Problem (M-1 — no role gate on the secrets router)

Even with auth and authorization enabled, the router (server/secrets_routes.py:14) uses require_auth, never require_manage_access. A chat-only ServiceUser can list, resolve, create, and (for un-owned / env-backed secrets) overwrite keys. The intended manage-role gate exists and is applied to the sibling manage router — it is simply not wired here.

Impact

On the shipped defaults (auth.enabled=false), any network caller can read, overwrite, or delete every stored secret, including the LLM provider key, with zero authentication. Even with auth turned on, any authenticated (non-privileged) user can do the same because the manage-role gate is missing.

Locations

• server/auth/dependencies.py:255
• settings.toml:164
• server/main.py:1725
• server/secrets_routes.py:14

Proposed fix

• Fail closed on secret routes regardless of the global auth flag.
• Change the secrets router dependency from require_auth to require_manage_access.
• Never pair allow_origins=["*"] with allow_credentials=True.
• Default the bind address to 127.0.0.1; require an explicit, warned opt-in for external binding.

Acceptance criteria

With default settings, unauthenticated requests to /api/secrets (list/create/update/delete/resolve) are rejected; only callers with manage-role access can reach the router once auth is enabled.

Severity scoring

CVSS 3.1: 9.1 critical — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N PR:N reflects the shipped default: auth.enabled=false, under which require_auth returns None and every route on the secrets router passes through. C:H and I:H are both present because the API permits reading and overwriting every stored secret, including the LLM provider key. S:U: the API grants access to secrets it already manages, so no authority boundary is crossed. A:N is a deliberate choice. The DELETE path destroys stored credentials, which is scored as integrity loss. Deployments that treat loss of the provider key as loss of service availability could score A:H, giving 10.0. With auth.enabled=true, the unauthenticated path closes but the missing manage-role gate remains, so any authenticated user retains the same access: PR:L, giving 8.1.

Fixed in 0.4.4

Fixed by e935697d, released in v0.4.4 (PyPI cuga==0.4.4).

• Default settings (auth.enabled=false). The secrets API (/api/secrets) and the management API (/api/manage) accept only callers on the same machine. A request gets 401 if the peer address is not loopback, if the Host header is not localhost, 127.0.0.1 or [::1], if it has an X-Forwarded-For, X-Real-IP or Forwarded header, or if it has an Origin header that is not one of this app's local UI origins. So a web page in the operator's browser cannot use these APIs. Set auth.allow_local_admin = false to close both APIs to every caller while auth is off.
• Auth on. Both routers require a manage role (ServiceOwner or ServiceAdmin); a chat-only user gets 403. Role checks now always apply when authentication is on: the separate auth.authorization_enabled setting is removed, and an old value is ignored.
• cuga start prints a warning at startup when auth is off.
• Regression tests: tests/unit/test_secrets_auth_gate.py. Upgrade notes.
• With auth on, users need a manage role to use the secrets and management APIs. Before you upgrade, make sure that your identity provider maps a role claim to ServiceOwner or ServiceAdmin.
• With auth off, calls to these APIs from another machine or through a reverse proxy get 401. Turn on auth for such deployments. Not changed in 0.4.4.
• CORS. With auth off, the server still sets allow_origins=["*"] with credentials. The new gate refuses an untrusted Origin on the secrets and management APIs, so this no longer reaches them. CORS for the other APIs is tracked in cuga-project/cuga-agent#1087.
• Bind address. cuga start binds 127.0.0.1 by default; external access needs --host 0.0.0.0. An explicit deployment mode, and a warning when the server listens on all interfaces, are tracked in cuga-project/cuga-agent#1085. Workaround for 0.4.3 and earlier. Upgrade. If you cannot: keep the default --host 127.0.0.1, do not expose the port, and do not browse untrusted sites while CUGA runs with auth off. With auth on, 0.4.3 and earlier still let any logged-in user use the secrets API.