Luketom Compromise Review

Changelog

1.18.3

• Distinguish verified LiteSpeed-managed .htaccess changes from unexplained important-file changes.
• Show expected LiteSpeed-only changes as calm informational notices instead of red security warnings.
• Require the approved non-LiteSpeed rules to remain byte-for-byte unchanged and reject suspicious cache-block directives before applying the informational classification.
• Keep administrator approval explicit and suppress urgent change emails only for verified expected LiteSpeed changes.

1.18.2

• Document the intentional use of LiteSpeed Cache and WP Super Cache third-party purge hooks for WordPress coding-standard checks.

1.18.1

• Rename the plugin and directory slug to Luketom Compromise Review to provide a distinctive WordPress.org identity.
• Replace short global, option, cron, nonce and asset prefixes with the unique luketom_cr prefix.
• Migrate existing Site Guard settings, scan history, approved administrators, integrity records and learned decisions without deleting rollback data.
• Retain verified restoration support for quarantine records and inactive themes created by versions up to 1.18.0.
• Correct the WordPress.org contributor username.

1.18.0

• Keep exact rewrite evidence actionable after its confirmed gambling payload has already been quarantined, including existing 1.17.1 records.
• Detect the Babeltoto payload variant shown in the Mifsuds incident.
• Store a protected, fingerprinted recovery copy only after an administrator explicitly approves .htaccess or Compromise Review verifies a repair.
• Add an explicit one-click recovery action that first preserves the current .htaccess as a separate verified rollback copy.

1.17.2

• Preserve exact rewrite evidence when a confirmed gambling payload is quarantined.
• Revalidate the fingerprinted protected copy so its matching .htaccess rule remains a confirmed, repairable finding after the live payload file has been moved.
• Support existing 1.17.1 quarantine records by verifying their target path, stored fingerprint and payload contents before permitting repair.
• Detect the Babeltoto variant shown in the Mifsuds incident.

1.17.1

• Restore individual and bulk inactive-theme removal.
• Revalidate every selected theme immediately before removal and keep active, parent, child and multisite themes protected.
• Store every removed theme as a fingerprinted, non-executable restore copy instead of permanently deleting it.
• Add one-click verified theme restoration without activating the restored theme or overwriting an existing directory.

1.17.0

• Require independent evidence and a fresh exact fingerprint before quarantine or .htaccess repair.
• Treat incident-associated filenames and generic code signatures as review-only, never as automatic removal evidence.
• Add verified one-click restore for new and existing quarantine records and restorable .htaccess repair backups.
• Refuse restores that would overwrite an existing file or .htaccess rules changed after repair.
• Disable permanent theme deletion and bulk malicious classification inside Compromise Review.
• Keep a 50-entry repair, quarantine and restore action history.

1.16.5

• Allow the strict clean tick when an optional affected page returns an HTTP error such as 404.
• Continue displaying the affected-page error for configuration review without treating it as evidence of infection.
• Withhold the clean tick only when live-page verification actually detects the known malicious payload.

1.16.4

• Replace the number 5 in the green Remember step with a tick only when every strict clean condition is satisfied.
• Keep the numbered 5 whenever scan batches, warnings, unapproved administrators, monitored files or important-file alerts remain.
• Use the journey marker itself as the clean affirmation instead of adding a separate completion panel.

1.16.3

• Display a clear files-and-database backup requirement beside the full security scan.
• Require an explicit backup confirmation before the full scan begins.
• Explain that scanning is read-only while later repair, quarantine and removal controls can change the site.

1.16.2

• Add a prominent green tick confirmation only when a full scan has completed with no unresolved security findings.
• Require all administrators to be approved, all scan batches to be complete, no uncertain monitored files and no outstanding important-file alerts.
• Suppress clean confirmation when the most recent affected-page check reported infection or an HTTP error.

1.16.1

• Base the five-step journey indicator only on unfinished scan batches and unresolved security findings.
• Stop protected themes and monitored files from incorrectly holding the interface on Step 3.
• Keep Step 2 current while additional 50,000-file batches remain, then mark the completed clean journey correctly.

1.16.0

• Count eligible files beyond the first 50,000 and display the exact number not yet scanned.
• Add Scan next 50,000 files so large sites can progress through the full file set in controlled batches.
• Retain and combine findings from completed batches until the full scan is finished.
• Restore the WordPress administrator checker as a visible Step 1 panel with account and approval counts.
• Keep unapproved administrators in Step 3 with separate approve and delete controls.

1.15.1

• Detect installed child themes and protect them from individual and bulk automatic removal, even when inactive.
• Recheck child-theme status on the server so removal cannot be triggered from an older scan result.
• Correct stored older findings while rendering so child-theme removal controls disappear immediately after updating.

1.15.0

• Replace the overlapping first and fuller scan choices with one clearly labelled Full security scan.
• Distinguish full-scan and quick-check coverage, show the actual safety limit and stop scheduled checks from overwriting the latest manual scan.
• Fix file counting at the 12,000 and 50,000 safety limits.
• Make the action indicator a fixed, immediately painted progress panel that remains visible from any step.
• Stop cache clearing from starting an unrelated filesystem scan and report which available cache layers were cleared.
• Make the affected-page setting optional and remove site-specific example paths and default URLs.
• Simplify Step 4 to one confirmed-incident bulk repair and show affected-page rechecking only when a page is configured.
• Rename stale cleanup and learning labels so each result describes the action that actually ran.

1.14.2

• Return administrators to the same findings area after approvals, deletions, repairs and other actions reload the page.
• Prefer the exact finding row when it still exists and fall back to the previous scroll position when an item was removed.

1.14.1

• Use the WordPress filesystem API for repairs, evidence backups and quarantine operations.
• Store new quarantine evidence in the WordPress uploads area instead of the content root.
• Tighten submitted-value sanitisation and escaped output for WordPress.org review.
• Run automated Plugin Check against the production plugin files only.

1.14.0

• Default alerts on fresh installations to the WordPress site administrator email.
• Let site owners explicitly control every alert recipient.
• Keep email delivery disabled on fresh installations until an administrator opts in.
• Preserve existing alert-recipient settings when upgrading managed sites.
• Add GitHub release packaging and an approval-gated WordPress.org deployment workflow.
• Declare compatibility through WordPress 7.1.

1.13.0

• Add lightweight monitoring for .htaccess, wp-config.php, wp-load.php, wp-settings.php, wp-blog-header.php, index.php and .user.ini.
• Check every four hours on the next WordPress request and send one email per distinct file change.
• Keep important-file warnings visible until an administrator recognises the change and approves the new trusted baseline.
• Never overwrite, repair or delete a changed important file automatically.

1.12.0

• Stop treating generic signature matches inside recognised installed plugins as confirmed quarantineable malware.
• Show the exact risky signature categories plus the installed plugin name and version.
• Keep known backdoors, gambling payloads and confirmed malicious fingerprints at critical/high severity.

1.11.1

• Prevent temporary 503 resource exhaustion by removing the synchronous 12,000-file scan from redirect repairs.
• Verify the exact .htaccess change immediately and clear only the repaired finding.
• Leave full filesystem scans as a separate deliberate action.

1.11.0

• Fingerprint each suspicious theme HTML rewrite rule found in .htaccess.
• Back up and remove only the selected exact rule, then verify and rescan.
• Replace misleading broad repair buttons on older scan results with a required refresh action.
• Report explicitly when a repair changed nothing instead of appearing to succeed silently.

1.10.0

• Add a confirmed delete action for unapproved administrator accounts.
• Reassign deleted-account content to the administrator performing the cleanup, then rescan.
• Block deletion of the current administrator, the last administrator and multisite super-administrators.

1.9.1

• Preserve valid dots in theme directory names during individual and bulk removal.
• Continue rejecting slashes and unsafe path characters before server-side eligibility checks.

1.9.0

• Display the active child theme and required parent as green protected rows.
• Add checkboxes, Select all and one confirmed bulk-removal action for inactive themes.
• Revalidate every selected theme on the server and rescan once after removal.

1.8.0

• Detect every inactive installed theme as a security-hygiene finding.
• Add a confirmed WordPress-native removal action followed by a fresh scan.
• Protect the active theme and its required parent from removal.
• Disable direct theme deletion on multisite and direct administrators to Network Admin.

1.7.1

• Move accepted Monitor decisions out of unresolved medium warnings into a blue informational state.
• Exclude monitored files from the Needs review count and email warning threshold.
• Continue reassessing monitored fingerprints whenever their file contents change.

1.7.0

• Add per-row and Select all checkboxes for eligible medium fingerprint findings.
• Apply Safe, Monitor or Malicious decisions to multiple selected findings with one confirmation.
• Restrict bulk decisions to non-actionable medium findings so confirmed threats cannot be bulk-approved accidentally.
• Identify clean placeholders belonging to absent import/export plugins as orphaned data rather than malware.

1.6.2

• Cross-check clean upload placeholders against WordPress’s installed-plugin registry.
• Suppress WP All Export, WP All Import and WP Import Export Lite placeholders only when the matching plugin is installed.
• Keep orphaned or unexplained upload folders visible for review.

1.6.1

• Recognise the actual WP All Export uploads directory name, wpallexport, and suppress clean index placeholders.
• Add a clear recommended action for uncertain findings and make Keep monitoring the safe default.
• Clarify that Safe and Malicious decisions require human verification.

1.6.0

• Add a fifth Threat Intelligence step with explicit Safe, Confirmed malicious and Keep monitoring decisions.
• Learn exact SHA-256 file fingerprints without self-modifying the plugin.
• Suppress approved-safe fingerprints, escalate approved-malicious fingerprints and reassess files whenever their contents change.
• Add an auditable learned-rule table with the ability to forget decisions.

1.5.0

• Redesign the admin screen as a clear Configure, Scan, Review, Fix and verify journey.
• Add recommended next actions, novice-friendly explanations and safer action labels.
• Move advanced notifications and administrator controls into expandable sections.
• Clearly distinguish confirmed fixable threats from manual-review findings.

1.4.1

• Stop classifying known WP All Import/Export index placeholders as high-risk malware when no malicious signature is present.
• Downgrade other unsigned PHP-in-uploads files to non-actionable manual review.
• Reserve quarantine controls for confirmed payloads and high-risk code signatures.

1.4.0

• Add Scan & check known URL and Fix chosen URL controls.
• Safely remove a matching same-site theme HTML rewrite for the configured URL with evidence backup.
• Quarantine confirmed gambling payload files, purge caches and verify the configured URL after repair.
• Add one-click administrator approval from the findings table and suppress future warnings for approved accounts.

1.3.1

• Display the full Luketom Compromise Review name in the WordPress admin sidebar.

1.3.0

• Standardise future branding as Luketom Compromise Review.
• Add a Known injection URL setting for the affected same-site page or path.
• Use the configured URL for uncached front-end verification after cleanup and cache purges.

1.2.2

• Refresh administrator findings immediately after saving the administrator allowlist.
• Remove approved administrators from Needs review without requiring another filesystem scan.

1.2.1

• Purge WordPress, LiteSpeed, WP Super Cache, WP Rocket and W3 Total Cache after cleanup actions.
• Add a cache-purge and uncached front-end contact-page verification action.
• Record the live verification result in the cleanup audit panel.

1.2.0

• Add an animated activity bar and stage messages during scans, repairs, quarantine and settings saves.
• Add a clear security summary with finding counts, files checked and scan coverage.
• Preserve a visible last-cleanup audit record showing repairs, quarantined paths and verification coverage.
• Explain partial scan coverage and the deep-scan limit.

1.1.0

• Add a one-click, evidence-preserving fix for confirmed incident redirects and payload files.
• Add direct Repair and Quarantine & rescan actions beside eligible findings.
• Remove noisy single-signature warnings that matched legitimate WordPress and plugin files.

1.0.1

• Send compromise alerts to both luke@luketom.com and tom@luketom.com.
• Support additional alert recipients and include medium-severity compromise indicators.

1.0.0

• Initial incident-response release.