GHSA-vmjq-hvgq-2wv4: Npm/9router vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/9routerto a version that resolves this vulnerability.Fixed in 0.5.4 - Configuration
Restrict the PATCH handler to an explicit whitelist of user-configurable fields. Move requireLogin, tunnelDashboardAccess, and authMode to a dedicated endpoint that requires current-password re-entry, mirroring the existing DB export/import re-authentication flow.
PATCH /api/settings request field handling = Whitelist user-configurable fields; require current-password re-authentication for requireLogin, tunnelDashboardAccess, and authMode
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs a valid authenticated session to send a PATCH request to /api/settings. The issue is therefore not a pre-authentication bypass by itself.
What is the impact if an attacker changes the affected setting?
Changing requireLogin to false disables authentication application-wide. Protected routes, including /api/keys and /api/providers, can then be accessed without authentication.
How can I check whether an instance may already have been affected?
Inspect the persisted settings for requireLogin set to false, and review other security-sensitive settings such as tunnelDashboardAccess and authMode. The vulnerable update behavior permits request-body fields to overwrite stored settings.
Is this the same issue as CVE-2026-5842?
No. This finding is distinct from CVE-2026-5842, which is described as a pre-authentication bypass on /api and was patched in 0.3.75.