AskNewsOctober 14, 2026

Automate Daily CVE Monitoring with OpenClaw and the AskNews CLI

A useful daily CVE (Common Vulnerabilities and Exposures) report answers one narrow question: does anything reported in the last 24 hours affect software we actually run?

Answering it by hand means reading a dozen advisories, deciding which ones deserve a second look, and then grepping lockfiles to see whether you even ship the affected package. That is work an agent can do every morning, as long as it is bounded, read-only, and honest about what it did not verify.

This post walks through one scheduled OpenClaw agent turn that does exactly that, using the AskNews CLI for time-bounded discovery. The agent decides which follow-up searches to run; you decide what to patch.

What the sweep does

Three stages of the sweep: broad 24-hour AskNews discovery with agent-chosen follow-ups, read-only repository correlation, and evidence-backed verdicts for human remediation. — Three stages of the sweep: a broad 24-hour discovery pass with dynamic follow-ups, a read-only repository correlation, and one verdict per candidate, handed to a human for remediation.

Discover. The agent opens one 24-hour UTC window and runs a few broad searches against AskNews news coverage: critical vulnerabilities, active exploitation, patches for widely used libraries and frameworks. It pulls CVE IDs, affected versions, and sources out of the structured results.
Follow up. For each candidate that could plausibly touch your stack, the agent decides its own next queries: what the advisory says, whether exploitation or a proof of concept has been reported, what the fix is. It adds a time-bounded X search to catch early researcher chatter, and labels everything from that layer as unverified.
Correlate. In a separate read-only step, the agent searches lockfiles in the connected repositories for the affected package and compares pinned versions with the advisory's affected range.
Report. One verdict per candidate — affected, not affected, or uncertain — with the evidence behind it, what was not verified, and one human next step. The job never installs, upgrades, or edits anything.

The agent is not executing a fixed list of queries you wrote. It runs a broad pass, notices what matters, and iterates. Your job is to give it a tight prompt, a bounded window, and read-only access.

Install and verify the AskNews CLI

Install the AskNews CLI with the hosted installer or from npm, then authenticate once. For a scheduled job, provide ASKNEWS_API_KEY through your platform's secret store rather than on the command line.

curl -fsSL https://docs.asknews.app/cli/install | bash # or: npm install --global @emergentmethods/asknews-cli asknews auth login # interactive; or export ASKNEWS_API_KEY in CI asknews auth status --offline --output json

A quick smoke test runs a 24-hour, time-bounded search. ISO 8601 UTC bounds give you a reproducible window; --time-filter pub_date keys the window to publication time rather than crawl time:

asknews news search "critical vulnerability actively exploited patch" \ --start-datetime 2026-10-13T07:00:00Z \ --end-datetime 2026-10-14T07:00:00Z \ --time-filter pub_date \ --limit 10 \ --output json

The JSON carries publication dates, source names, article URLs, and summaries. Keep CVE IDs and affected-version strings exactly as written; the agent uses them to build its follow-up queries and to grep lockfiles.

Schedule the OpenClaw turn

One cron job, one isolated session, a restricted tool allowlist, and a destination for the report. This example is verified against the openclaw cron add options in OpenClaw 2026.9.4; the job was not created on a live gateway for this post. Replace the placeholders with values from your installation:

SWEEP_PROMPT='Run a read-only CVE sweep for the previous 24 hours (UTC). Use the AskNews CLI: start with broad time-bounded news searches, then run whatever targeted news and X follow-ups you need on candidates that could affect our stack (advisory details, exploitation or PoC reports, fixed versions). Treat X results as unverified unless an advisory or vendor confirms them. In a separate step, search lockfiles in the connected repositories for the affected packages and compare pinned versions with the affected range. Report one verdict per candidate (affected / not affected / uncertain) with evidence, what you could not verify, and one human next step. Never install, upgrade, or edit anything.' openclaw cron add \ --name "Daily CVE sweep" \ --agent <AGENT_ID> \ --cron "0 7 * * *" \ --tz UTC \ --session isolated \ --tools "exec,read" \ --message "$SWEEP_PROMPT" \ --announce \ --channel discord \ --to "channel:<DISCORD_CHANNEL_ID>"

--session isolated keeps unrelated conversation history out of the run. --tools restricts tool names; because exec is allowed, the real guardrails are the agent's read-only filesystem, read-only repository credentials, and an exec policy that denies package installation. --announce delivers the final report to the chat target; see the OpenClaw cron docs for other providers.

A real example: CVE-2026-94545

To show what the agent actually does, here is a candidate that surfaced in a 24-hour window from September 2026 — not today's news, but a well-documented case worth studying. All details below come from the primary advisories and the search results cited; nothing is inferred beyond them.

The broad sweep. For the window 2026-09-23 00:00 to 2026-09-24 00:00 UTC, one of the agent's broad phrasings returned ten results: an actively exploited WordPress flaw, an Ubuntu kernel container escape, SolarWinds and Arista VeloCloud advisories, and — from a crypto-industry outlet, not a security vendor — "Critical Next.js RCE Vulnerability Patched in Version 16.3.6."

asknews news search "critical vulnerability patch released actively exploited" \ --start-datetime 2026-09-23T00:00:00Z \ --end-datetime 2026-09-24T00:00:00Z \ --limit 10 \ --output json

Noticing the candidate. Most of those are products or platforms with no lockfile signal at all. next is the kind of package that does show up in a package-lock.json, so an agent connected to a Next.js repository would prioritise that one and pull the CVE ID (CVE-2026-94545) out of the summary.

Targeted follow-ups. The agent then searched for the advisory's specifics, pinning the CVE ID with --string-guarantee so the results stay on topic, and widened the window to a week to catch later coverage:

asknews news search "Next.js ImageResponse remote code execution affected versions fix" \ --string-guarantee CVE-2026-94545 \ --start-datetime 2026-09-22T00:00:00Z \ --end-datetime 2026-10-01T00:00:00Z \ --limit 10 \ --output json

Coverage converged on the facts in the primary advisories, which the agent should cite directly:

GHSA-vcvr-r3jv-pc5j (Next.js): remote code execution in next/og ImageResponse when attacker-controlled values reach the generated SVG on the Node.js runtime. Severity critical, CVSS 4.0 9.5. Affected: next >= 16.2.0, < 16.3.6. Fixed in 16.3.6, released 2026-09-22. Versions before 16.2.0 are outside the affected range, and the Edge ImageResponse implementation is not affected.
GHSA-wx4j-mvgx-mqwp (Satori, the underlying renderer): the same CVE, affecting satori >= 0.0.27, < 0.33.5, fixed in 0.33.5. The NVD record carries the library-level CVSS 4.0 score of 5.3 (medium), with a note that impact depends on how the SVG is consumed.

That gap — 9.5 for the framework, 5.3 for the library — is exactly the kind of thing a human reviewer needs to see written down rather than averaged away.

The social layer. A time-bounded X search for the same window shows how the story moved before and after the news coverage:

asknews x '(CVE-2026-94545 OR GHSA-vcvr-r3jv-pc5j) -filter:replies' \ --start-datetime 2026-09-22T00:00:00Z \ --end-datetime 2026-10-01T00:00:00Z \ --output json

On 22 September the reporting researcher announced the finding; on 23 September security news accounts and vendors amplified it; on 29–30 September several accounts, including the researcher's, posted that a public proof of concept was available. News coverage in the window said no confirmed public exploit existed as of 23 September, and CVE-2026-94545 was not in CISA's Known Exploited Vulnerabilities catalog as of 13 October 2026. The agent's report should say precisely that: PoC claimed on X from 29 September, unverified by vendor advisory or KEV; treat as "exploit likely available" and raise patch priority — not "actively exploited."

Correlating with lockfiles. The agent greps for the package in the connected repositories and compares pinned versions to the affected range:

grep -rn --include=package-lock.json '"node_modules/next"' -A 2 . | grep '"version"'

A pin inside 16.2.0–16.3.5 is a candidate match, not a proven exposure. Reachability still depends on whether the app uses ImageResponse with attacker-influenced input and whether it runs on the Node.js or Edge runtime. The agent can check the first with a read-only search for next/og imports; it should report the second as something a human confirms.

What the report looks like

Generic daily security sweep report showing an uncertain verdict with a verification step and a not-affected verdict with continued monitoring.

For the example above, an honest entry would read like this (the repository, file paths, and pinned version are illustrative, not a real exposure):

CVE-2026-94545 — Next.js ImageResponse RCE — verdict: uncertain.Evidence: [email protected] pinned in web/package-lock.json; affected range >=16.2.0 <16.3.6 per GHSA-vcvr-r3jv-pc5j; fix 16.3.6 available since 2026-09-22. next/og imported in app/api/og/route.ts.Not verified: whether request parameters reach ImageResponse unescaped; runtime (Node.js vs Edge) for that route.Social signal: public PoC claimed on X 29–30 Sep (unverified); not in CISA KEV as of run date.Next step: owner of web/ confirms runtime and input handling, then upgrades to >=16.3.6.

Three habits keep the report trustworthy:

Separate the layers. Vendor advisory, NVD, and KEV are authoritative. News coverage is secondary. X posts are signal, never evidence. Say which layer each claim came from.
Separate matching from exploitability. A lockfile hit says you ship the package. It does not say the vulnerable code path is reachable. Report both, and let a human close the gap.
Report what you did not do. Which repositories were not connected, which searches returned nothing, where the window was widened. Silence reads as "all clear"; it should not.

Run it tomorrow

Install the CLI, add the cron job, and read the first report with a sceptical eye. If it says "uncertain" more often than you'd like, that is the point: the sweep's job is to narrow the morning's question to the few items that actually need a human, and to show its work.