GHSA-vmjq-hvgq-2wv4

### Summary The `PATCH /api/settings` endpoint writes the entire request body to persistent settings without a field whitelist. An authenticated user can set security-critical fields that are not meant to be modifiable here — notably `requireLogin`. Setting `requireLogin: false` disables authentication for the whole application, exposing all protected routes (e.g. `/api/keys`, `/api/providers`) to unauthenticated access.

### Details Root cause is unfiltered mass assignment (CWE-915):

- `src/app/api/settings/route.js` (PATCH handler) parses the body and passes it to `updateSettings(body)`, with special handling only for `newPassword` and `oidcClientSecret`. All other fields pass through. - `src/lib/db/repos/settingsRepo.js` — `updateSettings` does `next = { ...current, ...updates }`, so any key in the body overwrites stored settings, including `requireLogin`, `tunnelDashboardAccess`, `authMode`. - `src/dashboardGuard.js` — `isAuthenticated` returns `true` whenever `settings.requireLogin === false`, bypassing auth on all protected routes.

This is distinct from CVE-2026-5842 (CWE-285, pre-auth bypass on `/api`, patched in 0.3.75). This finding requires a valid authenticated session and abuses input handling, not missing authentication.

### PoC Instance on `localhost:20128`, default password `123456`.

1. Authenticate, capture session: `POST /api/auth/login` body `{"password":"123456"}` → `200 {"success":true}` 2. Mass-assign with the authenticated session: `PATCH /api/settings` body `{"requireLogin":false}` → `200`, response confirms `"requireLogin":false` 3. Verify bypass with NO session/credentials: `GET /api/keys` → `200`, returns full API key list unauthenticated 4. Cleanup (authenticated): `PATCH /api/settings` body `{"requireLogin":true}` → `GET /api/keys` returns `401` again

### Impact Post-authentication mass assignment. Any authenticated user (including one using the default password) can disable authentication globally, then read all stored API keys and provider connection data without credentials, and toggle tunnel/dashboard exposure. Escalates to remote full compromise when chained with the default password `123456` on an instance exposed via tunnel (`tunnelDashboardAccess` defaults to `true`).

### Suggested fix Whitelist user-configurable fields in the PATCH handler; move security-critical fields (`requireLogin`, `tunnelDashboardAccess`, `authMode`) to a dedicated endpoint requiring re-authentication (current-password re-entry), mirroring the existing DB export/import re-auth flow.