Hanu Malware Guard

1.2.8

• Fixed: the file-editor activity-log hook read $_POST[‘file’]/$_POST[‘theme’] and used them to build a nonce-action string before sanitizing — even though the only sink is wp_verify_nonce() (a hash comparison, not an executable/output context), the fix follows “sanitize early” literally: both values now go through sanitize_text_field() immediately, before any use. This is a no-op for every legitimate request, since real file paths and theme slugs never contain the characters it strips.
• Hardened several other raw $_GET/$_SERVER reads in the firewall (author-enumeration check, REST user-enumeration check, malicious-pattern scanner) with explicit per-line justification for why they’re intentionally inspected unsanitized — each is used only for validation (is_numeric()), substring comparison, or pattern-matching against attack signatures, never stored or output without separate escaping.

1.2.7

• Fixed: WordPress.DB.PreparedSQLPlaceholders.LikeWildcardsInQuery — a LIKE clause value was baked directly into the query string instead of passed through a placeholder. The schema-migration column check now passes its LIKE value via %s, and uninstall.php’s options cleanup now runs the pattern through $wpdb->esc_like() (it contains a real % wildcard) before passing it as %s, rather than hardcoding the pattern in the SQL.

1.2.6

• Fixed: dozens of static-analysis findings from the official Plugin Check tool (WordPress.DB.PreparedSQL.InterpolatedNotPrepared / PluginCheck.Security.DirectDB.UnescapedDBParameter) where a table name was interpolated into a SQL string across several files. All custom-table queries now pass the table name through $wpdb->prepare()’s %i identifier placeholder instead — this also closes a few cases where an existing phpcs:ignore comment sat on the wrong physical line of a multi-line prepare() call and so wasn’t actually suppressing anything. %i requires WordPress 6.2+, so the minimum supported version is now 6.2 (previously 6.0).
• Fixed: the legacy quarantine-folder cleanup used raw unlink()/rmdir() instead of the WP_Filesystem API (Plugin Check ERROR-level finding); it now goes through WP_Filesystem, and silently skips cleanup if direct filesystem access isn’t available rather than failing.
• Fixed: two remaining input-handling findings — added the missing sniff code to an existing justified phpcs:ignore on the file-editor’s $_POST[‘file’] read, and added a missing phpcs:ignore (with rationale) to the read-only $_GET check behind the settings-saved admin notice.

1.2.5

• Fixed: quarantine no longer writes anything to the filesystem. Previously a quarantined file was moved into a protected subfolder under wp-content/uploads — the plugin directory guidelines don’t allow storing potentially-executable code there at all, even in a plugin-specific, .htaccess-protected folder, since that protection isn’t guaranteed to be honored (Nginx ignores .htaccess entirely; offloaded/CDN-backed uploads bypass it too). Quarantine now reads the file’s bytes into the database (base64-encoded) and deletes the original from disk; restoring writes it back from the database. Sites upgrading from an earlier version automatically migrate any already-quarantined files into the database and remove the legacy on-disk folder on first load after updating.

1.2.4

• Fixed: the activity-log entry for built-in theme/plugin file-editor usage was written before verifying the nonce, so a CSRF-forged request from a user with edit_themes/edit_plugins capability could produce a false log entry even though core’s own handler would go on to reject the edit. It now verifies the same nonce core checks (edit-plugin_{file} / edit-theme_{file}{stylesheet}) before writing anything, and simply skips logging on failure without interfering with core’s own request handling.

1.2.3

• Fixed: the Quarantine action could move a file out of wp-admin/wp-includes for core-integrity findings, which counts as modifying a WordPress core directory. Findings inside core directories can now only be reviewed or ignored from Scan Results; the UI explains that core files must be restored via Dashboard → Updates → Re-install Now, or replaced manually.
• Fixed: the activity-log entry for built-in theme/plugin file-editor usage could previously be triggered by any logged-in user, since it hooked core’s ajax action at a priority that ran before core’s own nonce/capability check. It’s now gated by its own capability check (edit_themes/edit_plugins) before logging anything.