Description

processMessage() logs the inbound dedupe key (BlueBubbles messageId / associatedMessageGuid) and senderId whenever a message is dropped as a duplicate or inflight.

These values are likely stable identifiers that can be correlated with users/conversations (e.g., sender phone/email/handle and message GUIDs). Writing them to logs can expose PII/sensitive metadata to:

• operators who should not see message metadata
• log aggregation / SIEM systems with broader access than the app runtime
• incident/support artifacts shared externally

Vulnerable code:

if (claim.kind === "duplicate" || claim.kind === "inflight") {
  logVerbose(
    core,
    runtime,
    `drop: ${claim.kind} inbound key=${sanitizeForLog(dedupeKey ?? "")} sender=${sanitizeForLog(message.senderId)}`,
  );
  return;
}

Recommendation

Avoid logging raw sender identifiers and message GUIDs. Prefer one of:

• omit these fields entirely
• log a short, non-reversible digest (stable for correlation but not directly identifying)
• log only a minimal prefix/suffix (last 4) if needed for debugging

Example (hash + truncation):

import { createHash } from "node:crypto";

function hashForLog(value: string): string {
  return createHash("sha256").update(value, "utf8").digest("hex").slice(0, 12);
}

const keyTag = dedupeKey ? hashForLog(dedupeKey) : "";
const senderTag = message.senderId ? hashForLog(String(message.senderId)) : "";

logVerbose(core, runtime, `drop: ${claim.kind} inbound key_hash=${keyTag} sender_hash=${senderTag}`);

Also consider gating even the hashed output behind an explicit debug setting, and ensure logs are access-controlled and retained minimally.

Description

In processMessageAfterDedupe's dispatcher onError handler, the code logs String(err) directly to runtime.error.

• err can originate from sendMessageBlueBubbles, which throws errors that include untrusted BlueBubbles server response bodies (e.g., errorText = await res.text()), potentially containing attacker-controlled content, CR/LF, control characters, or sensitive details.
• Logging unfiltered error strings enables log forging/injection (newline/control chars) and may unintentionally persist sensitive data (server error payloads, stack traces, message content) into centralized logs.
• A sanitizeForLog() helper was introduced in the same file and used for other log lines, but is not applied here.

Vulnerable code:

onError: (err, info) => {
  if (info.kind === "final") {
    dedupeSignal.deliveryFailed = true;
  }
  runtime.error?.(`BlueBubbles ${info.kind} reply failed: ${String(err)}`);
},

Recommendation

Sanitize or structure error logging to prevent log forging and reduce sensitive data exposure.

Option A (reuse existing helper):

runtime.error?.(
  `BlueBubbles ${info.kind} reply failed: ${sanitizeForLog(err)}`,
);

Option B (structured logging with minimal fields):

runtime.error?.(
  `BlueBubbles reply failed kind=${sanitizeForLog(info.kind)} err=${sanitizeForLog((err as Error)?.message ?? err)}`
);

Additionally consider avoiding logging raw HTTP response bodies from upstream services; prefer status codes + correlation ids.

Description

extensions/bluebubbles/src/inbound-dedupe.ts introduces a new persistent on-disk store (per-account namespace) that writes JSON files under the OpenClaw state directory. The underlying async “atomic” writer (writeTextAtomic/writeJsonAtomic) does not defend against pre-existing symlinks/hardlinks at the destination path.

Impact (local attacker / same-host):

• If an attacker can create/replace ~/.openclaw/bluebubbles/inbound-dedupe/<name>.json (or any parent path component) with a symlink to another file writable by the gateway process, the dedupe commit will write JSON content to the symlink target.
• On Windows, the fallback path explicitly uses copyFile(tempPath, filePath), which will follow a symlink at filePath and overwrite the link target.
• There is no lstat/realpath verification of the final destination prior to the overwrite, and no O_NOFOLLOW style protection.

Vulnerable code (Windows fallback overwrite):

​// src/infra/json-files.ts
await fs.copyFile(tempPath, filePath);

This becomes reachable via BlueBubbles inbound dedupe persistence, which derives a per-account file path and ultimately calls writeJsonAtomic(...) through writeJsonFileAtomically(...).

Recommendation

Harden atomic writes against symlink/hardlink attacks (CWE-59):

• Before replacing the destination, verify the destination path is not a symlink (lstat) and that all parent directories are not symlinks.
• Prefer opening the destination with platform-appropriate no-follow flags (where available) and/or use fs.rename to a path that was created securely.
• On Windows fallback, avoid copyFile to a path that could be a symlink; instead create the destination file securely (e.g., open with exclusive flags) after validating lstat, or remove and recreate the destination only after verifying it is a regular file.

Example (sketch):

import fs from "node:fs/promises";

async function assertNotSymlink(p: string) {
  try {
    const st = await fs.lstat(p);
    if (st.isSymbolicLink()) throw new Error(`Refusing to write through symlink: ${p}`);
  } catch (e: any) {
    if (e?.code !== "ENOENT") throw e;
  }
}

await assertNotSymlink(filePath);
​// then proceed with rename/copy

Additionally, consider resolving resolveStateDirFromEnv() once and ensuring the created state subdirectories have restrictive permissions and are not symlinks.

Description

The inbound-dedupe wrapper logs dedupeKey, message.senderId, and arbitrary error/finalizeError objects after only stripping control characters, without any length truncation.

If an attacker can send authenticated BlueBubbles webhook events (or if the webhook token is leaked), they can supply extremely large strings in fields that flow into these logs (e.g., senderId is taken from the webhook payload in normalizeWebhookMessage() without a maximum length). This can cause:

• Log amplification / disk exhaustion (very large log lines)
• CPU/memory overhead from String(value) on large objects/strings

Vulnerable code (new logging):

function sanitizeForLog(value: unknown): string {
  return String(value).replace(/[\r\n\t\p{C}]/gu, " ");
}
...
`drop: ${claim.kind} inbound key=${sanitizeForLog(dedupeKey ?? "")} sender=${sanitizeForLog(message.senderId)}`
...
`inbound-dedupe: finalize failed for key=${sanitizeForLog(dedupeKey ?? "")}: ${sanitizeForLog(finalizeError)}`

Recommendation

Add size limits when logging values derived from webhook payloads and error objects.

For example, cap log fields to a small, safe maximum (e.g., 200 chars) and consider logging hashes instead of raw identifiers:

function sanitizeForLog(value: unknown, maxLen = 200): string {
  const s = String(value).replace(/[\r\n\t\p{C}]/gu, " ");
  return s.length > maxLen ? s.slice(0, maxLen) + "…" : s;
}

​// Or log hashes for high-entropy IDs
​// const keyHash = createHash("sha256").update(dedupeKey ?? "").digest("hex").slice(0, 12);

Also consider avoiding String(error) on arbitrary objects; prefer formatErrorMessage(err) or a bounded serialization that cannot explode in size.