CVE feed is stale (amber strip on the Security tab)

An amber strip at the top of the admin Security tab says the CVE feed hasn't refreshed in over 6 hours. Almost always a transient network reach issue to one of three upstream feeds.

Last updated 20 days ago

CVE feed is stale (amber strip on the Security tab)

What you're seeing

You open Addons → ImpulseCore → Security and there's an amber warning strip at the top:

CVE feed hasn't refreshed in the last 6 hours.
The Security tab still renders — existing snapshots and known CVEs are intact — but new CVEs from upstream haven't been ingested for hours.

Why it happens

Core pulls from three upstream CVE feeds:

  • Ubuntu USN — hourly, OS-level CVEs (kernel, OpenSSL, glibc, OpenSSH).
  • CISA KEV — hourly, actively-exploited cross-reference.
  • NVD by CPE — daily, direct-install products declared in module manifests (Postgres, MinIO, etc.).

The amber strip appears when cve_feed_refresh (the hourly task) hasn't completed in over 6 hours. The runner is invoking the task, but the task's handler is erroring because at least one of the upstream feeds is unreachable. Each failed refresh writes an audit entry naming the specific upstream.

Fix

  1. Find which upstream is failing. Open Addons → ImpulseCore → Audit. Filter to action cve_feed.refresh_failed. The context JSON in the most recent entry names which feed (usn, kev, or nvd) and includes the exception message — usually a connection timeout, DNS failure, or HTTP error code.
  2. Test connectivity from the WHMCS server. From the same host that runs the cron, hit the failing upstream directly. Examples: 
    curl -I https://ubuntu.com/security/notices.json curl -I https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json curl -I https://services.nvd.nist.gov/rest/json/cves/2.0
    A 200 OK means the feed is reachable from this host. A timeout, refused connection, or DNS error tells you the egress path is broken.
  3. If egress is blocked, fix the firewall. Hosting providers sometimes restrict outbound HTTPS. Whitelist the upstream hosts in whatever egress firewall sits between the WHMCS server and the internet. The three hosts the feed uses are ubuntu.com, cisa.gov, and services.nvd.nist.gov.
  4. If it's transient, force a refresh. Once you've confirmed the upstream is reachable again, don't wait for the next hourly tick. Run the refresh synchronously: 
    /opt/plesk/php/8.3/bin/php \ /path/to/whmcs/modules/addons/impulsecore/cron.php \ --task=cve_feed_refresh
    Replace /opt/plesk/php/8.3/bin/php with your PHP CLI binary. On Plesk: /opt/plesk/php/8.3/bin/php. On cPanel: /opt/cpanel/ea-php83/root/usr/bin/php. On a vanilla LAMP install: /usr/bin/php or whatever which php returns. Or stamp the task to run on the next 5-minute walker tick: 
    UPDATE mod_impulsecore_cron_tasks SET next_run_at = NOW() WHERE name = 'cve_feed_refresh';

How to confirm it worked

Refresh the Security tab. The amber strip disappears as soon as a successful refresh lands. The audit log shows a new cve_feed.refresh_completed entry with severity info and the count of entries pulled.

When the strip persists

If the strip stays amber for more than a couple of hours after the upstream is reachable again, run the task by hand to capture full stderr. A persistent failure pointing at a specific upstream usually means an API-side change (a feed URL moved, an auth requirement was added) rather than a network issue — those need a Core update to handle.

Related