fix(authz): hard-gate every credential export and CLI-config write (GHSA-5926-2w35-7h4q)

[diegosouzapw]

Fixes GHSA-5926-2w35-7h4q (HIGH), reported by @skeletonsec. Targets release/v3.8.51.

The report, confirmed on the tip

POST /api/providers/{id}/claude-auth/export and .../codex-auth/export gate on requireManagementAuth(request) with no alwaysRequireAuth, and neither path was in ALWAYS_PROTECTED_API_PATHS. Under requireLogin=false — the local-first default — both fail open: anyone who knows a connection id downloads the operator's raw Claude/Codex OAuth access_token / refresh_token, plus the Codex id_token.

The report is exactly right, including the part that stings: this is the third recurrence of one class. GHSA-mghq-58h3-qcqj added /api/db-backups; GHSA-v7g9-7f55-5g46 added the /api/settings/*-json siblings mghq had missed; these two are the siblings both missed.

So the fix is against the class, not the two routes

Sweeping every route that hands out stored credentials, dumps captured traffic, or writes the operator's CLI config turned up four more sitting on the fail-open tier:

Route	What it does anonymously under requireLogin=false
GET /api/logs/export	dumps call_logs (prompts and responses) and proxy_logs, up to 168h
/api/cli-tools/codex-profiles	GET leaks the operator's account label; PUT writes attacker-supplied auth.json + config.toml into the host's Codex CLI config
{claude,codex}-auth/apply-local	writes a stored credential into ~/.codex/auth.json / the Claude equivalent
providers/agy-auth/apply-local	writes into ~/.gemini/antigravity-cli/antigravity-oauth-token

The codex-profiles one is arguably worse than what was reported, because it is a write. Its only guard is ensureCliConfigWriteAllowed() called with no targetPath, which reduces to CLI_ALLOW_CONFIG_WRITES — default true. Paired with the sibling POST that stores an arbitrary profile, the chain is: POST a profile holding the attacker's auth.json, PUT it, and the operator's Codex CLI now runs on attacker credentials — or, via config.toml, against an attacker-controlled base URL, which puts every subsequent prompt through them.

The traffic-inspector HAR exports were already covered by LOCAL_ONLY — verified, not assumed.

Implementation

Routes with a dynamic segment cannot be expressed in the exact/prefix list: a /api/providers/ prefix would hard-gate the entire provider surface and break every keyless install. So this adds ALWAYS_PROTECTED_API_PATTERNS, mirroring the LOCAL_ONLY_API_PATTERNS that already exists for the same reason, and isAlwaysProtectedPath consults both.

Two deliberate calls, both flagged because they are judgement rather than mechanics:

• apply-local gets ALWAYS_PROTECTED, not LOCAL_ONLY. It closes the anonymous hole without breaking an operator driving the dashboard through a tunnel. LOCAL_ONLY would be defensible on "it writes to the host's home dir", but it changes a working flow for a legitimate setup.
• No { alwaysRequireAuth: true } at the handlers, even though the report suggests it. Tier 2 is the architecture's designated mechanism and the guard runs before the handler, so it would be redundant — and a second copy of the same decision inside each route is exactly the kind of duplicate that drifts (cf. the dashboardCsrf prefix scan that had to be unified in fix(authz): match exact public routes exactly, not as prefixes (GHSA-74g9-q8f6-793h) #11417). If you would rather have belt-and-braces here, say so and I will add it.

Validation

tests/unit/authz/credential-export-always-protected.test.ts — 5 tests, red before the fix. Written as an inventory of the whole class rather than two more assertions, so recurrence #4 fails the suite instead of arriving as an advisory. Includes the negative cases that matter:

• /api/providers, /api/providers/{id}, /api/providers/{id}/models, /api/providers/{id}/claude-auth must stay on MANAGEMENT — hard-gating them would break keyless local-first installs
• a connection id containing a slash must not slip past [^/]+ and fall back to the fail-open tier
• both trailing-slash spellings gated
• the already-fixed mghq/v7g9 entries pinned so a refactor cannot silently drop them

Runs, hermetic (env -u OMNIROUTE_API_KEY):

• tests/unit/authz/** + openapi-security-tiers + check-route-guard-membership + public-api-routes — 298/298
• typecheck:core — exit 0, no output
• check:docs-sync, check:tracked-artifacts — PASS
• prettier --check clean; eslint: the 8 errors in openapi-security-tiers.test.ts are the pre-existing no-explicit-any set already frozen in eslint-suppressions.json (count: 8, unchanged — this diff adds and removes no any)

docs/openapi.yaml marks the seven newly-gated operations x-always-protected, and openapi-security-tiers.test.ts now resolves {param} placeholders so it can validate pattern entries — aligned to the new contract, not relaxed.

[diegosouzapw]

/sweep-reds round 6 — FQG diagnosis (no code change)

gate(s) failed: public-creds is inherited from origin/release/v3.8.51 tip, not from this PR.

FQG job: https://github.com/diegosouzapw/OmniRoute/actions/runs/33753300941/job/100642036504
Annotation: 1 gate(s) failed: public-creds

Reproduced on a clean tip checkout (c41d8755db; still present on e1cf542378):

[check-public-creds] 1 entrada(s) obsoleta(s) na allowlist:
  ✗ open-sse/executors/zcodeProtocol.ts:302:omniroute-${process.pid}
[check-public-creds] 1 credencial(is) pública(s) como string literal:
  ✗ open-sse/executors/zcodeProtocol.ts L313: clientId = "omniroute-${process.pid}"

Cause: e2e330a058 (#12179) shifted clientId from L302 → L313. KNOWN_LITERAL_CREDS in scripts/check/check-public-creds.mjs still keys the old line. This PR does not touch zcodeProtocol.ts or that allowlist (diff is routeGuard + openapi + stryker tap.testFiles only).

Own complexity / file-size / mutation: not in the failed-gate list (FQG failed only public-creds).

Not merging origin/release into this PR (base-red #12581 OPEN). Holding until a base-reds PR retargets the allowlist line-key (302 → 313).