Two OpenClaw Agent-Authority Holes Closed on Main: Forged Plugin Owners and Ungoverned Terminal Input

Two privilege-boundary repairs merged into OpenClaw’s main branch within roughly five hours of each other, both tagged P0 by the project’s own triage labels. They are separate bugs with a shared theme: a component treated an authority claim as authority. If you operate a multi-user OpenClaw Gateway — especially one with public or low-trust channel ingress — both belong on your upgrade checklist.

The facts, briefly

PR #104872, merged 2026-08-26 03:36 UTC: public plugin ingress could claim owner privileges. The pull request states the problem plainly: “Public plugin ingress could claim owner privileges and reach owner-only tools.” The repair strips owner authority from public ingress entirely. Only an exact, live trusted plugin/channel capability injected by the host preserves authenticated owner state — a forged claim from a caller can no longer carry it. The maintainers report reproducing the original privilege-escalation regression before the fix and verifying that real production tool construction exposes no privileged tools to forged callers while genuine authenticated owners retain access.

PR #129604, merged 2026-08-25 22:59 UTC (closes issue #124946): agents could create and control their own Gateway-hosted terminals without honoring the execution permissions selected for their session. After the fix, terminal creation belongs to the authenticated operator through the Control UI. Agents can list, read, resize, and close only terminals the operator already opened for their exact session. Terminal input now follows the same effective policy as command execution: Full-access sessions send immediately, Guarded and Workspace/allowlist modes require a fresh one-time approval showing the exact input, and Read-only or execution-denied sessions reject the write. Every input path shares one final synchronous check that revalidates the live run, receipt authority, Gateway, and terminal owner immediately before the PTY is touched — and it fails closed on missing, released, replaced, canceled, or aborted runs.

Why the pairing matters

Interpretation, not a claim from the project: these are two halves of the same lesson. #104872 is about who may hold an identity — a sender on a public channel asserting it owns the conversation. #129604 is about what a holder may do — a trusted agent using its runtime to reach a shell its session policy never authorized. An attacker chains exactly these: forge or ride a weak identity, then use whatever tool surface that identity unlocks. Fixing either alone leaves a workable path; landing both in one day meaningfully narrows the chain.

It is also worth noting what did not change, because it constrains how much you must redo: the terminal fix keeps normal interactive operator access intact, keeps read-only agent sessions usable, and explicitly allows agents to collaborate with terminals the operator opened for them. This is a governance change, not a feature removal.

What operators should do

1. Upgrade to a main build that includes both merges (anything built after 2026-08-26 03:36 UTC carries both), or to the next release that includes them once published. Check openclaw --version against what your install channel currently delivers rather than assuming.
2. Re-check who counts as an owner on your channels. After upgrading, confirm from a non-owner sender account that owner-only plugin tools no longer appear where they previously leaked. If you relied on any pre-fix behavior here, treat that reliance as broken by design.
3. Expect approval prompts for terminal input in restricted sessions. In Guarded or Workspace mode, each terminal input now needs a fresh approval showing the exact keystrokes. That friction is the control working. Do not “fix” it by widening sessions to Full access unless you have decided the agent should have it.
4. Review standing automation that touched agent-created terminals. Anything scripted around agent-created shells will stop working; the PR notes agent-created shells and their detached-task ownership plumbing were removed outright.
5. Do not trust pre-fix audit logs as a complete record. Interpretation caveat: if either behavior existed in your environment, activity performed through forged-owner or self-created terminal paths may be under-attributed in logs written before the upgrade.

Verification status

This desk verified both merge records, full pull-request bodies, and commit SHAs from captured primary-source data (GitHub API payloads collected deterministically into the editorial intel database). The maintainers’ test claims — hundreds of owner/plugin/Discord tests for #104872; 598 focused tests plus the repository’s full changed-file gate for #129604 — are reported by the PRs themselves and are consistent with the project’s usual evidence standard, but we have not independently re-run those suites. No CVE number or GitHub Security Advisory accompanied either merge at verification time; absence of an advisory is not evidence of absent impact.