Greptile Summary

This PR fixes a regression introduced by the CVE-2026-32919 / CVE-2026-28473 security patches that broke all pure Bearer-token HTTP API integrations (curl, OpenAI SDKs, etc.) against /v1/chat/completions and other endpoints. The root cause was that resolveGatewayRequestedOperatorScopes() returned [] when the x-openclaw-scopes header was absent, causing every authenticated HTTP caller to fail the method-scope gate with missing scope: operator.write.

Key changes:

• src/gateway/http-auth-helpers.ts: resolveGatewayRequestedOperatorScopes now returns a copy of CLI_DEFAULT_OPERATOR_SCOPES (all five operator scopes) when the header is absent, while still returning [] for a present-but-empty header and parsing normally otherwise. The three-way distinction (absent / empty / populated) correctly preserves the CVE boundary for callers that explicitly restrict their own scopes.
• src/gateway/http-auth-helpers.test.ts: Thorough unit tests added covering all parsing branches including edge cases (whitespace-only, trailing commas, copy-not-reference check).
• src/gateway/server.openai-compatible-http-write-scope-bypass.poc.test.ts and sessions-history-http.test.ts: Missing-header expectations updated from 403 → 200; the explicit-scope CVE bypass tests remain unchanged at 403, confirming the security boundary is intact.

One minor finding: On line 36 of http-auth-helpers.ts, the raw === null branch is dead code — getHeader() returns string | undefined and ?.trim() converts any undefined to undefined (never null), so raw is always string | undefined.

Confidence Score: 5/5

Safe to merge — the fix is correct, well-tested, and the only finding is a trivial dead-code check that doesn't affect behavior.

The logic correctly handles all three cases (absent header → default scopes, empty header → no scopes, populated header → parsed scopes). Tests are comprehensive, including copy-not-reference verification. The CVE security boundary for explicit scope declarations is verified to remain intact by the unchanged PoC test assertions. The sole finding (dead raw === null branch) is a P2 style nit with zero runtime impact.

No files require special attention beyond the minor dead-code note in src/gateway/http-auth-helpers.ts line 36.

This is a comment left during a code review.
Path: src/gateway/http-auth-helpers.ts
Line: 36

Comment:
**Dead code: `raw === null` is unreachable**

`getHeader()` is typed to return `string | undefined` (never `null`), and the `?.trim()` optional-chain on line 35 converts any `undefined` result to `undefined` — it cannot produce `null`. Therefore `raw` is always `string | undefined`, making the `raw === null` branch permanently unreachable.

The comment in the PR description says "explicitly checks for `undefined` or `null`", but only the `=== undefined` arm can ever match. Leaving the dead arm in can confuse future readers into thinking `getHeader` might return `null`.

```suggestion
  if (raw === undefined) {
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(gateway ): restore default operator ..." | Re-trigger Greptile}

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

const raw = getHeader(req, OPERATOR_SCOPES_HEADER)?.trim();
if (raw === undefined) {
  return [...CLI_DEFAULT_OPERATOR_SCOPES];
}

export function resolveGatewayRequestedOperatorScopes(req: IncomingMessage): string[] {
  const raw = getHeader(req, OPERATOR_SCOPES_HEADER);
  if (raw === undefined) return []; // absent => no scopes
  const trimmed = raw.trim();
  if (!trimmed) return [];
  return trimmed.split(",").map(s => s.trim()).filter(Boolean);
}

Analyzed PR: #57596 at commit d80e939

_{Last updated on: 2026-03-30T09:44:55Z}

Latest run failed. Keeping previous successful results. Trace ID: 019d3ee58cf290bc5dc0de29fa0796d4.

_{Last updated on: 2026-03-30T16:00:24Z}

Pushed a follow-up commit to drop the dead raw === null check per Greptile's review — good catch, getHeader() only ever returns string | undefined.

For anyone reviewing: the core idea here is a three-way distinction on the x-openclaw-scopes header:

• Header absent → caller is a plain HTTP client (curl, OpenAI SDK, etc.) that doesn't know about scopes at all. We grant CLI_DEFAULT_OPERATOR_SCOPES, same as the CLI gets. This is what was broken.
• Header present but empty → caller explicitly opted into zero scopes. We respect that and return []. This preserves the CVE-2026-32919 / CVE-2026-28473 security boundary.
• Header present with values → parse as before.

I deliberately used the CLI_DEFAULT_OPERATOR_SCOPES constant rather than hardcoding scope strings, so if new scopes get added upstream they'll be picked up automatically. Also returning a spread copy ([...CLI_DEFAULT_OPERATOR_SCOPES]) to avoid anyone accidentally mutating the shared constant.

The PoC test for the CVE bypass still asserts 403 when operator.approvals is explicitly declared — that path is untouched.

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

Severity Title

1 🟠 High Privilege escalation: missing x-openclaw-scopes header grants full CLI operator scopes
Vulnerabilities

1. 🟠 Privilege escalation: missing x-openclaw-scopes header grants full CLI operator scopes

Property Value
Severity High
CWE CWE-285
Location src/gateway/http-auth-helpers.ts:34-47

Description

resolveGatewayRequestedOperatorScopes() treats a missing x-openclaw-scopes header as a signal to grant CLI_DEFAULT_OPERATOR_SCOPES (which include operator.write and operator.admin). Because headers are controlled by the caller, an authenticated HTTP client can omit the header to obtain elevated operator scopes and pass authorizeOperatorScopesForMethod() checks.

Impact:

• Any bearer-token authenticated HTTP request can bypass method-scope gating by simply omitting the header.
• This effectively turns the scope gate into an opt-in restriction rather than an enforcement mechanism, enabling unauthorized access to write/admin endpoints.

Vulnerable code:

const raw = getHeader(req, OPERATOR_SCOPES_HEADER)?.trim();
if (raw === undefined) {
  return [...CLI_DEFAULT_OPERATOR_SCOPES];
}

Recommendation

Do not derive effective authorization scopes from an attacker-controlled request header.

Safer options:

1. Default-deny when the header is absent (treat as no scopes), and require clients to explicitly request scopes:

export function resolveGatewayRequestedOperatorScopes(req: IncomingMessage): string[] {
  const raw = getHeader(req, OPERATOR_SCOPES_HEADER);
  if (raw === undefined) return []; // absent => no scopes
  const trimmed = raw.trim();
  if (!trimmed) return [];
  return trimmed.split(",").map(s => s.trim()).filter(Boolean);
}

2. If certain clients should receive defaults, derive them from server-side trust signals (e.g., mTLS identity, trusted proxy auth mode, or token claims), not the presence/absence of a caller-controlled header.

Additionally, consider validating/whitelisting scopes in the header against the known OperatorScope set to prevent unrecognized scope strings from being treated as meaningful elsewhere.

Analyzed PR: #57596 at commit d80e939

Last updated on: 2026-03-30T09:44:55Z

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

Severity Title

1 🟠 High Privilege escalation: missing x-openclaw-scopes header grants full CLI operator scopes
Vulnerabilities

1. 🟠 Privilege escalation: missing x-openclaw-scopes header grants full CLI operator scopes

Property Value
Severity High
CWE CWE-285
Location src/gateway/http-auth-helpers.ts:34-47

Description

resolveGatewayRequestedOperatorScopes() treats a missing x-openclaw-scopes header as a signal to grant CLI_DEFAULT_OPERATOR_SCOPES (which include operator.write and operator.admin). Because headers are controlled by the caller, an authenticated HTTP client can omit the header to obtain elevated operator scopes and pass authorizeOperatorScopesForMethod() checks.

Impact:

• Any bearer-token authenticated HTTP request can bypass method-scope gating by simply omitting the header.
• This effectively turns the scope gate into an opt-in restriction rather than an enforcement mechanism, enabling unauthorized access to write/admin endpoints.

Vulnerable code:

const raw = getHeader(req, OPERATOR_SCOPES_HEADER)?.trim();
if (raw === undefined) {
  return [...CLI_DEFAULT_OPERATOR_SCOPES];
}

Recommendation

Do not derive effective authorization scopes from an attacker-controlled request header.

Safer options:

1. Default-deny when the header is absent (treat as no scopes), and require clients to explicitly request scopes:

export function resolveGatewayRequestedOperatorScopes(req: IncomingMessage): string[] {
  const raw = getHeader(req, OPERATOR_SCOPES_HEADER);
  if (raw === undefined) return []; // absent => no scopes
  const trimmed = raw.trim();
  if (!trimmed) return [];
  return trimmed.split(",").map(s => s.trim()).filter(Boolean);
}

2. If certain clients should receive defaults, derive them from server-side trust signals (e.g., mTLS identity, trusted proxy auth mode, or token claims), not the presence/absence of a caller-controlled header.

Additionally, consider validating/whitelisting scopes in the header against the known OperatorScope set to prevent unrecognized scope strings from being treated as meaningful elsewhere.

Analyzed PR: #57596 at commit d80e939

Last updated on: 2026-03-30T09:44:55Z

Let me walk through why this finding doesn't represent an actual privilege escalation in practice.

The key thing Aisle's model is missing here is what has already happened before resolveGatewayRequestedOperatorScopes() is ever called. By the time we reach that function, the request has already passed through authorizeGatewayBearerRequestOrReply() — meaning the caller proved they hold a valid gateway Bearer Token. In OpenClaw's auth model, that token is the operator credential. There's no concept of a "low-privilege token" vs. a "high-privilege token" at the HTTP API layer — if you have the token, you're the operator, full stop.

So the scenario Aisle describes — "an attacker omits the header to gain elevated scopes" — requires the attacker to already possess the gateway secret. At that point they don't need to manipulate headers; they already own the box.

The x-openclaw-scopes header was never designed as a security boundary. It's a voluntary self-restriction mechanism: a caller who wants to run with reduced privileges (e.g., a read-only monitoring integration) can opt into that by sending the header. The CVE-2026-32919 / CVE-2026-28473 patches leveraged this mechanism for the WebSocket/UI path where device pairing injects scopes server-side — that's the actual security boundary, and our fix doesn't touch it.

For context:

• Before v3.28 (pre-CVE patches): no method-scope gate existed on HTTP endpoints at all. Token auth = full access. That was the intended behavior.
• v3.28+ (post-CVE): the scope gate was added but resolveGatewayRequestedOperatorScopes() returned [] for missing headers, accidentally breaking all headless HTTP callers. That's the regression this PR fixes.
• Our fix: restores the pre-v3.28 effective behavior for authenticated HTTP callers while preserving the CVE security boundary for explicit scope declarations.

Aisle's second suggestion (deriving scopes from server-side trust signals like token claims) is genuinely a good long-term direction, but it would require changes to the token issuance and validation pipeline — well beyond the scope of a targeted regression fix.

tl;dr — the "attacker" in this scenario already has the keys to the kingdom. We're not granting them anything they didn't already have.

Landed on main.

• Landed source commit: 8e5f4e7
• Merge commit: 9d5c523

Thanks @openperf.