Description

In runCronChangedHook, the plugin hook context exposes getCron() which returns the gateway-owned CronService instance cast to PluginHookGatewayCronService.

• This is only a TypeScript cast; at runtime the returned object is the full CronService with additional powerful methods (e.g., run, enqueueRun, wake, status, listPage, getJob, etc.).
• Any plugin registered for the new cron_changed hook can call these methods without passing through the gateway’s normal authorization boundaries, enabling a confused-deputy/privilege-escalation path:
  • modify/add/remove cron jobs globally
  • force-run jobs or wake the system (potentially triggering system events/actions under gateway authority)
  • read cron job metadata/state that may belong to other agents/sessions

Vulnerable code:

const hookCtx: PluginHookGatewayContext = {
  config: getRuntimeConfig(),
  getCron: () => cron as PluginHookGatewayCronService,
};

Recommendation

Do not expose the concrete CronService instance to plugins.

• Return a capability-limited wrapper object that only implements the intended safe surface area, and do not leak the underlying instance.
• Additionally, enforce authorization/scoping (e.g., only allow operations on jobs owned by the calling plugin, or provide read-only access for cron_changed).

Example (capability wrapper):

const cronApi: PluginHookGatewayCronService = {
  list: (opts) => cron.list(opts).then(jobs => jobs.map(toPluginCronJob)),
  add: (input) => { throw new Error("not permitted"); },
  update: (id, patch) => { throw new Error("not permitted"); },
  remove: (id) => { throw new Error("not permitted"); },
};

const hookCtx: PluginHookGatewayContext = {
  config: getRuntimeConfig(),
  getCron: () => cronApi,
};

If mutation must be supported, add explicit policy checks in the wrapper before calling into cron (e.g., verify plugin id, job ownership tags, or a configured allowlist).

Description

The cron_changed plugin hook receives a PluginHookGatewayContext that includes the full runtime configuration object.

• getRuntimeConfig() returns the active runtime OpenClawConfig (loaded from disk/env substitutions)
• This config commonly contains sensitive values (provider API keys/tokens, auth secrets, filesystem paths, etc.)
• Any plugin implementing cron_changed will receive this config on each cron event, expanding the opportunities for exfiltration/misuse of secrets by third-party/untrusted plugins

Vulnerable code:

const hookCtx: PluginHookGatewayContext = {
  config: getRuntimeConfig(),
  getCron: () => cron as PluginHookGatewayCronService,
};
void hookRunner.runCronChanged(evt, hookCtx)

Recommendation

Avoid passing the full runtime config into plugin hooks.

Recommended options:

1. Provide a sanitized/minimal config view intended for plugins (explicit allowlist):

import { toPluginSafeConfig } from "../plugins/config-sanitize.js";

const hookCtx: PluginHookGatewayContext = {
  config: toPluginSafeConfig(getRuntimeConfig()),
  getCron: () => cron as PluginHookGatewayCronService,
};

Where toPluginSafeConfig strips secrets (API keys, tokens, passwords), internal paths, and any values not required by the plugin SDK.

2. Do not include config at all for this hook (or gate behind an explicit exposeConfigToPlugins setting).

Also document clearly in the plugin SDK whether hooks can access secrets, and treat any plugin that receives secrets as fully trusted.

Description

cron_changed hook events expose an internal CronJob snapshot to plugins. toPluginCronJob() attempts to map the internal type to the public plugin SDK shape, but it uses structuredClone(job.payload) (and structuredClone(job.schedule)) without filtering keys.

Because CronJob.payload is a union that can include agentTurn payloads with additional internal/sensitive fields (e.g. model, fallbacks, toolsAllow, allowUnsafeExternalContent, and externalContentSource provenance), any extra properties present at runtime will be preserved and become readable by plugins even though PluginHookGatewayCronJob.payload is typed as only { kind, text }.

This is an information disclosure risk when plugins are untrusted or have weaker trust boundaries than the core gateway.

Vulnerable code:

payload: job.payload ? structuredClone(job.payload) : undefined,

Relevant internal payload shape includes additional fields beyond {kind,text}:

export type CronPayload = { kind: "systemEvent"; text: string } | CronAgentTurnPayload;
​// CronAgentTurnPayloadFields includes model/fallbacks/toolsAllow/externalContentSource/etc.

Recommendation

Do not clone and forward the internal payload verbatim. Instead, explicitly construct the public payload shape and drop/deny-list internal fields.

Example (allow only systemEvent payload):

function toPluginCronPayload(payload: CronPayload | undefined): { kind: string; text?: string } | undefined {
  if (!payload) return undefined;
  if (payload.kind === "systemEvent") {
    return { kind: payload.kind, text: payload.text };
  }
  ​// For agentTurn or other internal kinds, either omit entirely or provide a redacted summary
  return { kind: payload.kind };
}

function toPluginCronJob(job: CronJob): PluginHookGatewayCronJob {
  return {
    id: job.id,
    ​// ...
    payload: toPluginCronPayload(job.payload),
  };
}

If some agentTurn fields are intended to be public, define a separate public payload type and whitelist only those keys. Add tests to ensure extra keys (e.g. externalContentSource, toolsAllow) are not present in emitted plugin events.

Description

CronEvent now optionally includes a full job snapshot, and the gateway broadcasts the raw event object to all websocket subscribers.

• CronEvent.job is set to the full internal CronJob object at multiple emit sites.
• The gateway’s onEvent handler immediately does params.broadcast("cron", evt, ...) with no redaction.
• CronJob contains potentially sensitive fields such as:
  • payload (e.g., agent-turn message, which may include secrets/prompts or external content provenance)
  • delivery.to (for webhook mode this may be a URL and can embed credentials/tokens)
  • failureAlert destinations
  • sessionKey / agentId (internal routing identifiers)

This creates a risk of information disclosure to any connected/authorized UI clients (and any other consumers of the gateway broadcast channel) that were previously only receiving the smaller CronEvent without job contents.

Vulnerable code:

onEvent: (evt) => {
  params.broadcast("cron", evt, { dropIfSlow: true });
  ​// ...
}

Recommendation

Do not broadcast the internal CronEvent directly once it contains a CronJob snapshot.

Options:

1. Broadcast a sanitized/public shape (recommended), similar to the plugin hook mapping, and explicitly omit/redact sensitive subtrees (payload, delivery, failureAlert, externalContentSource, etc.):

onEvent: (evt) => {
  const publicEvt = {
    action: evt.action,
    jobId: evt.jobId,
    ​// include only minimal safe fields
    ...(evt.job ? { job: { id: evt.job.id, name: evt.job.name, enabled: evt.job.enabled } } : {}),
    runAtMs: evt.runAtMs,
    durationMs: evt.durationMs,
    status: evt.status,
    summary: evt.summary,
    nextRunAtMs: evt.nextRunAtMs,
  };
  params.broadcast("cron", publicEvt, { dropIfSlow: true });
};

2. If job details must be available to the UI, gate them behind an explicit authorization check and/or send them only to specific connection IDs that are authorized to view cron job payload/delivery details.

Also consider adding a unit test asserting that cron broadcast payload never includes payload/delivery/failureAlert (or other sensitive keys).

Description

The gateway fires cron_changed plugin hooks in a fire-and-forget manner without any backpressure or concurrency limit.

• Every cron event calls runCronChangedHook() which starts hookRunner.runCronChanged(...) but does not await it.
• runCronChanged() delegates to runVoidHook(), which executes all handlers and only resolves once all handlers complete.
• There is no default timeout for cron_changed (timeouts are only configured for agent_end by default), so a slow/hung plugin hook can keep the Promise pending indefinitely.
• If cron events occur frequently (many jobs, frequent ticks) this can create an unbounded number of in-flight hook executions, leading to memory/CPU growth and potential gateway instability (DoS).

Vulnerable code:

void hookRunner.runCronChanged(evt, hookCtx).catch((err) => {
  cronLogger.warn({ err: formatErrorMessage(err), jobId: evt.jobId }, "cron_changed hook failed");
});

Recommendation

Add backpressure for cron_changed hook execution, and enforce a timeout.

Options (choose one):

1. Queue with bounded concurrency (recommended):

import pLimit from "p-limit";
const limit = pLimit(1); // or small N

const runCronChangedHook = (evt: PluginHookCronChangedEvent) => {
  const hookRunner = getGlobalHookRunner();
  if (!hookRunner?.hasHooks("cron_changed")) return;

  const hookCtx: PluginHookGatewayContext = {
    config: getRuntimeConfig(),
    getCron: () => cron as PluginHookGatewayCronService,
  };

  void limit(() => hookRunner.runCronChanged(evt, hookCtx))
    .catch((err) => cronLogger.warn({ err: formatErrorMessage(err), jobId: evt.jobId }, "cron_changed hook failed"));
};

2. Configure a default timeout for cron_changed in DEFAULT_VOID_HOOK_TIMEOUT_MS_BY_HOOK (still consider concurrency limiting):

const DEFAULT_VOID_HOOK_TIMEOUT_MS_BY_HOOK = {
  agent_end: 30_000,
  cron_changed: 5_000,
};

This prevents unbounded buildup of pending promises when hooks are slow or never resolve.