Description

queuePendingWakeReason() coalesces wake requests by a key derived only from agentId and sessionKey. When multiple wakes for the same key are merged, the code carries forward a previous heartbeat override if the newer wake omits heartbeat.

This can unintentionally apply heartbeat.target: "last" (or any other override) to a later wake of a different reason (e.g., interval/retry), causing heartbeats to be delivered to the last conversation/channel instead of the configured destination.

Impact:

• A wake that was intended to target a safe/expected destination can inherit target:"last" from an earlier wake.
• This can result in unexpected outbound message delivery to a prior chat/recipient, which is an information disclosure risk.

Vulnerable code:

const merged =
  (next.heartbeat ?? previous.heartbeat)
    ? { ...next, heartbeat: next.heartbeat ?? previous.heartbeat }
    : next;

The coalescing key does not include heartbeat fields, so an override can persist across different wake reasons under the same agentId::sessionKey key.

Recommendation

Ensure heartbeat overrides do not unintentionally persist across coalesced wakes.

Options:

1. Scope the coalescing key to heartbeat override (recommended if overrides must not mix):

function getWakeTargetKey(params: { agentId?: string; sessionKey?: string; heartbeatTarget?: string }) {
  const agentId = normalizeWakeTarget(params.agentId);
  const sessionKey = normalizeWakeTarget(params.sessionKey);
  const hbTarget = normalizeOptionalString(params.heartbeatTarget) ?? "";
  return `${agentId ?? ""}::${sessionKey ?? ""}::${hbTarget}`;
}

2. Do not inherit previous.heartbeat when the new wake omits it (treat omitted as “no override”):

​// keep next.heartbeat as-is; do not fall back to previous
pendingWakes.set(wakeTargetKey, next);

3. If inheritance is desired only for retries of the same wake, restrict merging to retry paths (e.g., when reason is retry), or require explicit opt-in.

Also consider normalizing/validating heartbeat.target (allowlist) at intake to prevent unexpected target values from being carried around.

Description

The heartbeat wake path merges a caller-provided heartbeat object into an existing config using object spread.

• params.heartbeat / opts.heartbeat can be influenced by external callers (cron/gateway/runtime callers).
• Using { ...base, ...override } allows special keys like __proto__, constructor, or prototype to mutate the resulting object's prototype.
• This is a classic prototype-pollution sink in JavaScript/TypeScript and can lead to unpredictable behavior (property lookups affected across the app) and potential security impacts depending on subsequent object usage.

Vulnerable code:

const resolveRequestedHeartbeat = (heartbeat?: HeartbeatConfig) =>
  requestedHeartbeat ? { ...heartbeat, ...requestedHeartbeat } : heartbeat;

Recommendation

Harden merges of externally-provided objects:

1. Allowlist expected keys and ignore everything else.
2. Reject dangerous keys (__proto__, prototype, constructor) before merging.

Example:

function sanitizeHeartbeatOverride(input: unknown): { target?: string } | undefined {
  if (!input || typeof input !== "object") return undefined;
  const rec = input as Record<string, unknown>;
  ​// block prototype-pollution keys explicitly
  if ("__proto__" in rec || "constructor" in rec || "prototype" in rec) return undefined;
  const out: { target?: string } = {};
  if (typeof rec.target === "string") out.target = rec.target;
  return out;
}

const safeOverride = sanitizeHeartbeatOverride(params?.heartbeat);
const resolveRequestedHeartbeat = (heartbeat?: HeartbeatConfig) =>
  safeOverride ? { ...heartbeat, ...safeOverride } : heartbeat;

Apply the same pattern anywhere heartbeat overrides are merged (e.g., the gateway cron adapter).

Description

Main-session cron jobs now always wake/execute heartbeats with an override heartbeat: { target: "last" }.

This is risky because heartbeat.target="last" resolves delivery using the session entry’s stored lastChannel/lastTo (see resolveHeartbeatDeliveryTarget → resolveSessionDeliveryTarget), meaning the heartbeat output is sent to whoever last interacted with that shared session.

If the agent’s main session is shared by multiple users/chats (common for a single agent main session), a cron-triggered heartbeat can be delivered to an unintended recipient (the most recent user), leaking:

• cron/heartbeat-produced content
• any workspace/agent state surfaced by the heartbeat prompt
• system-event summaries consumed during the heartbeat run

Vulnerable code (new behavior):

heartbeatResult = await state.deps.runHeartbeatOnce({
  reason,
  agentId: job.agentId,
  sessionKey: targetMainSessionKey,
  heartbeat: { target: "last" },
});
...
state.deps.requestHeartbeatNow({
  reason,
  agentId: job.agentId,
  sessionKey: targetMainSessionKey,
  heartbeat: { target: "last" },
});

Because this override is unconditional for main-session cron jobs, it can also bypass an agent configuration that intentionally sets heartbeat.target: "none" to prevent outbound heartbeat delivery.

Recommendation

Avoid forcing heartbeat.target="last" for cron-triggered heartbeats unless you can guarantee correct recipient scoping.

Options:

1. Respect agent config and only set the override when explicitly configured for that job:

const heartbeatOverride = job.heartbeatTargetOverride
  ? { target: job.heartbeatTargetOverride }
  : undefined;

state.deps.requestHeartbeatNow({ reason, agentId: job.agentId, sessionKey: targetMainSessionKey, heartbeat: heartbeatOverride });

2. Require an explicit, unambiguous delivery context (channel/to/accountId) bound to the cron job, rather than using session "last".

3. If "last" is required, ensure the session model is per-user/per-sender for cron delivery (separate session keys per recipient), and validate the sessionKey belongs to the intended recipient before sending.