Claude-assisted Synology Chat code replaced the webhook's stable numeric recipient with a lookup by mutable nickname or username, so a colliding account could receive another user's reply.

How AI contributed: Direct introductionPublished Mar 26, 2026 in openclaw/openclawAll 35 findings in this repository

Show full advisory description

Summary Synology Chat reply delivery could rebind to a mutable username match instead of the stable numeric user_id recorded by the webhook event. Affected Packages / Versions · Package: openclaw (npm) · Affected: < 2026.3.22 · Fixed: >= 2026.3.22 · Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87) · Latest published npm version checked: 2026.3.23-2 Fix Commit(s) · 7ade3553b74ee3f461c4acd216653d5ba411f455 Release Status The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2. Code-Level Confirmation · extensions/synology-chat/src/webhook-handler.ts now keeps replies bound to the stable webhook user identifier unless an explicit dangerous opt-in is enabled. · extensions/synology-chat/src/config-schema.ts contains the explicit dangerous opt-in seam instead of silent username rebinding. OpenClaw thanks @nexrin for reporting.

What actually happened

GHSA-wv46-v6xc-2qhf aliases CVE-2026-35670. Parent of ce12b909 sends webhook replies to payload.user_id. Member ce12b909 (Claude Opus 4.6) adds resolveChatUserId nickname/username matching via user_list. Squash 9a3800d8 (#23709) keeps byNickname; member/carrier blobs differ. Fix 7ade3553 returns payload.user_id unless dangerouslyAllowNameMatching. 630f1479 is 2026.3.23-2 changelog only. v2026.3.1 lacks the carrier. v2026.3.2 contains the carrier and byNickname without the gate. v2026.3.22 contains the fix. Member is not a tag ancestor.

Root cause

Authentication & access control introduced

The Claude-coauthored squash added nickname and username resolution and used the result as the recipient for immediate and buffered replies.

AI-assisted change: Claude

9a3800d8e6

extensions/synology-chat/src/webhook-handler.ts extensions/synology-chat/src/channel.ts

Fix

Security fix

The direct fix keeps replies on the webhook's stable user_id by default and permits name matching only behind an explicitly dangerous compatibility flag.

Fix by Peter Steinberger · no AI marker found

7ade3553b7

extensions/synology-chat/src/accounts.ts extensions/synology-chat/src/webhook-handler.ts

Case facts

CVE ID: CVE-2026-35670
GHSA ID: GHSA-WV46-V6XC-2QHF
Published: Mar 26, 2026
Severity: MEDIUM
Language: TypeScript
AI tool: Claude
AI role: Direct introduction
Vulnerable release: v2026.3.2
Fixed release: v2026.3.22

CWE-639 CWE-706 CWE-807 CWE-807 RELIANCE ON UNTRUSTED INPUTS IN A SECURITY DECISION

Advisory source

AI-assisted change

AI-assisted changeextensions/synology-chat/src/webhook-handler.ts source openclaw/openclaw@9a3800d8e6+29−5

@@ -10,7 +10,7 @@ import {   readRequestBodyWithLimit,   requestBodyErrorToText, } from "openclaw/plugin-sdk";

Show 24 hidden lines

-import { sendMessage } from "./client.js";+import { sendMessage, resolveChatUserId } from "./client.js"; import { validateToken, authorizeUserForDm, sanitizeInput, RateLimiter } from "./security.js"; import type { SynologyWebhookPayload, ResolvedSynologyChatAccount } from "./types.js"; @@ -225,6 +225,8 @@ export interface WebhookHandlerDeps {     chatType: string;     sessionKey: string;     accountId: string;+    /** Chat API user_id for sending replies (may differ from webhook user_id) */+    chatUserId?: string;   }) => Promise<string | null>;   log?: {     info: (...args: unknown[]) => void;@@ -330,8 +332,29 @@ export function createWebhookHandler(deps: WebhookHandlerDeps) {     // ACK immediately so Synology Chat won't remain in "Processing..."     respondNoContent(res); +    // Default to webhook user_id; may be replaced with Chat API user_id below.+    let replyUserId = payload.user_id;+     // Deliver to agent asynchronously (with 120s timeout to match nginx proxy_read_timeout)     try {+      // Resolve the Chat-internal user_id for sending replies.

+      // Synology Chat outgoing webhooks use a per-integration user_id that may+      // differ from the global Chat API user_id required by method=chatbot.+      // We resolve via the user_list API, matching by nickname/username.+      const chatUserId = await resolveChatUserId(+        account.incomingUrl,+        payload.username,+        account.allowInsecureSsl,+        log,+      );+      if (chatUserId !== undefined) {+        replyUserId = String(chatUserId);+      } else {+        log?.warn(+          `Could not resolve Chat API user_id for "${payload.username}" — falling back to webhook user_id ${payload.user_id}. Reply delivery may fail.`,

Show 38 hidden lines

+        );+      }+       const sessionKey = `synology-chat-${payload.user_id}`;       const deliverPromise = deliver({         body: cleanText,@@ -341,6 +364,7 @@ export function createWebhookHandler(deps: WebhookHandlerDeps) {         chatType: "direct",         sessionKey,         accountId: account.accountId,+        chatUserId: replyUserId,       });        const timeoutPromise = new Promise<null>((_, reject) =>@@ -349,19 +373,19 @@ export function createWebhookHandler(deps: WebhookHandlerDeps) {        const reply = await Promise.race([deliverPromise, timeoutPromise]); -      // Send reply back to Synology Chat+      // Send reply back to Synology Chat using the resolved Chat user_id       if (reply) {-        await sendMessage(account.incomingUrl, reply, payload.user_id, account.allowInsecureSsl);+        await sendMessage(account.incomingUrl, reply, replyUserId, account.allowInsecureSsl);         const replyPreview = reply.length > 100 ? `${reply.slice(0, 100)}...` : reply;-        log?.info(`Reply sent to ${payload.username} (${payload.user_id}): ${replyPreview}`);+        log?.info(`Reply sent to ${payload.username} (${replyUserId}): ${replyPreview}`);       }     } catch (err) {       const errMsg = err instanceof Error ? `${err.message}\n${err.stack}` : String(err);       log?.error(`Failed to process message from ${payload.username}: ${errMsg}`);       await sendMessage(         account.incomingUrl,         "Sorry, an error occurred while processing your message.",-        payload.user_id,+        replyUserId,         account.allowInsecureSsl,       );     }

The Claude-coauthored change resolves a stable webhook user ID through mutable nickname or username data, then carries that resolved value into direct reply delivery. A renamed or colliding account can therefore redirect the bot's response.

AI-assisted changeextensions/synology-chat/src/channel.ts source openclaw/openclaw@9a3800d8e6+5−1

@@ -243,6 +243,10 @@ export function createSynologyChatPlugin() {             const rt = getSynologyRuntime();             const currentCfg = await rt.config.loadConfig(); +            // The Chat API user_id (for sending) may differ from the webhook+            // user_id (used for sessions/pairing). Use chatUserId for API calls.+            const sendUserId = msg.chatUserId ?? msg.from;+             // Build MsgContext using SDK's finalizeInboundContext for proper normalization             const msgCtx = rt.channel.reply.finalizeInboundContext({

Show 10 hidden lines

               Body: msg.body,@@ -275,7 +279,7 @@ export function createSynologyChatPlugin() {                     await sendMessage(                       account.incomingUrl,                       text,-                      msg.from,+                      sendUserId,                       account.allowInsecureSsl,                     );                   }

The channel uses the resolved chatUserId as the recipient for buffered replies. This completes the vulnerable path from mutable name matching to the outbound send target.

Security fix

Fixextensions/synology-chat/src/accounts.ts source openclaw/openclaw@7ade3553b7+1−0

@@ -91,0 +92,1 @@+    dangerouslyAllowNameMatching: merged.dangerouslyAllowNameMatching ?? false,

Account resolution now defaults the compatibility flag to false. Deployments that do nothing therefore retain the stable numeric webhook recipient instead of entering mutable-name lookup.

Fixextensions/synology-chat/src/webhook-handler.ts source openclaw/openclaw@7ade3553b7+3−0

@@ -376,0 +377,3 @@+  if (!params.account.dangerouslyAllowNameMatching) {+    return params.payload.user_id;+  }

The reply resolver now returns the stable payload user_id before any nickname or username lookup unless an operator deliberately enables the dangerous compatibility mode.

Patch fingerprints

AI-assisted change 8ca5d13c7d7b19b3e1286b26dab9e247b994500d4dfb1ae25dfdd79fccae32ae · Fix 1aee95f59e7836d23fa1e330385cf7298777f6e99c2c1cc916f9ee484ba8d895

Advisory references

Claude-assisted Synology Chat code replaced the webhook's stable numeric recipient with a lookup by mutable nickname or username, so a colliding account could receive another user's reply.

Show full advisory description

What actually happened

AI-assisted change

AI-assisted changeextensions/synology-chat/src/webhook-handler.ts source openclaw/openclaw@9a3800d8e6+29−5

@@ -10,7 +10,7 @@ import {   readRequestBodyWithLimit,   requestBodyErrorToText, } from "openclaw/plugin-sdk";

Show 24 hidden lines

-import { sendMessage } from "./client.js";+import { sendMessage, resolveChatUserId } from "./client.js"; import { validateToken, authorizeUserForDm, sanitizeInput, RateLimiter } from "./security.js"; import type { SynologyWebhookPayload, ResolvedSynologyChatAccount } from "./types.js"; @@ -225,6 +225,8 @@ export interface WebhookHandlerDeps {     chatType: string;     sessionKey: string;     accountId: string;+    /** Chat API user_id for sending replies (may differ from webhook user_id) */+    chatUserId?: string;   }) => Promise<string | null>;   log?: {     info: (...args: unknown[]) => void;@@ -330,8 +332,29 @@ export function createWebhookHandler(deps: WebhookHandlerDeps) {     // ACK immediately so Synology Chat won't remain in "Processing..."     respondNoContent(res); +    // Default to webhook user_id; may be replaced with Chat API user_id below.+    let replyUserId = payload.user_id;+     // Deliver to agent asynchronously (with 120s timeout to match nginx proxy_read_timeout)     try {+      // Resolve the Chat-internal user_id for sending replies.

+      // Synology Chat outgoing webhooks use a per-integration user_id that may+      // differ from the global Chat API user_id required by method=chatbot.+      // We resolve via the user_list API, matching by nickname/username.+      const chatUserId = await resolveChatUserId(+        account.incomingUrl,+        payload.username,+        account.allowInsecureSsl,+        log,+      );+      if (chatUserId !== undefined) {+        replyUserId = String(chatUserId);+      } else {+        log?.warn(+          `Could not resolve Chat API user_id for "${payload.username}" — falling back to webhook user_id ${payload.user_id}. Reply delivery may fail.`,

Show 38 hidden lines

+        );+      }+       const sessionKey = `synology-chat-${payload.user_id}`;       const deliverPromise = deliver({         body: cleanText,@@ -341,6 +364,7 @@ export function createWebhookHandler(deps: WebhookHandlerDeps) {         chatType: "direct",         sessionKey,         accountId: account.accountId,+        chatUserId: replyUserId,       });        const timeoutPromise = new Promise<null>((_, reject) =>@@ -349,19 +373,19 @@ export function createWebhookHandler(deps: WebhookHandlerDeps) {        const reply = await Promise.race([deliverPromise, timeoutPromise]); -      // Send reply back to Synology Chat+      // Send reply back to Synology Chat using the resolved Chat user_id       if (reply) {-        await sendMessage(account.incomingUrl, reply, payload.user_id, account.allowInsecureSsl);+        await sendMessage(account.incomingUrl, reply, replyUserId, account.allowInsecureSsl);         const replyPreview = reply.length > 100 ? `${reply.slice(0, 100)}...` : reply;-        log?.info(`Reply sent to ${payload.username} (${payload.user_id}): ${replyPreview}`);+        log?.info(`Reply sent to ${payload.username} (${replyUserId}): ${replyPreview}`);       }     } catch (err) {       const errMsg = err instanceof Error ? `${err.message}\n${err.stack}` : String(err);       log?.error(`Failed to process message from ${payload.username}: ${errMsg}`);       await sendMessage(         account.incomingUrl,         "Sorry, an error occurred while processing your message.",-        payload.user_id,+        replyUserId,         account.allowInsecureSsl,       );     }

AI-assisted changeextensions/synology-chat/src/channel.ts source openclaw/openclaw@9a3800d8e6+5−1

@@ -243,6 +243,10 @@ export function createSynologyChatPlugin() {             const rt = getSynologyRuntime();             const currentCfg = await rt.config.loadConfig(); +            // The Chat API user_id (for sending) may differ from the webhook+            // user_id (used for sessions/pairing). Use chatUserId for API calls.+            const sendUserId = msg.chatUserId ?? msg.from;+             // Build MsgContext using SDK's finalizeInboundContext for proper normalization             const msgCtx = rt.channel.reply.finalizeInboundContext({

Show 10 hidden lines

               Body: msg.body,@@ -275,7 +279,7 @@ export function createSynologyChatPlugin() {                     await sendMessage(                       account.incomingUrl,                       text,-                      msg.from,+                      sendUserId,                       account.allowInsecureSsl,                     );                   }

The channel uses the resolved chatUserId as the recipient for buffered replies. This completes the vulnerable path from mutable name matching to the outbound send target.

Security fix

Fixextensions/synology-chat/src/accounts.ts source openclaw/openclaw@7ade3553b7+1−0

@@ -91,0 +92,1 @@+    dangerouslyAllowNameMatching: merged.dangerouslyAllowNameMatching ?? false,

Account resolution now defaults the compatibility flag to false. Deployments that do nothing therefore retain the stable numeric webhook recipient instead of entering mutable-name lookup.

Fixextensions/synology-chat/src/webhook-handler.ts source openclaw/openclaw@7ade3553b7+3−0

@@ -376,0 +377,3 @@+  if (!params.account.dangerouslyAllowNameMatching) {+    return params.payload.user_id;+  }

The reply resolver now returns the stable payload user_id before any nickname or username lookup unless an operator deliberately enables the dangerous compatibility mode.