Nimble Security 1.1.12
======================
- Quarantine storage moved from wp-content/nimble-security/quarantine into a protected
  folder inside the uploads directory, resolved at runtime with wp_upload_dir(). Existing
  payloads are migrated once, on update, and the folder keeps its .htaccess/web.config
  guards and index.php silence file.
- Extended Protection moved to the Nimble Security Pro add-on. It was the only feature
  that generated a PHP file, and generated PHP has no place in a plugin hosted on
  WordPress.org. The WordPress-routed firewall still enforces every one of the same rules.
- Removed two unnecessary core-file includes (wp-admin/includes/plugin.php in the
  quarantine policy check, wp-admin/includes/update.php in the update-status refresh).
- Diagnostics now probes the uploads directory for writability instead of wp-content.
- External services documented in full, with Terms of Service and Privacy Policy links.

Nimble Security 1.1.11
======================
- Removes the Nimble Security Pro licence client, the Licence admin screen and all licence storage from the free plugin. Licensing now ships only with the commercial Pro package. Nothing in the free plugin is gated, checked, time-limited or dependent on a key.
- The two-factor login screen loads assets/css/login-2fa.css instead of printing a <style> block, and the interim-login handoff script is attached to customize-base with wp_add_inline_script() instead of being printed inline.
- Uninstall still clears the licence options and the daily validation schedule left behind by earlier versions.
- No protection-engine, Easy Setup, integrity, firewall, scanner, Operations or Backup contract changes.

Nimble Security 1.1.10
======================
- Hides the licence key field until Nimble Security Pro is installed on the site. Pro defines its version constant before its own licence gate, so installing Pro reveals the field even while it is still unlicensed. The filter nimble_security_license_entry_visible overrides this.
- With no key and no Pro present, the licence screen is purely informational: Pro is coming, and nothing in the free version is waiting on it.
- No behaviour change.

Nimble Security 1.1.9
=====================
- The licence screen no longer presents an unreleased product as a missing one. With no key stored it reads "coming soon" rather than "not activated", and the key field sits under "Already have a key?" instead of being the page's call to action.
- Pro capabilities are described in the future tense throughout, since Pro is not released yet.
- No behaviour change.

Nimble Security 1.1.8
=====================
- Rewrites the plugin description for the WordPress.org directory: user-facing language, no internal release wording, no version numbers of sibling products that would go stale.
- Corrects the Contributors username to nimbleplugin, which is the actual WordPress.org account.
- Documents at each call site why the quarantine, scanner and permission-audit paths use direct filesystem calls rather than WP_Filesystem.
- Adds a translators comment to the one remaining placeholder string that lacked one, and regenerates the .pot (913 -> 936 strings).
- Removes three internal release-candidate entries from the readme changelog; changelog.txt keeps the full history.
- No behaviour change.

Nimble Security 1.1.7
=====================
- Replaces the placeholder brand mark with the real Nimble logo across every surface: the WordPress admin menu icon, the plugin header, the licence screen, the two-factor login screen and both request-blocked pages.
- The admin menu icon and the blocked-request pages carry the mark inline, so they render without an extra HTTP request and remain correct when Extended Protection runs before WordPress has loaded.
- The brand mark drops its cyan glow in light mode, where it read as a halo against the white header.
- No behaviour change.

Nimble Security 1.1.6
=====================
- Declares Tested up to 7.1 so the plugin remains listed in WordPress.org search.
- Uninstall now passes both plugin-owned table names through $wpdb->prepare() as %i identifiers instead of interpolating them, clearing the Plugin Check DirectDB warnings at the source rather than suppressing them.
- No behaviour change.

Nimble Security 1.1.5
=====================
- Aligns the phpcs suppression on the permission-hardening chmod with the sniff names used elsewhere in the package, so the WordPress.org Plugin Check does not flag an unsuppressed direct file-system call.
- No behaviour change of any kind.

Nimble Security 1.1.4
=====================
- Adds Smart 404 blocking (opt-in, disabled by default): a client that produces a burst of missing-page hits is blocked for a bounded period. Off by default because a site with many broken links can produce the same pattern from a legitimate crawler.
- Signed-in administrators and allowlisted paths are never counted; blocking only happens in Protect mode, while Learning records the burst without refusing anything.
- Adds file permission auditing: WordPress directories and configuration files are checked for group/other write access, reported under Diagnostics, and can be tightened from there. Tightens only, never loosens, never leaves the installation, and reports what could not be changed.
- New settings: Smart 404 threshold, window and block duration; permission auditing on/off.
- New events: firewall.not_found_detected, firewall.not_found_blocked, firewall.not_found_refused, integrity.permissions_hardened.
- No licensing, Easy Setup, malware scanner, integrity, Threat Cloud, Operations or Backup/Recovery behavior changes.

Nimble Security 1.1.3
=====================
- Large eligible script-bearing files from 5–50 MiB are now scanned through bounded 1 MiB streaming windows with a 16 KiB overlap.
- The malware scanner no longer labels an otherwise complete scan incomplete solely because a normal script asset exceeds 5 MiB.
- Files above 50 MiB remain outside the bounded local scan and still prevent a clean coverage claim; unreadable eligible files remain coverage failures.
- Incomplete coverage now records a bounded list of relative paths/reasons so the administrator can see what prevented full coverage.
- No licensing, Easy Setup, firewall, integrity, Threat Cloud, Operations or Backup/Recovery behavior changes.

Nimble Security 1.1.2
=====================
- Fixes horizontal overflow in the WordPress admin by keeping the Security canvas within the available viewport width.
- Uses shrink-safe grid columns and min-width guards for dashboard panels and Easy Setup cards.
- No security, licensing, Easy Setup, Threat Cloud, Operations or Backup/Recovery behavior changes.

Nimble Security 1.1.1
=====================
- Adds first-run Easy Setup with Skip for non-technical site owners.
- Recommended setup applies compatibility-safe local protection and schedules the first checks.
- Preserves the 1.0.1 Free-owned Pro licensing client and response-automation hook.
- Improves inline licence/Pro notice contrast in both dark and light mode.
- Database schema, Operations 1.11, Backup/Recovery and Threat Cloud contracts are unchanged.

Nimble Security 1.0.1
- Fires nimble_security_response_automation_panel on the Response admin page. Nimble Security Pro renders its recovery-gated automation policy form on that hook; without it the panel never appeared and the policy stayed permanently Off.
- No security policy, schema, Threat Cloud, Operations or Backup contract changes.

Nimble Security 1.0.0
- First stable release; clean version number replaces the 1.0.0-rc series.
- Adds the NimblePlugins signed licensing client, owned by Free (RSA-SHA256 verified verdict, encrypted local key storage, 7-day offline grace, daily background validation).
- Adds the Nimble Security > Licence admin page.
- Fixes a corrupted uninstall.php that had lost its opening PHP tag; no uninstall cleanup ran at all, including the fail-open disabling of a generated Extended Protection auto_prepend_file policy.
- Uninstall now also clears licence state and the licence validation schedule.
- No security policy, schema, Threat Cloud, Operations or Backup contract changes.

=== Nimble Security ===
Contributors: nimbleplugins
Tags: security, firewall, malware scanner, two-factor, integrity
Requires at least: 6.6
Requires PHP: 8.1
Tested up to: 7.1
Stable tag: 1.1.6
License: GPLv2 or later

High-end WordPress security built as the protection layer for the NimblePlugins product family.

== Description ==


Nimble Security 1.0 RC14 keeps the RC12 runtime hotfix and completes the release UX while preserving the RC11 cache/runtime maintenance intelligence. Nimble Threat Cloud remains in the architecture but is presented as Coming soon until the production service is launched.

Current Free protections include:

* wp-config.php changes are REVIEW signals by default, not automatic HIGH/Action Required findings. Administrators can explicitly trust a recognized current wp-config.php; Nimble stores only a new SHA-256 baseline and never copies configuration contents/secrets into the Security database.
* Software update posture rejects stale WordPress update transients. An update is only counted when WordPress checked the exact version currently installed and advertises a strictly newer version. Stale/unknown update state is shown separately and does not reduce Security Score as if the installed component were outdated.
* Vulnerability/Threat Intelligence UI presents Nimble Threat Cloud as Coming soon while still avoiding false claims of authoritative vulnerability coverage.
* Data-only threat-intelligence extension contracts for authoritative vulnerability advisories, malware definitions, virtual-patch firewall rules and IP reputation. Free remains the enforcement owner and fails open if Pro or the feed is unavailable.
* Basic WAF can enforce a verified reputation decision without persisting raw IP addresses; event storage hashes the actor.
* Prepared Extended Protection policies automatically recompile after a verified threat-feed update so signed virtual patches can reach the pre-bootstrap WAF without a manual re-prepare step.
* Emergency Lockdown preserves the current rescue administrator, revokes other privileged WordPress sessions, restricts new privileged sign-ins, disables Application Passwords/XML-RPC, freezes WordPress file modifications/background updates, and removes high-risk administrative capabilities until explicitly exited.
* Filesystem break-glass support: defining `NIMBLE_SECURITY_DISABLE_LOCKDOWN` as true bypasses enforcement so a site owner can recover out-of-band if the WordPress admin becomes unreachable; the configured emergency state remains visible as bypassed until cleared or enforcement is resumed.
* Manual privileged-session containment can revoke all other administrator/super-admin sessions without changing passwords.
* Component-level containment can deactivate an affected active site-level plugin as a whole when a malware finding cannot safely be quarantined file-by-file. The exact affected file is canonicalized and SHA-256 revalidated immediately before deactivation; stale evidence is refused. Network-active plugins remain explicit/manual-only.
* Component containment requests a recovery point when a provider is connected, invalidates the affected observed baseline and starts fresh Integrity + Malware verification.
* Manual hash-verified quarantine for eligible high-confidence malware findings.
* Quarantine refuses stale findings when the file SHA-256 changed after detection.
* Active plugin/theme files, Nimble Security runtime files and other system-sensitive locations are blocked from automatic single-file removal in this safety-first release.
* Every quarantined payload is AES-256-GCM encrypted at rest in a guarded local vault with its plaintext SHA-256, original mode/mtime and a non-overwriting restore path.
* Successful quarantine and restore automatically request fresh Integrity + Malware verification scans.
* Local incident repository with open/contained/resolved states and risk scores.
* Recovery-point provider contract for Nimble Backup or another registered recovery provider; if a connected provider fails before quarantine, the destructive action is stopped.
* Resumable local malware scanning with both a 120-entry ceiling and a short wall-clock chunk budget, advanced automatically by a signed non-blocking same-site worker, WP-Cron fallback and delayed watchdog.
* Integrity and Malware scans require one Start action only; administrators no longer manually process each chunk.
* The scan page polls bounded status data while open, but closing the browser does not stop the server-side job.
* Delayed workers are self-healed server-side by an independent watchdog; browser status polling is supplemental rather than required.
* Seven deliberately narrow high-confidence malware heuristics for encoded execution, direct request-to-shell execution and suspicious JavaScript/PHP loaders.
* Malware file contents stay on the WordPress server. Findings store rule metadata and SHA-256 state, not source excerpts.
* Symlinks are reported but never followed by the malware scanner. High-churn cache/build directories are excluded.
* Files above 5 MiB are not read by the local malware scanner. If eligible files are unreadable or exceed the limit, the scan is labelled incomplete instead of clean.
* Older malware findings are not auto-resolved by an incomplete scan.
* WordPress core, plugin and theme component inventory with installed version, active state and local update availability.
* Strict data-only vulnerability-advisory matching contract with introduced/fixed or last-affected version ranges.
* Vulnerability results are never labelled clean unless the advisory provider explicitly marks its feed authoritative. Free 1.0 RC7 ships without an authoritative advisory feed and says so in the UI.
* Data-only virtual-patch firewall rule extension contract. The local WAF rejects malformed external rule schemas/regexes before use.
* Local Basic Protection firewall for WordPress-routed requests, with Protect, Learning and Off modes.
* High-confidence firewall rules for traversal/LFI, sensitive-file probes, executable uploads, SQL injection, XSS probes, dangerous stream wrappers and TRACE/TRACK.
* Optional per-IP WordPress request rate limiting, disabled by default.
* Extended Protection compiler for explicit PHP auto_prepend_file deployment.
* Login Guard, privacy-preserving brute-force rate limiting and temporary lockouts.
* Encrypted TOTP two-factor authentication, one-time recovery codes and TOTP replay protection.
* WordPress session control, author-enumeration protection, optional XML-RPC authentication control and Application Password auditing/revocation.
* Integrity findings are interpreted before they reach the administrator: a raw file difference is not labelled a confirmed compromise merely because a baseline changed.
* WordPress-confirmed plugin/theme installs, updates and deletions are correlated with integrity state. Previous component findings are resolved, the stale local baseline is invalidated and the affected component is re-baselined locally in the background after the lifecycle operation.
* Trusted post-update re-baselining is component-scoped and does not contact WordPress.org or upload component files/hashes. It runs independently of the optional daily full integrity schedule because it is a local maintenance operation.
* Existing RC3 plugin/theme file-difference findings are migrated on first RC6 boot: ordinary added/modified component files become Review-level findings, while removed/missing plugin/theme components become low-priority information. Core, configuration, drop-in and MU-plugin integrity signals retain stronger treatment.
* Integrity UI groups changes by WordPress/component and starts with a plain-language “What should I do?” assessment: No action, Review, or Action required. Detailed file paths stay available inside expandable groups.
* HTTPS-only WordPress core checksum verification against the official WordPress.org checksum service.
* Resumable SHA-256 observed baselines for plugins, MU plugins, drop-ins, themes and selected security-sensitive configuration files.
* Bounded local event/finding engines and a 100-point Security Score spanning hardening, Identity, Integrity, Firewall, Detection, software-update posture and a 10-point Recovery Readiness contribution from a privacy-safe backup provider.
* Privacy-safe Nimble Operations health provider contract 1.11, coordinated with Operations Pro 0.5.5, with aggregate detection, exact open-incident severity counts and backward-compatible interpreted integrity state.
* WordPress Abilities/REST status contract.

Important: Free 1.0 RC7 contains a real local malware detector, but its small embedded heuristic rule set is intentionally not described as a complete malware intelligence service. Likewise, vulnerability inventory/matching is active but no authoritative real-time advisory feed is bundled in Free. Signed real-time advisory, malware-signature and virtual-patch feeds remain a Pro/Nimble Threat Cloud capability.

== External service ==

When an administrator explicitly starts an integrity scan, Nimble Security requests the checksum list for the site's installed WordPress version and locale from the official WordPress.org Core Checksums API at api.wordpress.org. The request is HTTPS-only and sends the installed WordPress version and locale needed to select the checksum set. It does not upload file contents, local file hashes, credentials, customer data or the site URL in the Nimble Security user-agent. As with any outbound HTTPS request, the remote service can observe normal network metadata such as the connecting server IP address.

Automatic daily integrity scans are disabled by default. If an administrator enables them in Nimble Security > Settings, future scheduled scans may make the same WordPress.org checksum request.

Plugin, MU-plugin, drop-in, theme and configuration-file integrity baselines are calculated locally and do not upload component files or hashes. WordPress-confirmed plugin/theme installs, updates and deletions are correlated locally with Integrity. Changed component findings are resolved, the stale component baseline is invalidated and that specific plugin/theme is re-baselined locally in the background. This trusted maintenance refresh does not call the WordPress.org checksum service and does not depend on the optional daily full-integrity schedule. WordPress core verification remains a full-scan operation because it uses the official WordPress.org checksum service described above.

== Installation ==

1. Upload and activate Nimble Security.
2. Open Nimble Security > Identity and enroll administrator 2FA.
3. Open Nimble Security > Integrity and run the initial baseline scan.
4. Open Nimble Security > Firewall and validate Basic Protection in your environment.
5. Open Nimble Security > Scanner and run the first local malware scan.
6. Open Nimble Security > Vulnerabilities and review installed software/update posture. A zero advisory match is not authoritative until a verified advisory feed is connected.
7. Open Nimble Security > Response to review incidents, quarantine state, component containment, Emergency Lockdown and recovery-provider connectivity.
8. If you want pre-bootstrap filtering, prepare Extended Protection and apply the displayed auto_prepend_file directive through hosting/PHP configuration only after staging validation.
9. Review Settings before enabling automatic integrity or malware scans.

== Firewall model ==

Basic Protection runs after active plugins have been loaded but before theme setup/init. It therefore protects WordPress-routed requests without claiming to intercept requests that never invoke WordPress/PHP. Baseline rules intentionally inspect only the request method, path and query string; request bodies and cookies are not collected by the firewall engine.

Protect mode blocks matched high-confidence rules. Learning mode records the same matches without blocking. Off disables Basic Protection. The optional global request rate limiter is disabled by default because shared NAT, reverse proxies and high-volume legitimate clients can otherwise be penalised. Client identity defaults safely to the socket peer; forwarded client-IP headers are accepted only when the direct peer matches an explicitly configured trusted-proxy CIDR.

Extended Protection is a generated, standalone PHP bootstrap intended for PHP's auto_prepend_file setting. Preparing it writes the bootstrap, a local PHP policy file and a bounded queue under wp-content/nimble-security/firewall. Nimble Security does not edit php.ini, .user.ini, .htaccess or hosting configuration automatically in 1.0 RC7. When activated by the server, the bootstrap evaluates the same compiled baseline rules before WordPress loads. It stores only keyed hashes for blocked request correlation and never stores raw IP addresses, cookies or request bodies.

If Nimble Security is deactivated or uninstalled, the generated policy is disabled so an old auto_prepend_file directive fails open instead of continuing stale enforcement.

== Integrity model ==

WordPress core uses official remote checksums and can therefore be verified against a known source.

Plugins, MU plugins, WordPress drop-ins, themes and selected configuration files use an observed local baseline. That baseline proves whether files changed after the observation point; it does not prove that the initially observed package was authentic or malware-free. Nimble Security intentionally labels these snapshots as observed baselines rather than verified packages.

When WordPress reports a successful plugin/theme install, update or delete, Nimble Security treats that operation as trusted maintenance rather than an unexplained file attack. On install/update the old observed baseline is invalidated, stale component findings are resolved, and that exact plugin/theme is re-hashed locally in a component-only background refresh. This maintenance refresh runs even when the optional daily full scan is disabled and does not contact WordPress.org. If a lifecycle change occurs during an active scan, the mixed-time scan is superseded rather than trusted. WordPress core remains separately verified against the official checksum service during a full integrity scan.

== Detection model ==

The Free malware engine runs locally and is deliberately conservative. It scans eligible PHP/script-bearing files in resumable chunks and applies data-only regex definitions. It does not upload file contents. A clean state means the current installed rules found no high/critical match and scan coverage was complete; it is not a mathematical proof that every file is benign. If eligible files are unreadable or exceed the 5 MiB safety limit, the scanner reports incomplete coverage and does not use that scan to auto-resolve previous malware findings.

The vulnerability layer inventories WordPress core, plugins and themes using local WordPress state and matches them against a schema-restricted advisory provider contract. Version ranges support an introduced version plus exactly one upper bound: fixed (exclusive) or last_affected (inclusive). Free 1.0 RC7 does not pretend to ship an authoritative advisory database. A provider must explicitly report authoritative=true before an empty matched-advisory set may be presented as a clean vulnerability state.

The Pro 1.0 RC7 extension keeps the cryptographic trust boundary for future Ed25519-signed data feeds, retains high-confidence incident correlation and adds explicitly opt-in conservative automation. It still does not enable a production network threat feed, active-component auto-deactivation, automatic session revocation or automatic Emergency Lockdown.

== Response model ==

Response 0.6 is manual-first. Nimble Security re-hashes the exact malware file immediately before quarantine and refuses the action if the bytes changed after detection. Quarantine is limited to locations where single-file isolation is not expected to dismantle an active WordPress runtime component; active plugins/themes and system-sensitive paths are deliberately refused. The local quarantine vault stores randomized `.qtn` envelopes encrypted with AES-256-GCM and also installs server access guards as defense in depth. The original malware bytes are never deliberately persisted as plaintext in the vault. Restore never overwrites an existing original path, rejects symbolic-link parent segments, authenticates/decrypts the payload, and verifies the plaintext SHA-256 before writing bytes back.

A recovery provider may register through the nimble_security_recovery_point_providers contract. When at least one provider is connected, Nimble Security requests a recovery point before quarantine. If all registered providers fail, the quarantine action is stopped. If no provider is registered, local quarantine still retains its own encrypted, authenticated restore payload.

Every successful quarantine or restore requests new Integrity and Malware scans. Operations receives only aggregate incident/quarantine/verification status; local file paths and quarantine payloads are not exported by the health contract.

== Privacy ==

Nimble Security stores security state locally. Authentication/firewall actors used for rate limiting and event correlation are keyed hashes; the Operations provider never returns raw IP addresses, credentials, request bodies, cookies, file contents or local file paths. Malware scanning is local; file contents/excerpts are not persisted as findings. Basic Firewall events store the bounded request path but never the query/body. Extended Protection queues only keyed actor/path hashes and technical rule metadata.

TOTP secrets are encrypted locally using AES-256-GCM with a key derived from the site's WordPress authentication salts. If authenticated encryption is unavailable, Nimble Security refuses to enroll 2FA instead of storing the secret unencrypted.

Recovery codes are displayed once and stored only as password hashes.

== Changelog ==

= 1.0.0-rc16 =
* Final WordPress.org compliance pass.
* Documented the bounded dynamic IN-list prepare call so PHPCS does not miscount variadic replacement values.
* No runtime security behavior, database schema, Operations contract, Backup contract, or Threat Cloud behavior changed.

* WordPress.org compliance pass 2: fixes translator-comment placement in admin templates.
* Removes the remaining PreparedSQL.NotPrepared findings in BaselineRepository with inline prepared reads.
* Consolidates narrowly scoped direct-database annotations where fresh uncached security state is intentional.
* No security policy, schema, Threat Cloud, Operations or Backup contract changes.

= 1.0.0-rc12 =
* Hotfix: prevent a fatal TypeError in Integrity runtime-maintenance reconciliation on admin_init / scheduled no-argument hooks.
* Register no-argument maintenance hooks with accepted_args=0 and defensively normalize direct method input.
* No security policy, database schema, Operations contract or Backup contract changes.

= 1.0.0-rc11 =
* Tracks plugin activation/deactivation as maintenance context in addition to install/update/delete.
* Reclassifies .htaccess hash changes and missing drop-ins as Review-level Integrity signals rather than automatic Action Required.
* Auto-retires stale missing advanced-cache/object-cache/db drop-in baselines only when their disappearance is temporally correlated with recent WordPress-confirmed plugin maintenance.
* Adds explicit safe Intentional actions for recognized .htaccess and WordPress drop-in changes/removals with exact-path and symlink checks.
* Modified/new executable drop-ins are never blindly auto-trusted; Malware/Vulnerability/Core/Incident evidence is unaffected by Integrity acknowledgement.
* Preserves RC10 local QR 2FA, Operations contract 1.11 and Nimble Backup recovery integration.

= 1.0.0-rc9 =
* Adds WordPress privacy-policy, exporter and eraser integration without exposing authentication secrets.
* Adds incident-aware Security Score caps and release-package hardening.
* Preserves the RC8 Update Intelligence, Intentional state, Operations and Backup contracts.

= 1.0.0-rc8 =
* Adds Update Intelligence for WordPress plugin/theme maintenance: pre-install snapshots, post-install correlation, process-complete handling and explicit `upgrader_overwrote_package` support for uploaded ZIP replacement.
* Makes trusted update correlation idempotent across overlapping WordPress upgrader hooks and queues component-only local re-baselining automatically.
* Adds a pending-update reconciliation safety net for self-updates/hosts where the final upgrader callback is interrupted.
* Adds explicit administrator “Intentional” handling for review-only plugin/theme Integrity changes and wp-config.php. This resets only Integrity baselines; Malware, Vulnerability and Incident evidence is never cleared.
* Adds bulk acknowledgement for multiple review-only plugin/theme maintenance groups, while excluding WordPress core and stronger Integrity conditions.
* Adds site-level intentional diagnostics for supported configuration warnings. `DISABLE_WP_CRON` can now be acknowledged when an external/system cron is deliberately used; Nimble warns again if the underlying condition changes.
* Keeps Operations Pro 0.5.5 provider contract 1.11 and Nimble Backup 1.40.1 recovery/readiness contracts unchanged.
* Retains RC7 per-user Light/Dark mode and the Vulnerabilities/Response admin separation fix.

= 1.0.0-rc6 =
* Fixes legacy `scheme:/component/...` Integrity target parsing so plugin, theme and configuration findings no longer collapse into a generic “Other site files” group.
* Adds a plain-language Integrity decision layer with No action / Review / Action required semantics and component-grouped findings.
* Adds an explicit “I recognize this update” workflow for plugin/theme version transitions. Nimble only permits it when the recorded current version still exactly matches the installed version, then resolves that component's obsolete findings and rebuilds only its local observed baseline.
* Same-version unexplained file changes cannot use the version-acceptance shortcut.
* Gives wp-config.php its own security-sensitive explanation instead of mixing it with plugin update noise.
* Review-level plugin/theme groups stay collapsed by default; only action-required sensitive groups open automatically.
* Correlates WordPress-confirmed plugin/theme install, update and delete lifecycle events with Integrity instead of presenting expected maintenance as unexplained high-severity changes.
* Automatically performs a local, component-scoped post-update baseline refresh without contacting WordPress.org and without requiring automatic daily scans.
* Reclassifies legacy open plugin/theme file-difference findings on first RC6 boot: ordinary added/modified files become Review-level; missing/removed components become low priority.
* Reserves High/Critical integrity treatment for stronger signals such as WordPress core, sensitive configuration, drop-ins/MU-plugin changes or correlated malware evidence.
* Adds boundary-safe component-family finding resolution so similarly prefixed plugin slugs cannot resolve each other.
* Coordinates directly with Nimble Operations Pro 0.5.5 by publishing the expected Security provider contract 1.11, including exact open-incident severity counts and backward-compatible integrity state mapping.
* Integrates Nimble Backup 1.40.1 recovery-point and aggregate health contracts into a 10-point Recovery Readiness contribution to the Security score, without reading backup archives, paths or credentials.
* Retains RC3 scanner endurance, watchdog and Extended-WAF hardening unchanged.

= 1.0.0-rc3 =
* Keeps the 1.0 feature freeze and focuses on scanner endurance and generated-runtime hardening.
* Adds a short wall-clock budget to Integrity and Malware chunks while preserving exact processed-entry cursors.
* Adds a delayed server-side scan watchdog in addition to signed loopback and WP-Cron fallback workers.
* Revalidates scanner file identity and root containment at read/hash time, refusing symlink/path swaps instead of following them silently.
* Fixes a lock-contention edge case where a loopback worker could clear the scheduled fallback before discovering another worker held the scanner lock.
* Replaces Integrity's end-of-component second filesystem traversal with batched per-job verification markers and database-bounded missing-file detection.
* Bumps the internal database schema to 1.0.0 with `file_hashes.last_verified_job`; Diagnostics verifies the column exists.
* Generated Extended WAF bootstrap refuses direct web execution and its policy file requires the bootstrap runtime marker.
* Corrupt Extended WAF queue headers are reset safely under lock and reported as a high-severity technical event.
* Bumps Nimble Operations health-provider contract to 1.12 with watchdog, runtime-budget and Extended-WAF direct-access-guard capabilities.

= 1.0.0-rc2 =
* Fixes multi-entry trusted-proxy CIDR and firewall allowlist persistence from older builds that stored literal `\n` separators.
* Hardens firewall allowlists against root, query/fragment, traversal and prefix-boundary bypasses.
* Authenticates Extended WAF queue entries with HMAC-SHA256 and rejects tampered/stale entries.
* Detects stale generated Extended-WAF policy artifacts and safely refreshes them where possible.
* Adds short-lived HMAC scan-worker tokens while retaining WP-Cron fallback.
* Adds RC2 attack/failure regression coverage for WAF rules, encoded traversal, trusted proxy chains and queue authenticity.

= 0.9.0 =
* Adds Free-owned threat-intelligence consumption contracts for advisories, malware rules, virtual patches and IP reputation.
* Basic WAF can enforce verified Pro reputation decisions.
* Extended Protection recompiles prepared policies after a verified threat-feed update.
* Vulnerability scanner schedules a short deferred rescan after threat intelligence changes.
* Operations provider contract 1.8 adds aggregate signed-feed health, sequence, expiry and rule counts.


= 0.7.0 =
* Adds Emergency Lockdown with rescue-admin preservation and out-of-band break-glass constant.
* Revokes other privileged sessions on Lockdown activation and supports explicit privileged-session containment without password changes.
* Restricts new privileged logins during Lockdown while leaving the rescue administrator able to re-authenticate.
* Disables Application Password availability, XML-RPC, file modifications and automatic background updates while Lockdown is active.
* Removes high-risk plugin/theme/core/user-management capabilities during Lockdown without removing `manage_options`, so Security can still be exited.
* Adds active site-level plugin component containment for malware findings that cannot safely be quarantined file-by-file.
* Component containment is recovery-aware, invalidates observed integrity state and starts fresh Integrity + Malware verification.
* Network-active plugin containment remains manual-only.
* Adds a stable Free-owned response-service contract used by Pro automation without exposing plugin globals.
* Nimble Operations health-provider contract 1.7 adds Emergency Lockdown and automation aggregates.
* Deactivation fails open by clearing stored Emergency Lockdown state.

= 0.6.0 =
* Adds safety-first manual Response layer with hash revalidation before quarantine.
* Adds AES-256-GCM encrypted local quarantine vault and non-overwriting, symlink-aware, SHA-256 verified restore.
* Refuses automatic single-file quarantine for active plugins/themes, Security itself and system-sensitive locations.
* Adds incident repository with open, contained and resolved states plus bounded risk scores.
* Adds recovery-point provider contract for Nimble Backup integration without cross-product database coupling.
* Starts fresh Integrity and Malware verification automatically after successful quarantine or restore.
* Adds branded Response dashboard and quarantine actions directly on eligible Scanner findings.
* Nimble Operations health-provider contract 1.6 adds aggregate incident, quarantine, recovery-provider and verification state.
* Adds response-safe event hook used by Pro incident correlation without exposing raw request bodies, cookies, credentials or raw IP addresses.

= 0.5.1 =
* Removes manual “Process next chunk now” from normal Integrity and Malware scan workflows.
* Adds signed automatic same-site scan workers with WP-Cron fallback and browser status polling.
* Adds self-heal dispatch when an open scan page observes a worker that has not advanced recently.
* Registers the previously missing integrity deferred-start hook.
* Bumps the Nimble Operations health-provider contract to 1.5 with automatic scanner-orchestration capability.

= 0.5.0 =
* Detection Layer: resumable bounded local malware scanner.
* Seven high-confidence local malware heuristics with strict data-only extension schema.
* Scan coverage semantics prevent incomplete scans from being labelled clean or auto-resolving previous findings.
* WordPress core/plugin/theme component inventory and local update posture.
* Strict vulnerability-advisory matching contract with explicit authoritative-feed semantics; Free ships with no authoritative feed.
* Data-only virtual-patch firewall rule extension contract.
* Nimble Operations health provider contract 1.4 adds malware/vulnerability/update aggregates and scanner coverage state.
* Detection settings for daily malware scans (off by default) and component re-evaluation.
* Lifecycle cleanup for malware/vulnerability workers and scan state.
* Scan worker locks use atomic option acquisition plus ownership tokens so an expired worker cannot release a newer worker’s lock.
* Five-layer branded Protection roadmap and responsive full-canvas dashboard retained.



= 0.4.0 =
* Active local application firewall for WordPress-routed requests.
* High-confidence baseline WAF rule families for traversal/LFI, sensitive files/executable uploads, SQL injection and XSS.
* Protect, Learning and Off modes.
* Optional global per-IP WordPress request rate limiting, disabled by default.
* Narrow path-prefix allowlist.
* Standalone Extended Protection compiler for explicit PHP auto_prepend_file deployment.
* Extended policy mirrors firewall mode and allowlist; settings changes refresh prepared policy atomically.
* Bounded privacy-safe pre-bootstrap event queue using keyed IP/path hashes only.
* Deactivation/uninstall fail-open safety disables the generated policy.
* Firewall state and 24-hour aggregates added to Nimble Operations contract 1.3.
* Security Score rebalanced to include active firewall and enforcement state.
* Fixed the integrity auto-scan settings handler to call the correct IntegrityScanner service.

= 0.3.0 =
* Integrity Protection dashboard and admin workflow.
* HTTPS-only official WordPress core checksum verification.
* Detects modified, missing, unreadable and unexpected executable core files.
* Resumable component scanner with bounded 250-file chunks.
* Local SHA-256 observed baselines for plugins, the full MU-plugin directory, WordPress drop-ins, themes and selected configuration files.
* Detects added, modified and missing component files without silently moving the baseline.
* Security-sensitive executable/config changes receive higher severity.
* Symlinks are reported but never followed.
* Files over 50 MiB are not hashed; oversized security-sensitive files become findings.
* WordPress plugin/theme lifecycle events invalidate affected update baselines and require a refresh; background refresh runs only with automatic-scan opt-in.
* Integrity scan state and aggregate findings added to Nimble Operations contract 1.2.
* Security Score rebalanced to include current integrity monitoring and high-severity integrity state.
* Automatic daily integrity scans are opt-in and disabled by default.
* Initial observed baselines are built transactionally as an in-progress state and promoted only after the component finishes, preventing interrupted partial baselines from being trusted.
* Scans are superseded if a trusted plugin/theme lifecycle change occurs concurrently.
* Resolved integrity findings are retained for 90 days; completed/failed/superseded scan jobs for 30 days.

= 0.2.0 =
* Active Login Guard with brute-force rate limiting and lockouts.
* IP + IP/account-pair limiting avoids global username lockouts that could be abused for denial of service.
* Generic authentication errors.
* TOTP 2FA with encrypted secrets, a dedicated two-stage WordPress login challenge and one-time recovery codes.
* TOTP replay protection records the last accepted time step with compare-and-swap updates.
* Separate invalid-2FA rate limiting.
* Session control for the current administrator.
* Numeric author-enumeration protection.
* Authenticated XML-RPC control.
* Application Password auditing and revocation.
* Identity status added to the Operations contract.
* Expanded Security Score with active identity controls.
* New fully branded Identity dashboard and settings.
* Security event taxonomy preserves dotted event names.

= 0.1.1 =
* Full-canvas branded admin background.
* Initial Free foundation and seven-table storage model.
* Bounded local event engine.
* Baseline hardening score.
* Native Operations health provider contract 1.1.
* Abilities API status ability and REST fallback.

= 0.9.0 =
* Production hardening: trusted-proxy client IP resolution, network-scoped settings when network activated, Extended WAF reputation enforcement, and Operations contract 1.9.
