WP Perf Shield

=== WP Perf Shield === Contributors: menj Author URI: https://github.com/menj Tags: security, malware, scanner, hardening, remediation Requires at least: 5.8 Tested up to: 6.8 Requires PHP: 7.4 Stable tag: 1.4.91 License: GPLv2 or later License URI: https://www.gnu.org/licenses/gpl-2.0.html

Blocks wp-perf-analytics traffic-hijacking malware and renamed variants with activation blocking, scheduled scanning, forensics, hardening, and remediation tools.

== Description ==

WP Perf Shield is a focused WordPress security plugin built to detect and disrupt the wp-perf-analytics / session-manager malware family and related ClickFix render-hijacker variants such as native-render-toolkit, total-render-profiler, total-render-toolkit, pro-font-optimizer, site-speed-insights, advanced-asset-insights, page-seo-toolkit, starter-image-guard, auto-content-profiler, pro-cache-scanner, and total-database-optimizer.

It has grown well past that starting point. Detection now covers doorway kits, obfuscated packers, file-operation web shells that contain no executable code at all, PHP configuration files that switch hardening back off, and cloaked injectors that hide from administrators and crawlers alike while serving content to ordinary visitors. Source is normalised before matching, so malware that splits its identifiers across concatenated fragments to defeat scanners is caught anyway.

Beyond scanning, the plugin records what happens on the site - sign-ins, account creation, role elevation, plugin and theme activity, uploads - grouping related activity into incidents with a cumulative risk score.

It combines real-time plugin activation blocking, hourly malware scanning, behavioural monitoring, a tamper-evident event log, one-click remediation actions, forensic reporting, and hardening helpers for common post-compromise cleanup tasks.

= Key features =

• Blocks known malicious plugin slugs and renamed plugin patterns from activation.
• Enforces a site-policy banned-plugins list, separate from malware blocking, for ordinary plugins you choose not to run (WP File Manager and FileBird by default): refused on upload and activation, and deactivated if already present.
• Checks plugin file hashes using built-in MD5 indicators and custom MD5/SHA-256 hashes.
• Scrubs blocked plugins from both normal active plugin lists and multisite network-active plugin lists.
• Detects wp-content drop-in persistence loaders that restore mu-plugins/session-manager.php from wp_session_tokens_config.
• Scans plugins, themes, uploads, cache directories, language directories, MU plugins, wp-login.php, wp-cron.php, wp-config.php, .htaccess, cron hooks, and suspicious database options.
• Runs an hourly scheduled scan and sends rate-limited email alerts for critical findings.
• Provides one-click cleanup actions for known credential harvesters, exfil files, malicious options, tampered wp-cron.php, suspicious users, attachments, plugin folders, and theme files.
• Detects and cleans known removable malware patterns from wp-config.php with a pre-write backup and clean-baseline reset.
• Includes forensic reporting for media uploads, admin accounts, plugin timestamps, theme tampering, option anomalies, PHP backdoors, and WordPress core file integrity.
• Includes hardening actions for wp-config.php constants, .htaccess marker blocks, transient cleanup, session invalidation, and auth salt rotation.
• Stores structured logs in a PHP-guarded file under wp-content/plugins/wp-perf-shield/logs.
• Uses a modern minimalist admin UI with rounded panels, gradient accents, and mobile-friendly layout behavior.
• Enqueues admin CSS and JavaScript from assets/css/admin.css and assets/js/admin.js.
• Auto-deletes confirmed malware artifacts by default, with a Settings tab control for detect-only operation.
• Auto-blocks IP addresses that attempt to upload known malware ZIPs or renamed ZIPs containing known malicious folders, hashes, or payload markers.
• Protects sign-in against brute-force and low-and-slow subnet rotation: per-address and per-range thresholds with escalating repeat-offender blocks, permanent bans for attempts on non-existent accounts, a manual permanent range ban, XML-RPC multicall stripping, and optional Akismet reputation input and reporting — all without ever making the sign-in path wait on the network.
• Detects file-operation web shells by capability cluster - browsing, writing, deleting and uploading driven by raw request parameters - which contain no eval or shell_exec and so evade execution-focused scanning.
• Detects php.ini and .user.ini files that re-enable shell execution or remove open_basedir and disable_functions restrictions.
• Detects cloaked injectors that serve content to visitors while hiding from logged-in administrators and from search-engine, SEO and page-speed crawlers.
• Normalises split-literal obfuscation before matching, so identifiers written as glued fragments are found and every existing indicator keeps working.
• Blocks outbound requests carrying WordPress session cookies to external hosts, and quarantines the files responsible.
• Optionally blocks external post creation, editing and deletion through the REST API and XML-RPC (the auto-blogging and doorway-spam injection route), allowing only genuine dashboard publishing; off by default.
• Records behaviour and groups related activity into incidents with cumulative risk scoring.
• Renders its own documentation inside wp-admin.
• Autoloads its classes, so an ordinary front-end page view parses a fraction of the codebase.
• Includes a Diagnostics tab for attack attempts, hostile IPs, clearances, scan outcomes, Source Trace timeline, and operational status.
• Records upload-pathway diagnostics and restricts ZIP uploads to trusted administrator upload routes.

Detection is described by technique rather than by malware name, because names change on every build and techniques do not: obfuscated and self-extracting payloads, identifiers spelled character by character to keep them out of the file, unauthenticated file managers, executable PHP in directories that should hold only data, configuration dropped to weaken the server, and credentials or session cookies being sent off-site. That last one is also blocked at runtime, before the request leaves.

Findings from a kit that plants the same file in many directories collapse into one entry listing every location, so an intrusion reads as one problem rather than a dozen. == Installation ==

1. Upload the wp-perf-shield folder to /wp-content/plugins/.
2. Activate WP Perf Shield from the WordPress Plugins screen.
3. Open Tools > WP Perf Shield.
4. Run a manual scan from the Overview tab.
5. Review the Diagnostics, Forensics, Remediation, Hardening, Events, and Settings tabs as needed.

The plugin logs directory, wp-content/plugins/wp-perf-shield/logs/, must be writable by WordPress for event logging.

The PHP ZipArchive extension is recommended so WP Perf Shield can inspect inside renamed ZIP uploads before WordPress accepts them.

Additional project documentation is stored in the plugin doc/ folder. The root readme.txt remains in place for WordPress plugin metadata.

== Frequently Asked Questions ==

= Is this a general-purpose antivirus plugin? =

No. WP Perf Shield is intentionally focused on known wp-perf-analytics / session-manager style malware, related backdoors, suspicious persistence options, and common post-compromise cleanup workflows.

= Does deactivating the plugin remove protection? =

Deactivation stops the normal plugin hooks and scheduled scan. The plugin intentionally does not remove protective artifacts that may need to survive deactivation unless removed through the admin UI or full uninstall.

= Where are logs stored? =

Security events are stored in wp-content/plugins/wp-perf-shield/logs/events.php. The file is PHP-guarded to prevent direct web exposure, and the log directory includes an index.php and .htaccess to block direct access.

= Can I add custom indicators? =

Yes. Use the Settings tab to add custom blocked slugs and custom MD5 or SHA-256 file hashes.

= Does this support multisite? =

The blocker checks and scrubs both normal active plugins and network-active plugins. Site-specific behavior should still be tested in your own multisite environment before relying on it broadly.

= Can the plugin repair every infected file automatically? =

No. Some repairs require SSH, WP-CLI, SFTP, or hosting-panel access. The plugin provides manual commands and targeted actions where automatic cleanup would be unsafe.

== Screenshots ==

1. Overview with scan status, issue summary, readiness checks, and recent events.
2. Diagnostics tab with attack, clearance, scan, IP, Source Trace, and operational summaries.
3. Forensics report with trace data and manual SSH commands.
4. Remediation tab with targeted cleanup actions.
5. Hardening checklist for post-compromise security controls.
6. Events tab for the full retained security log.

== Changelog ==

= 1.4.91 = Adds the operator control for the remediation veto introduced in 1.4.88, which until now had no interface: the plugin could refuse to remove a target but no one could tell it to. Every finding gains a Mark Safe button with file or folder scope, and Diagnostics gains a panel listing everything protected, with its scope, reason and date, where paths can also be protected directly before they are ever flagged and any decision revoked later. Protection applies to every check including confirmed signature matches, since an operator is a better authority on their own code than any heuristic; findings remain visible and reported, but nothing acts on them automatically. Also adds a control to clear the automatic-removal halt, which previously required database access. This supersedes the 1.4.88 advice to disable automatic deletion.

= 1.4.90 = Calibrates automatic removal without reducing detection. Behavioural findings about files inside installed plugins, themes and mu-plugins are now reported for operator review rather than removed automatically, which is the rule that would have prevented the earlier outages. Confirmed signature matches are still removed, and behavioural findings in locations where executable PHP has no legitimate reason to exist - uploads, cache directories, plugin temp and log folders - are still removed, since a false positive there costs a stray file rather than a working site. WordPress core is never removed automatically and an operator Safe decision overrides everything. Also fixes the Overview screen, which hid the manual removal button for exactly those findings the policy had declined to act on, leaving them visible but unactionable; they now show a "Needs your review" status alongside a working control.

= 1.4.89 = Fixes WordPress core files being quarantined. A genuine wp-admin/setup-config.php was reported as critical credential exfiltration because it reads the database password field, which is its purpose as the installer; content heuristics now skip core entirely and leave core judgement to the existing checksum verification against the official WordPress API, which answers the question exactly rather than by inference. Also fixes the core protection introduced in 1.4.88, which only applied to detectors named on a fixed heuristic list and so did not cover this or any detector added later; the list is inverted to name confirmed signature detectors instead, so anything unrecognised is treated as inference and fails safe. Core is now never removed automatically regardless of detector confidence, since deleting a core file breaks a site rather than cleaning it, and the definition of core was widened to include index.php, xmlrpc.php and other files that do not begin with wp-.

= 1.4.88 = Critical remediation-safety release. Earlier versions could automatically quarantine legitimate software and repeat that action on subsequent scans even after an operator approved the file, because detection authorised removal directly and no operator veto existed. All destructive action now passes through a central remediation policy. Marking a target safe is an absolute veto on automatic removal, stored persistently, keyed by canonical path identity so it cannot be defeated by a different detector, a new finding ID, or an alternative spelling of the path, and checked again immediately before anything is moved. The policy fails closed when trust state cannot be read, refuses to let behavioural findings remove entire plugins or WordPress core files, and records Performance Lab, WP-Optimize, Abstract Box and Auto-justify Content as known-legitimate. If a safe target ever reaches the destructive gate, all automatic removal halts and the administrator is notified. Note: the dashboard control for marking targets safe is not yet included; until it ships, operators who need to protect specific files should disable automatic deletion in Settings.

= 1.4.87 = Strengthens the database-resident payload check against trivial evasion. Adversarial testing of a known-caught sample showed that two simple mutations - joining the deliberately split identifiers, and moving the encoded payload out of the source into a sibling file - each survived individually but together evaded every check, because the two detections that appeared to confirm one another in fact depended on exactly one precondition each. The check now keys on the mechanism the loader cannot drop: a decoder applied to get_option, the same option written back, and the result placed where it executes. The payload's physical location is no longer relevant. Verified against three legitimate option-decoding plugins, which remain unflagged, and covered by a new adversarial harness that rebuilds the mutations from a real sample on every run.

= 1.4.86 = Adds detection for plugins that store their executable payload in a WordPress option rather than in their own files, writing it back whenever the option is missing. Three ne