Changelog

September 19, 2026 · View on GitHub

Unreleased

Added

Malware findings are stored for a daily review; only proven classes email at once. Every finding the CLI reports now lands in the findings table with its severity and family, whatever the severity. MalwareFindings::should_email names the tier-1 classes that email the moment they are first seen: hash indicators, critical and high file-rule findings from the quicksave scanners, a plugin that hides itself, a PHP file a wordpress.org plugin never shipped, a trigger or event on a core table. Everything else (modified vendor files, the database scan, security-plugin changes, all mediums and lows) waits for the review. New columns hold the verdict (compromise, residue, benign, needs-human), its reason and who gave it; benign resolves the finding. GET /captaincore/v1/malware-findings lists open findings without a verdict and POST /captaincore/v1/malware-findings/{id}/verdict records one (both admin-gated); wp captaincore malware-findings --unreviewed and --verdict=<v> --reason=<text> --id=<id> do the same from the shell. Database version 54.
Malware alert emails render database findings. The CLI's database scan reports locations like db:post/116 or db:option/widget_text; the email now shows them as "Post 116" or "Option widget_text" under a Location column, and opens with "A database scan has found injected content" when the alert's source is the database scan, instead of the quicksave file wording.
Malware findings are recorded, not just emailed. Every finding the CLI reports (nightly quicksave scans, full-tree scans, hidden-plugin and media checks) lands in a findings table keyed by site, environment, path and signature. A finding already open updates its last-seen time and count instead of sending the same alert again, a resolved finding that comes back reopens and alerts, and only new findings appear in the email. wp captaincore malware-findings [<site>] [--status=open|resolved|all] [--resolve [--id=<id>]] [--format=table|json|csv|count] lists and resolves them; resolving after a cleanup is what re-arms the alert.

Improved

A managed update can be started from any site, whether or not the dashboard counts updates as pending. "Run managed update" is the first entry in the site's Tools card, and the Inventory tab's button is always present, reading "Update all (N)" when the update queue knows of pending targets and "Run managed update" otherwise. Both confirm first, say how many components the environment excludes, and run the same update the legacy "Manual update" button did, with quicksaves before and after.
Update exclusions are visible and editable where the plugins are. A plugin or theme excluded from managed updates on an environment wears an "Excluded" pill in the Inventory list, the tab reports how many are excluded, and right-clicking a row offers "Exclude from managed updates" or "Include in managed updates" without opening the settings dialog. "Update settings…" now also sits in the Inventory tab and the Tools card, the Environment card reads "On · N excluded", and the dialog explains what clicking a name does, counts exclusions per kind, and no longer lists must-use plugins or drop-ins.

Fixed

Deleting a site removes everything that belonged to it. The delete only ever removed the site row, so its environments, account links, captures, session snapshots and per-environment scripts stayed behind as rows with no site. A delete now clears all of those in the same pass. Snapshots, audits and timeline entries are kept on purpose, since a customer or operator may still open them (a final snapshot's download link resolves through its row). wp captaincore orphan-rows reports the rows earlier deletes left behind and --delete --limit=N removes them in batches.
Backups, versions, snapshots and timeline entries always show their year. A backup from two years ago read the same as one from last week, "Sep 15, 12:21 AM", so restoring or downloading the wrong year was easy from a long list. Every date in those lists now reads like "Sep 15, 2026 · 12:21 AM".
Snapshot downloads work again. The dashboard's Download link and Copy link both pointed at a URL ending in ".zip", which matched no route, so every download answered "No route was found matching the URL and request method" instead of the archive. The download endpoint now accepts the file name with or without the extension, which is also what the emailed link and the legacy dashboard have always sent.
A snapshot's countdown is no longer off by the viewer's time zone. Expiry is stored in UTC but was being read as local time, so a fresh 24 hour link read as 27 hours in New York and 21 hours in Berlin, where a live link could be shown as already expired.
An expired snapshot offers "New 24h link" alone. Its Download link was still shown and could only ever fail.
A snapshot whose archive the storage server cannot produce now says so. The dashboard used to send the browser to a page built from the error text.
An email forward can be edited again. The Email forwarding tab could add or delete an alias but had no way to change one, so fixing a typo or adding a recipient meant deleting the alias and recreating it. Each forward now has an Edit link that opens the alias and its recipients in place, with Save and Cancel, and Delete asks first.
After Mailgun sending is set up, the Sending tab loads DNS records, usage, and events immediately. The zone used to be created while the panel stayed empty until you left the tab and came back.
A first payment no longer fails for want of a billing address. Adding a card asks for the billing details the charge needs — name, address, city, state, ZIP, country and email — showing them as a summary once they are on file and as a form until then, with searchable country and state pickers. The address is saved before the card is created and travels with it to Stripe. Paying an invoice with a saved card asks for the same details first, the Billing address screen marks what is required, and the API refuses a card with an incomplete address instead of returning a bare gateway error.
A dashboard tab left open for more than half a day no longer fails silently. The REST nonce is refreshed in the background every 30 minutes and whenever the tab returns to the foreground, and a request that still hits an expired nonce fetches a fresh one and replays itself. When the login session itself has ended, the tab goes to the login page and returns to the same screen after sign-in.

The pairing release. Connecting a CaptainCore CLI server to the Manager is now one command in each direction at once: captaincore connect --server-url=... fetches the CLI token and registers the CLI server's address with the Manager in the same request, so a fresh install needs no wp-config.php constant. The release also carries the second security sweep that ran after 1.1.0 shipped: fourteen fixes, most of them closing checks that failed open or that one entry point applied and another skipped.

Added

The CLI server address no longer has to live in wp-config.php. captaincore connect --server-url=https://... on the CLI server registers the address with the Manager over the same administrator-authenticated request that hands the CLI its token, so one command pairs both directions. The value is stored in the global configurations, shown and editable under Settings, Branding, as "CLI server", and read through a new captaincore_cli_address() helper that every dispatch call and the websocket address now use. A CAPTAINCORE_CLI_ADDRESS constant still wins when defined, so existing installs keep working unchanged; the Settings field says so when that is the case. Only an administrator-authenticated connect can change the address; a token-authenticated --sync cannot redirect dispatch.

Security

The brute-force throttle and the new-location step-up now apply to wp-login.php and XML-RPC, not only to the dashboard's login endpoint. A user without two-factor authentication could previously be signed in from anywhere, with unlimited attempts, by posting to wp-login.php. The location check runs after core verifies the password so it cannot be used to trigger verification mail for arbitrary usernames; application passwords are exempt by design.
Minting an application password through the dashboard now honours WordPress's application-password availability settings and the create_app_password capability. Being logged in was the only requirement before, so disabling application passwords had no effect and a user could re-enable them for themselves in one request.
The legacy dashboard shell requires a login. It rendered for anyone who asked for ?ui=legacy, and although every data call gated itself, the boot payload handed an anonymous visitor the CLI dispatch address and the object-storage base URI. The invite, welcome and connect flows keep their logged-out shell with those values emptied.
Three fail-open gaps in the authorization core are closed: the Users model's constructor expressed its administrator check as a discarded return value and so listed every WordPress user's name, email, login and roles to any caller that reached it; an unrecognised account tier resolved to full access instead of none; and an account's provisioning template and outstanding invoices were emitted untiered.
Report and scheduled-report handlers fail closed when site_ids is not an array. A string slipped past a hand-rolled ownership loop and could resolve another account's billing contact. Reading that address now also respects the account plan tier, matching the account view.
Scheduling an account-wide report respects the sites and timeline tiers, so a domains-only or sites-only member can no longer receive on a schedule what their tier withholds.
Saving account site defaults checks recipe access before storing recipe ids. It was the one of three recipe-running doors without the check, and it let another user's private recipe run on a host the caller picked. All three doors now share one permission helper.
Request values can no longer occupy argument positions on CLI commands. A body or query field of the same name outranked the URL segment, and where the value reached a legacy command string the dispatch server re-tokenized it into extra arguments on a fleet-privileged process. Backups, backup retrieval, log archive and the Mailgun deploy command move to the argv form the CLI server executes verbatim; quicksave hashes come from the URL only and must start alphanumeric; recipe ids are cast to integers before the ownership check rather than after.
New site creation verifies the customer account a site is linked to. It was the one ownership-bearing field on that request never checked, and because site invites honour that link, it chained into cross-tenant account membership. Inviting your own address into an account is rejected as well.
Outbound TLS verification is no longer switched off by the debug constant on the component-inventory calls, the updater's package download, or configuration sync, which had relaxed verification globally for the rest of the request. The updater's info path now applies the same host and hash checks as its update path. A Kinsta provider row the caller may not use is refused outright instead of falling through to the house API key.
Values that reach a permission decision or a regular expression are validated: an account's billing user must be a member of that account; the login endpoint compares its command strictly so a JSON true no longer matches every branch; provider slugs are whitelisted on create as they already were on update; and version filters are escaped as regex literals, which also stops a version like 6.76 matching 6x76.
Customer-set values are escaped before they become markup in staff notification email, in the configurations tab (a product title containing an apostrophe could end the attribute early), and in the DNS result banner.
The bundled Parsedown is updated to 1.8.0 with safe mode on, so raw HTML in customer-supplied Markdown is escaped by the parser as well as by kses. The shipped API docs opt out explicitly.
A permission helper that returned a count rather than a boolean, and so was true for a bare subscriber at eight endpoints, is renamed to say what it tests. Every endpoint turned out to be protected by per-row scoping, so there was no live gap, but the next caller would have inherited a false gate.

v1.1.0 - September 4, 2026

The security and scale release. Two audits ran against this cycle: the sweep that followed 1.0.0, which went over every REST route and both authorization primitives, and a second pass over the release candidate that found site provisioning trusting fields it had accepted from the browser. Both are fixed here. Alongside that, the dashboard picked up the parts of the legacy interface it was still missing, from domain registrar and account assignment to per account site defaults and renewal estimates, and an account with a large footprint opens in under a second instead of a minute.

Added

The account named in a site's header opens that account. It was plain text, so reaching the account meant going back to the Accounts list and finding it again.
Mailgun sending can be set up on a subdomain other than mg. The setup row now takes the label, defaulted to mg, with the domain shown after it, and the line above follows what is typed. The legacy dashboard asked for this and the rebuild had fixed it to mg. It matters because Mailgun sending domains are unique across the whole platform, so when mg for a domain is already registered to an account we do not hold, another label is the way through.
Operators can turn a site's uptime monitor on or off from the Environment card on the site page, as the legacy dashboard allowed. The change is administrator-only on the server as well, and is recorded on the site's activity log. The Uptime monitor and Managed updates rows are now shown to operators only.
A Help & shortcuts guide: the question-mark button in the top bar (or "Help & shortcuts" in the command palette) explains what ⌘K searches, how the terminal dock works, where right-click menus live, and lists every keyboard shortcut. Commands now list ahead of sites and domains in palette results once you start typing.
Fleet core-update probe/apply runs are stored as a parent run plus per-site rows (core versions before and after, stage, error class, triage status) so agents can group failures. Email stays a short recap.
New site supports multiple Kinsta connections: agencies with their own Kinsta company can pick which provider a new site is created on, and the clone list only offers sites from that same connection (Kinsta cannot clone across companies).
Pay invoices right on the invoice: open invoices now show a payment section listing your saved payment methods with the default preselected, a Pay button for the chosen method, a "Pay with a new card" option that saves the card and pays in one step, and a Remove action on each saved method.
Per-account site defaults: each account now has a Site defaults tab where administrators and full-access members set the default email, timezone, recipes and users applied to that account's new sites. Lower access tiers can no longer write defaults through the API.
Domain account assignment is back: operators can assign a domain to accounts or unassign one straight from the domain screen, matching the legacy Edit Domain dialog.
Operators can set where a domain is registered from the Registrar tab: an Edit link on the Registrar row picks one of the registrar connections (Hover.com, Spaceship) or marks the domain as registered externally, completing the legacy Edit Domain dialog. The Domains list column and the domain header update immediately.
Site filters can exclude a version: the Plugin chip's Version list has the same Is / Is not toggle as Status, and the Theme chip now opens the same Version and Status popover. The chip label shows the sub-filter, so a negated version reads as ≠ 4.2.3 at a glance.
Filter sites, then target them in the console: whenever a filter narrows the Sites list, a "Console" chip appears beside Clear that opens the terminal dock preselected with every matching site's production environment, and a hand-checked selection gets the same via "Open in console" in the bulk actions bar. The target picker shows the selection and can refine it before running.
The Users page has its own address (/account/users), so it can be bookmarked, shared, and reached directly, and browser back and forward work through it. User rows now show the person's Gravatar profile picture when they have one, falling back to the initials monogram when they do not.
An account's Plan tab now previews what the next renewal will cost. A Next renewal estimate card shows the renewal date, the estimated total for the billing interval, and every line behind it: the base plan, extra sites, storage and visits priced from your usage pricing, addons, one-off charges and credits. This is the breakdown the legacy dashboard hid behind a "See breakdown" link.
New site can find the nearest datacenter from the customer's location: a map-pin button beside the Datacenter dropdown opens a place search (type the customer's city or address), and picking a match ranks every datacenter by distance with the closest one selected automatically. Any row in the ranked list can be chosen instead.
The new-post email sent to blog subscribers now carries a Reply-To of the WordPress admin email (Settings → General), so replies reach the inbox instead of the SMTP sending address.
A domain's Sending tab now lists the Mailgun MX records alongside the SPF, DKIM and tracking records, so nothing a sending zone needs is missing from the verification table, and a Copy DNS records button hands you the whole set as plain text ready to paste into a ticket or send to a customer's DNS provider.
The Registry tab now shows whether each component is actually running. Deactivated plugins and themes are grouped below the ones WordPress loads and dimmed, must-use plugins and parent themes are labelled, and a summary line reads the risk that matters: how many critical and high findings sit on code that loads, and how many more are on deactivated components. A deactivated component can be deleted straight from its right-click menu.

Fixed

Setting up Mailgun sending for a domain no longer fails silently. The new dashboard discarded the server's reason, so the button appeared to do nothing. The reason is now shown in the panel, and it is a clearer one: a sending domain that already exists is first looked for in the connected Mailgun account and adopted if it is there, and only reported when the name is genuinely held by an account we do not have, which says that it has to be released there first.
Opening an account with a large site and domain footprint took about a minute, and its timeline was wrong once it arrived. A process log that touched many of the account's sites was fetched once per site, and each repeat re-filtered that log's sites against the account with a linear scan, which on one account came to roughly 2.2 billion comparisons. Repeating a log also rewrote the same record, so its timestamp came back empty and it was drawn as several identical rows. Logs are now read once each and the filter is a keyed lookup, taking that account from 42 seconds to well under a second with every site still listed on its entry.
Opening the address of a site that has been deleted, or that your account cannot see, now shows a clear "This site is no longer here" page instead of another site's header with cards stuck on Loading.
Requesting a site's removal no longer reports "Could not update the removal request" when it in fact succeeded. The server answered with an empty body, which the dashboard read as a failure. It now returns a proper result and the dashboard also tolerates empty replies.
Every confirmation in the dashboard now uses its own dialog instead of the browser's alert box: deleting domains, DNS zones, environments, files, plugins, users and payment methods, revoking passwords, running tools, sending reports, transferring ownership, and more. Destructive actions get a red button named for the action; everything else stays blue. Request site deletion also lists each environment (Production, Staging) with its address so it is clear what the request covers.
A new site provisioned at Kinsta, or a staging environment created or linked there, now reliably reaches the CaptainCore CLI. The hand-off was a single request with nothing behind it, so a busy or restarting core server left the CLI unaware of the new environment (Sync data then failed with "site-staging not found"). The provisioning chain now retries the push until the CLI accepts it, linking is idempotent (a retry can no longer add a duplicate Staging row), the environment list cache refreshes at the same moment, Sync data re-pushes any environment added in the last day before it runs, and the new UI kicks off the first staging Sync data as soon as the environment is ready, as the legacy UI did.
New sites created on Kinsta by customers link into the dashboard again: a permission check introduced this cycle rejected the shared hosting connection for non-administrators, leaving the site orphaned at Kinsta, and the provisioning chain now retries and reports linking failures instead of discarding them.
The legacy dashboard's light mode no longer paints the page, the top bar and every site header bar in the brand blue. Those surfaces now use the same near-white canvas as the new dashboard, with their text darkened to match, so the two do not clash when you switch between them. Dark mode is unchanged.
A payment method can always be removed, including the primary one and a card that is the only method on file.
Adding a domain works for customers again: the New domain dialog now asks which website the domain belongs to (required by the API) and reports errors instead of failing silently.
Cloning a site no longer reports "Permission denied for the clone source" when several site records share the same provider site id. Any record the caller can reach now satisfies the check.
The New domain and New site dialogs no longer present a preview-data account name as the preselected account. When the dialog opens, an account that does not exist is replaced with a clear "Select an account" prompt (a sole account preselects itself), and adding a domain without picking one now says so up front.
Site provisioning handles Kinsta operation failures honestly. When Kinsta reports that a create operation failed outright, the chain now stops right away with the provider's reason recorded on the action and in the activity log, instead of polling for five minutes and failing with no explanation. A create that dies with Kinsta's transient "failed in the background" error is automatically re-submitted once, which is how those creates succeed when retried by hand. And once the site itself exists, a failure in the follow-up CDN steps (edge caching, image optimization) no longer marks the whole provisioning as failed.
Share Access works for agencies: anyone with full access on an account that grants the site (owning, customer, or shared) can now send a site invite. The invite still always lands in the site's customer account, never the agency's own account. The dialog also names the real reason when a send is not allowed instead of a generic error.
DNS records display again: a security guard on the Constellix API wrapper rejected requests whose endpoint carried an inline query string, which silently emptied the DNS editor, the zone export and the DNS CLI. Those calls now pass query arguments through the wrapper's parameter array.
Adding a DNS value for a name that already has a record of that type (a second TXT at the root, another MX server, a round-robin A address) now stacks the value inside the existing record instead of trying to create a duplicate, which Constellix rejects. The legacy editor merged these silently on save; the new editor folds the value in as soon as you click Add record and again on Save as a safety net for zone imports and renames. CNAME and HTTP records stay one per name.

Security

A security audit of the 1.1.0 release candidate went back over the routes and query builders the 1.0.0 hardening pass covered, and over everything this cycle added. Provisioning was the significant find: New site posted its whole payload to the server, that payload was stored as the provisioning job's own state, and the job then read it back as fact. A customer could name the Kinsta site the job resolved and have the following steps fetch that site's SFTP credentials on the operator's API key and file them under their own account, which would have handed them every per-site command the dashboard offers. The payload is now rebuilt from the fields the dialog sends, and the operation result always comes from the recorded operation.
Being a member of no account no longer grants the permissions of a full member. The invite preview shows an invitee what they were invited to before they accept, so it deliberately skips the membership check, and the tier lookup treated the resulting empty level as full access. Opening that preview returned the account's members and their email addresses, its sites and domains, and every other pending invite together with the token that redeems it. Pending invites no longer carry their token, and accepting an invite requires the address it was sent to.
A domain's Mailgun SMTP password is no longer sent to the browser. The dialog never displayed it, but it is a working credential that can send mail as the domain and it stayed valid after its reader lost access to the account.
Names that customers set, on accounts, sites and subscriptions, are escaped where the shared email layout renders them, so a name cannot style or restructure a message that staff receives. Requesting plan changes now checks the caller holds the subscription, as cancelling a plan already did.
Values that cannot be bound as query parameters are constrained where they are used: sort columns and directions in the base model, and site filter values, which were escaped as text but still read as regular expressions. Four query helpers with no callers were removed rather than left inheritable by every model.
Site and domain ownership checks compare ids strictly. Both allow-lists are built from database results, so a loose comparison matched a boolean against any non-empty list, and an empty array counted as authorized. Callers that pass a request value directly are no longer able to satisfy a check for a record they do not own.
Configuration is filtered per viewer. The legacy dashboard rendered the whole configuration option into the page, and it serves logged-out visitors for the invite and connect flows, so a server-side secret stored there reached anyone who asked for it. Non-admins now receive an allow-list of the keys the interface reads.
Environment names are constrained everywhere they reach the CLI server, not only on the log endpoints that already checked them.
DNS record ids are validated before they become part of a provider API path, and the Constellix client rejects endpoints carrying path or query syntax, as the Spaceship client already did.
Deleting a site through the bulk command endpoint requires an administrator, matching the dedicated delete route.
Importing sites from a provider verifies the account they are imported into.
Snapshot download links expire on the server after 24 hours. The expiry was recorded and shown in the interface but never enforced on the request.
Requesting a password reset no longer counts against the sign-in rate limit, so it cannot be used to lock someone out of their own account.
Scheduled report recipients are validated when a report is updated, as they already were when one is created.
Site names, account names and site URLs are escaped in operator notification email, and audit report content is filtered before it is rendered.
Security Finder requests verify TLS, and the CLI token is compared in constant time on the connect endpoint.

Improved

The Site URL and WP admin rows on a site's Credentials card open the address in a new tab when clicked; the Copy button beside them still copies.
Deleting a site now opens an in-app confirm dialog instead of a browser prompt that asked you to type the site name. The dialog states plainly that the site is removed from CaptainCore only and that nothing is deleted at the host. For Kinsta sites, a final downloadable backup is requested for every environment (production and staging) before the record is removed, so a full snapshot is waiting at Kinsta when the site is later removed in MyKinsta; the result is shown in the confirmation toast and recorded on the site's activity log.
Terminal output can be copied again, as in the legacy console: right-click a job in the activity dock for "Copy output" (the whole stream), and hover any console line for a copy button that grabs just that line.
The DNS editor autocorrects values before saving, as the legacy editor did: a CNAME, ANAME, MX server or SRV host missing its trailing dot gets one, and a TXT value typed without quotes is wrapped in them.
The New site dialog now enforces Kinsta's site name limits as you type: the name field stops at 32 characters (the same cap MyKinsta applies) and a live character counter beside the field turns red until the name reaches the 5 character minimum.
Transactional emails got a design refresh. The shared layout's neutrals moved to a single consistent palette, prices and totals are set in monospace, and buttons and cards picked up softer rounding. A new optional email_logo configuration lets emails carry a wide lockup logo while the portal keeps its square logo.
Remaining query builders bind their values and scrub their identifiers, matching the rest of the model layer.
Every third-party script and stylesheet on the legacy dashboard is pinned with a subresource integrity hash.
Plugin classes carry a direct-access guard and the directories that were missing one now have an index file.

v1.0.0 - August 24, 2026

The interface release. CaptainCore Manager reaches 1.0 with a rebuilt /account experience: a fast, hand-maintained single-page interface (templates/core/) that replaces the original Vue dashboard as the default, while the legacy app remains one switch away. This cut also records the control-plane work since 0.18.0: hash-based security operations, session monitoring, new hosting and registrar providers, email forwarding, in-browser logs and a terminal, customer reports, and a proper GitHub Releases cycle with a signed update manifest and self-updater.