PT-2026-31838 · Npm · Openclaw

Publicado

2026-03-30

·

Atualizado

2026-03-30

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
Fixed in OpenClaw 2026.3.24, the current shipping release.

Summary

The shared /allowlist command persists channel authorization config through writeConfigFile(...) but does not re-validate gateway client scopes for internal gateway callers. Because chat.send is intentionally reachable to operator.write callers and still creates a generic command-authorized internal context, an authenticated write-scoped gateway client can indirectly mutate channel allowFrom and groupAllowFrom policy that direct config.patch correctly reserves to operator.admin.
This is not just a generic code smell. The current code already shows the intended boundary by adding sink-side internal admin checks to shared /config and /plugins writes, but /allowlist was left behind.

Details

The gateway's documented scope split is clear:
  • chat.send is a write-scoped action.
  • direct config mutation is an admin-scoped action.
The vulnerable path is:
  1. A gateway client authenticates with operator.write.
  2. The client calls chat.send, which is intentionally allowed for that scope.
  3. chat.send builds an internal message context with CommandAuthorized: true and carries GatewayClientScopes into the reply pipeline.
  4. resolveCommandAuthorization(...) converts that internal message into isAuthorizedSender=true in the common case where no stricter commands.allowFrom override is configured.
  5. /allowlist add|remove accepts that generic command authorization and proceeds into its config-backed edit path.
  6. The handler clones the parsed config, calls plugin.allowlist.applyConfigEdit(...), validates the result, and persists it with writeConfigFile(validated.config).
  7. No sink-side check requires operator.admin before the persistent write occurs.
That creates a direct control-plane mismatch:
  • config.patch rejects the same caller with missing scope: operator.admin.
  • /allowlist add dm ... or /allowlist add group ... reached through chat.send can still rewrite channel authorization state.

Impact

  • A gateway client intentionally limited to operator.write can persist first-party channel authorization policy.
  • The caller can widen DM or group allowlists for channels using the shared /allowlist plumbing.
  • This weakens the repo's documented control-plane privilege split between ordinary write actions and admin-only persistent authorization mutation.

Remediation

1) Add the Missing Sink-Side Internal Admin Check to /allowlist

Mirror the existing hardened pattern from /config and /plugins.
Before any config-backed /allowlist add|remove write, require:
  • operator.admin for internal gateway channels
This should happen before plugin.allowlist.applyConfigEdit(...) and before writeConfigFile(...).

2) Keep Pairing-Store and Config-Write Policy Checks, but Do Not Treat Them as Scope Enforcement

configWrites policy and pairing-store behavior are useful secondary controls, but they do not replace the missing privilege check between operator.write and operator.admin.

Improper Privilege Management

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Enumeração de Fraquezas

CWE-269

Identificadores relacionados

GHSA-94PW-C6M8-P9P9

Produtos afetados

Openclaw