CaptainCore
GitHub
Docs Manager

Security

Fleet vulnerabilities, checksum failures, audit coverage, core-update runs and stored site audits.

Security and Site Audits are two operator-only items in the sidebar’s Operate group. Security is the fleet view. Site Audits holds stored reports for individual sites.

Security tabs

The Security screen has four tabs, in this order:

  1. Vulnerabilities
  2. Checksums
  3. Coverage
  4. Core

Each is deep-linkable, for example /account/security/coverage. The first three load together the first time you open the screen; Core loads on demand.

Vulnerabilities

This tab lists known vulnerabilities that are actually present in your fleet.

The data comes from WP Registry. The Manager pulls the latest critical and high findings, then matches them against each active site’s installed plugins and themes by slug and version, counting any install at or below the flagged version. Findings with no fleet exposure are dropped, so the tab stays focused on what you can act on rather than registry noise about code you do not run.

A threat row

Each row reads, left to right: a severity chip (Critical, High, Medium or Low), the component name, an identifier which is the CVE where one exists and the registry finding code otherwise, the affected site count, a Patch available chip when a patch exists, and a status chip.

The four statuses are New, Investigating, Reported and Resolved. A threat with no tracking record yet reads New.

Working a threat

Click a row to expand it. You get the finding titles, a Recommendation: line, and an Affected: list of every site running the vulnerable build, each clickable straight into that site.

Below that are the notes. Add one with the Add note… field and the Add note button. Adding a note on an untracked threat also moves it to Investigating.

The action row offers:

  • Open in terminal (targets prefilled), which opens the terminal dock with every affected environment already selected. This is how you act on all affected sites at once.
  • Download patch, when a patch is available.
  • Mark investigating
  • Mark resolved

Marking a threat resolved also writes an entry on the timeline of every affected site, so the work is recorded where the site’s history lives.

Checksums

The Checksums tab has two sections, both built from data the CLI collects on sync.

Core checksum failures

Every environment whose WordPress core checksum verification failed. Each row is titled by the environment’s home URL rather than the site name, so a production row and a staging row are distinguishable, and carries a Production or Staging chip. Two pills follow: a count of modified core files and a count of extra and missing files together.

Copy SSH copies a ready-to-paste SSH command for that environment. Repair core files opens the terminal dock so you can do the repair yourself; there is no automated repair.

Click a row to expand it into a list of every affected file, each suffixed with whether it is modified, missing or extra.

Plugin checksum failures

Environments where wp plugin verify-checksums found files that do not match what wordpress.org published, sorted by the number of modified files. Each row shows the home URL, the environment chip, the affected slugs and up to four file chips.

Click a row to expand it into the full list of modified files, each shown as slug/file — changed.

Core checksum failures on production trigger a one-time email alert. Plugin checksum alerts are deliberately not emailed, because operator-customized plugins (for example PHP 8 compatibility patches on abandoned plugins) show up here and the fleet is reviewed from this tab instead.

Coverage

Coverage measures how much of the code your fleet runs has been audited, counted in unique content hashes.

For every active production environment the Manager collects the content hash of each active plugin, active theme, must-use plugin and loose file, dedupes them fleet-wide, and asks WP Registry which of those hashes carry an audit. Coverage is audited unique hashes over total unique hashes.

Four tiles read:

  • Fleet coverage as a percentage, turning amber below 80
  • Audited builds as 12,401 / 13,720
  • Unaudited, amber when non-zero
  • Sites, the count of active production environments

Below that, Coverage by component type draws a percentage bar for Plugins, Themes, Must-use and Files. Bars are green at 80 percent and above, amber at 50 and above, red below.

A footer note counts components that have no content hash yet, which normally means the site needs a sync.

The heavy job that builds the “update before audit” queue behind this work runs from cron. See wp captaincore update-queue in WP-CLI commands.

Core

The Core tab holds fleet core-update probe and apply runs. Each run is stored as a parent row plus one result row per site, recording the core versions before and after, the stage that failed, an error class and a triage status.

Runs are produced by the CaptainCore CLI and pushed into the Manager, not started from this screen. Until the first one arrives the tab reads “No core probe runs yet. Fleet probe results land here after update-core finishes.”

A dropdown at the top picks the run, with a Search runs… box. Each option names the run’s time, target, version and failure count.

Four tiles read Sites, Passed, Failed and Version, and a meta line carries the requested version, the version it resolved to when they differ, the run duration and the time it started.

Below that is Failure groups, one row per error class with its site count. The error classes cover a widget factory failure, a PHP fatal, a named parameter error, a signature mismatch, an undefined constant, CLI memory, not a WordPress root, an HTTP probe failure, boot, render, a theme path problem, a version check and SSH, with an “Other” fallback.

Expanding a group lists each failing site with the reason, its environment and stage chips, the core versions before and after, and a Resolve button. Clicking the row opens the site.

Per-result triage statuses are open, triaged, resolved and ignored. The same data is queryable from the shell with wp captaincore core-update-runs.

Site Audits

Site Audits is its own sidebar item at /account/site-audits. It lists stored audit reports for individual sites.

A toolbar at the top holds a site picker with a Search sites… box, a row of type chips, and a Request audit button.

Each row shows the site, its environment and report type, the date, a findings summary reading 3 open · 12 resolved, a status chip, and the actions View, Publish or Unpublish, Copy link when published, and Cancel while an audit is still queued.

Statuses are Queued, Running, Clean, Issues found, Compromised and Remediated. A published audit shows as Published.

Report types are Security, Malware, Performance, Accessibility, Debug and Incident.

What an audit record holds

An audit carries the site and environment, the WordPress and PHP versions, an issues count, a plugin count, a set of scan checks, the site configuration, the administrator accounts, timeline events, dashboard metrics, a summary, and arbitrary custom sections with their own ordering.

Findings live alongside it, each with a severity of critical, high, medium or low, a status of open or resolved, a title, a description, evidence, a recommendation and a resolution. Resolving the last open finding flips the audit to Remediated automatically. Findings are created over the REST API rather than edited in this screen.

Publishing

Publish renders the audit into a standalone HTML report and writes it into the webroot under a filename that carries a random token, so the URL is a capability rather than something anyone can guess. Re-publishing mints a new filename and deletes the previous file. Unpublish deletes it.

The published report opens with a dashboard of tiles, a summary callout, then Scan Results covering filesystem integrity, malware signatures, frontend analysis, database scan, logs and user accounts, then Issues Found with severity-tagged finding cards and their evidence, then Administrator Accounts, Site Configuration and Attack Timeline, plus any custom sections, with a generated left-hand navigation.

Audits are most often created over the REST API by an agent or a script rather than requested here.

Other security work

Several security features run on a schedule rather than in the interface:

  • Session monitoring takes daily snapshots of admin accounts, sessions and injected capabilities per environment and alerts on the delta rather than the absolute state. wp captaincore session-alerts emails the digest.
  • Google Web Risk checks run every production home URL against Google’s Web Risk API and email a summary. wp captaincore web-risk-check.
  • Scan and component queues rank which sites and which unique component builds most need auditing. wp captaincore scan-queue and wp captaincore component-queue.
  • Security patches come from WP Registry’s patch manifest and surface here as the Patch available chip and the Download patch link.
  • Integrity alerts fire by email when core or plugin checksums fail, malware is detected, visual captures change unexpectedly, or a site’s default role is unsafe.

Per-site audit coverage lives on the site page’s Registry tab. See Site detail.