`isPublicApiRoute()` matched every entry of PUBLIC_API_ROUTE_PREFIXES with
`startsWith()`, but 11 of the 15 entries name ONE route, not a subtree. As a
prefix each also marked every adjacent path sharing its leading characters as
PUBLIC, which skips the MANAGEMENT auth gate.
That is reachable today: Next resolves `/api/usage/om-usage<anything>` to the
dynamic route `/api/usage/[connectionId]`, and that handler carries no auth of
its own — it relies entirely on being classified MANAGEMENT. An unauthenticated
caller therefore reaches `fetchAndPersistProviderLimits()`, which is an
existence oracle over connection ids (409/404/400/200) and, for a connection id
actually starting with `om-usage`, discloses live quota JSON and can drive an
OAuth token refresh (a write side effect) with no credentials.
Split the allowlist by shape:
- PUBLIC_API_ROUTE_PREFIXES keeps only genuine subtrees, every entry ending in
"/" (asserted by a unit test, so the class cannot come back silently).
- PUBLIC_API_ROUTES_EXACT holds the single routes, matched exactly in both
spellings.
- The three read-only "prefixes" were single routes too and move to
PUBLIC_READONLY_CORS_API_ROUTES, matched exactly. classify.ts now asks
`isPublicReadonlyCorsRoute()` instead of scanning the raw list, so the CORS
origin relaxation pipeline.ts keys on cannot be inherited by a sibling either
(`/api/monitoring/health-detail` was taking it).
- `/api/health` deliberately stays in its own set so it keeps classifying as
`public_prefix`; folding it into the read-only set would widen CORS on it.
dashboardCsrf.ts had a second copy of the prefix scan; it now shares
`isPublicApiRoute()` so the client CSRF exemption and the server classification
cannot disagree. Side effect in the safe direction: the three LOCAL_ONLY oauth
auto-import routes were CSRF-exempt on the client while the server already
required the token — the client now attaches it.
Reported by @ntdat812 (GHSA-74g9-q8f6-793h), with the shape of the fix and the
two gotchas above called out in the report.
Closes GHSA-74g9-q8f6-793h
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
Co-authored-by: Nguyen Thanh Dat <ntdat812.dev@gmail.com>
⭐5 — 4 achados STILL-REAL de advisories de segurança, cada um com TDD (RED→GREEN) e crédito ao reporter original: ACP RCE hardening (resolveVersionProbe), db-backups Tier-2 allowlist, uppercase authz bypass (matcher case-insensitive), spawn-veto drift (chatgpt-web-codex-doctor). typecheck/lint limpos, suíte authz/acp/cors verde. UNSTABLE é o base-red inherited #9985, já documentado no corpo da PR.
v3.8.40 cycle integration → main. All test gates green (Unit/Integration/Coverage/Node-compat/Quality-Ratchet). The only red check, 'PR Test Policy', is the test-masking heuristic firing on the cumulative ~57-commit release diff (legitimate assert consolidations already reviewed per-PR — Gemini CLI removal #5246, retired GPT models #5280, provider catalog refreshes); overridden with --admin per the documented release-PR convention. CodeQL/SonarQube advisory scans non-blocking; #5278's code already passed CodeQL on main. Homologated on VPS 192.168.0.15 (v3.8.40 healthy).
Centralize optional API key capability checks so dashboard forms and
provider schemas share the same rules, including keyless Pollinations
support and cloud-agent batch testing mode.
Also align auto-combo config on `routerStrategy`, keep legacy combo
reads compatible, preserve MCP routes as management APIs, narrow
`require-login` public access to readonly/bootstrap flows, and make
cloud-agent CORS reflect the request origin for credentialed requests.
- Add exact-match guard for /dashboard/onboarding before the broad /dashboard prefix
- Add setup_wizard and client_api_mcp to ClassificationReason union type
- Update test to verify PUBLIC classification
Co-authored-by: HomerOff <homeroff76@gmail.com>
