<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 11 Oct 2026 14:48:34 +0000</lastBuildDate>
    <item>
      <title>GHSA-hfpr-jhpq-x4rm — OpenClaw: `operator.write` chat.send could reach admin-only config writes</title>
      <link>https://db.gcve.eu/vuln/ghsa-hfpr-jhpq-x4rm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: openclaw&lt;/p&gt;
&lt;p&gt;### Summary
A gateway client authenticated with `operator.write` could route `/config set` or `/config unset` through `chat.send` and reach persistent config mutation even though direct config RPC methods are admin-scoped.&lt;/p&gt;
&lt;p&gt;### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published vulnerable version: `2026.3.2`
- Affected range: `&amp;lt;= 2026.3.2`
- Patched in: `2026.3.7`&lt;/p&gt;
&lt;p&gt;### Details
Before the fix, `chat.send` ran slash commands in an internal gateway-chat context with `CommandAuthorized: true`, and `/config` write paths only checked command authorization plus `commands.config` / `channels.&amp;lt;provider&amp;gt;.configWrites` gates. That allowed an authenticated `operator.write` gateway client to bridge into persistent config writes even though direct `config.*` RPC methods remain `operator.admin` scoped.&lt;/p&gt;
&lt;p&gt;The fix keeps command functionality intact while restoring the intended scope boundary:
- persistent `/config set|unset` writes routed through gateway `chat.send` now require `operator.admin`
- read-only `/config show` remains available to normal write-scoped gateway clients
- normal messaging-channel `/config` behavior remains unchanged&lt;/p&gt;
&lt;p&gt;### Impact
This is a real authorization mismatch, but exploitability requires an already authenticated gateway client with `operator.write`, `chat.send` access, and `/config` command support enabled. Maintainer severity is set to medium because the bug is a scoped control-plane privilege mismatch rather than a broad unauthenticated…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: openclaw&lt;/p&gt;
&lt;p&gt;### Summary
A gateway client authenticated with `operator.write` could route `/config set` or `/config unset` through `chat.send` and reach persistent config mutation even though direct config RPC methods are admin-scoped.&lt;/p&gt;
&lt;p&gt;### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published vulnerable version: `2026.3.2`
- Affected range: `&amp;lt;= 2026.3.2`
- Patched in: `2026.3.7`&lt;/p&gt;
&lt;p&gt;### Details
Before the fix, `chat.send` ran slash commands in an internal gateway-chat context with `CommandAuthorized: true`, and `/config` write paths only checked command authorization plus `commands.config` / `channels.&amp;lt;provider&amp;gt;.configWrites` gates. That allowed an authenticated `operator.write` gateway client to bridge into persistent config writes even though direct `config.*` RPC methods remain `operator.admin` scoped.&lt;/p&gt;
&lt;p&gt;The fix keeps command functionality intact while restoring the intended scope boundary:
- persistent `/config set|unset` writes routed through gateway `chat.send` now require `operator.admin`
- read-only `/config show` remains available to normal write-scoped gateway clients
- normal messaging-channel `/config` behavior remains unchanged&lt;/p&gt;
&lt;p&gt;### Impact
This is a real authorization mismatch, but exploitability requires an already authenticated gateway client with `operator.write`, `chat.send` access, and `/config` command support enabled. Maintainer severity is set to medium because the bug is a scoped control-plane privilege mismatch rather than a broad unauthenticated…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-hfpr-jhpq-x4rm</guid>
    </item>
  </channel>
</rss>
