WPAuditor Product Documentation

Entry point: WPAuditor → SIEM Dashboard

WPAuditor turns your WordPress installation into a lightweight Security Operations Center (SOC). Rather than relying on a single firewall rule or a periodic malware scan, WPAuditor operates continuously across every layer of your site — recording structured security events, detecting web application attacks in real time, scoring IPs by threat level, scanning files for obfuscation and tampering, and routing alerts to the right people when something goes wrong.

The plugin is built around a structured event log that every other subsystem reads from and writes to. The SIEM Dashboard, Active Defense System (ADS), Timeline, Threat Simulator, and Alert Center all share the same log pipeline — so every detection, block action, and site change is visible in one place and can be correlated across time.

Key design goals:

• Always-on logging — the event logger runs on every request without requiring cron jobs.
• Reversible actions — quarantine moves files rather than deleting them; temporary blocks expire automatically.
• Safe defaults — ADS starts in Dry Run mode; Global Rate Limiting is off by default; destructive actions require confirmation dialogs.
• Lightweight hosting compatibility — designed for shared hosting: uses WordPress transients and object cache for rate limiting counters, avoids heavy database queries on the critical path.
• MITRE ATT&CK alignment — detections are mapped to ATT&CK tactics and techniques, making events readable by analysts familiar with that framework.

Requirements

• WordPress 5.8 or later.
• PHP 7.4 or later (PHP 8.x fully supported and recommended).
• Write access to wp-content/logs/ for the SIEM log file. WPAuditor creates this directory on activation if it does not exist, and places a silent index.php inside to prevent directory listing.
• Write access to wp-content/ for quarantine storage and backup archives.
• Optional — WP-Cron: Required for ADS scheduled scans, log auto-clean, and scheduled backup jobs. Standard WordPress cron is sufficient; a real system cron improves reliability.
• Optional — Outbound HTTPS: Used by the Core File Integrity scanner (WordPress.org checksums API) and by the Cloudflare integration (IP block/unblock API calls).
• Optional — Object cache (e.g. Redis, Memcached): Global Rate Limiting uses wp_cache_get/set if available, falling back to WordPress transients. An in-memory object cache significantly improves counter accuracy under high traffic.
• Optional — ZipArchive with AES-256 support: Required for the encrypted Backup & Restore feature. WPAuditor checks for this at runtime and shows a clear error if the server does not support it.

Installation

1. Upload the WPAuditor plugin ZIP via Plugins → Add New → Upload Plugin, or extract it into wp-content/plugins/wpauditor/ via FTP/SFTP.
2. Click Activate Plugin. On activation, WPAuditor will:
   • Create wp-content/logs/ if it does not exist.
   • Generate a hidden, randomised log filename in the format .WPA_xxxxxxxxxxxx to prevent direct URL guessing.
   • Register default options for ADS thresholds, alert severity, cooldown timers, and other settings.
3. Navigate to WPAuditor → SIEM Dashboard and confirm the log file path is valid and writable. A green status badge confirms the logger is active.
4. Follow any on-screen onboarding prompts (timezone, alert recipients, basic options).

Updating: WPAuditor uses its own update system. When a new version is available, an update notice appears in the WordPress Plugins screen. Your license key must be active for updates to be delivered. License keys are stored encrypted in the WordPress database.

Quick Start Checklist

Follow these steps after activation to achieve a solid baseline security posture in under 15 minutes.

• 1. Confirm logging is active. Open WPAuditor → SIEM Dashboard and check for the green log-file status badge. Generate a test login (log out and log back in) and verify the LOGIN_SUCCESS event appears in the log table.
• 2. Configure alert recipients. Go to WPAuditor → Alert Center → Overview tab and enter your default notification email address. Set the minimum severity to HIGH to start. Optionally configure per-severity routing (e.g. send CRITICAL events to an on-call address).
• 3. Enable ADS in Dry Run. Open WPAuditor → Active Defense, select the Balanced preset, and turn on Dry Run mode before enabling blocking. Watch the "Recent Actions" ledger for 24–48 hours to understand what ADS would have blocked, then switch to live enforcement.
• 4. Run file integrity checks. Visit File Activity Monitoring, Obfuscated PHP Files, and File Permission Scanner in sequence. Quarantine any suspicious findings. Run WordPress Core File Integrity to verify no core files have been tampered with.
• 5. Create an encrypted backup. Go to WPAuditor → Backup & Restore, set a strong encryption password, and run an on-demand backup. Store the downloaded archive in a secure off-site location.
• 6. Apply hardening. Enable Custom Login URL to hide /wp-login.php, and consider disabling XML-RPC and restricting the REST API if you do not actively use them.
• 7. Test your setup. Use WPAuditor → Threat Simulator to run a brute-force simulation and confirm that the SIEM Dashboard charts update and an alert email is sent.

Event Logger & Log File

Used by: SIEM Dashboard, ADS, Timeline, Alert Center, Threat Simulator

The event logger is the core of WPAuditor. It hooks into WordPress at the init action and runs on every request, writing structured log lines to the hidden log file in wp-content/logs/. Every other WPAuditor subsystem reads from this same log file — making the log both the event source and the single source of truth for your site's security history.

What gets logged

• HTTP request context: HTTP method, full URI, query string, client IP address, user agent string, and (when available) country code from GeoIP/Cloudflare headers.
• Authentication events: Successful logins (LOGIN_SUCCESS), failed logins (LOGIN_FAILED), password resets (PASSWORD_RESET), and detected brute-force bursts (BRUTE_FORCE_ALERT).
• User lifecycle events: New user registrations (USER_REGISTER), role changes (ROLE_CHANGE), user deletions (USER_DELETED), and profile updates (PROFILE_UPDATED).
• Content changes: Post/page creates, updates, and deletions (POST_CREATED, POST_UPDATED, POST_DELETED); media uploads and deletions (MEDIA_UPLOADED, MEDIA_DELETED).
• Site configuration changes: Plugin activations and deactivations (PLUGIN_ACTIVATED, PLUGIN_DEACTIVATED); theme switches (THEME_SWITCH); changes to sensitive WordPress options such as siteurl, home, admin_email, permalink_structure, and users_can_register (SETTING_CHANGED).
• Web application attacks: SQL injection, XSS, Remote Code Execution (RCE), LFI/RFI, command injection, obfuscation/encoding patterns, WordPress-specific exploits, suspicious uploads, tool fingerprints, and sensitive file probes — all detected by the pattern engine described in the Detection section below.
• IP blocking actions: Automatic blocks triggered by ADS (IP_BLOCKED), manual blocks from the SIEM Dashboard, and unblock events (IP_UNBLOCKED).
• IP spoof attempts: When proxy headers (CF-Connecting-IP or X-Forwarded-For) are present but the connecting IP is not a trusted proxy, WPAuditor logs an IP_SPOOF_ATTEMPT event and uses the raw REMOTE_ADDR instead.
• Backup and restore operations: Backup job starts and completions (BACKUP_RUN, RESTORE).

Log file format

Each log line is structured for both human readability and machine parsing. The format is:

[TIMESTAMP] [EVENT_TYPE] IP=x.x.x.x cc=XX method=GET uri=/path ua="..." category=CATEGORY severity=LEVEL details...

The structured format means you can forward WPAuditor logs to an external SIEM (Splunk, Elastic, Graylog) or parse them with standard log tools. The log file location can be confirmed and troubleshot from the SIEM Dashboard status strip.

Log file protection: The log filename is randomised at activation (e.g. .WPA_a3f9c12e48d1), begins with a dot to hide it from many directory listings, and is stored in wp-content/logs/ alongside an index.php that silently exits on direct access. This prevents the log from being read via a browser URL even if directory listing is enabled.

IP Resolution & Proxy Handling

Used by: Event Logger, ADS, Global Rate Limiting

Accurate IP attribution is critical for blocking and audit trails. WPAuditor implements a multi-step IP resolution process that safely handles reverse proxies and Cloudflare without being trivially spoofable.

• Base address: WPAuditor always starts from $_SERVER['REMOTE_ADDR'] — the IP of the directly connecting server, which cannot be forged by a client.
• Trusted proxy detection: If REMOTE_ADDR falls within a known Cloudflare IP range (fetched from cloudflare.com/ips-v4 and ips-v6 and cached for 7 days), or within a custom trusted-proxy list (configurable via the wpauditor_trusted_proxies WordPress filter), the plugin trusts the proxy headers.
• Cloudflare header preference: When the connecting IP is a trusted Cloudflare proxy, CF-Connecting-IP is preferred over X-Forwarded-For because it contains a single clean IP rather than a list.
• XFF right-most extraction: For trusted proxies that send X-Forwarded-For, WPAuditor walks the list right-to-left and returns the right-most public IP that is not itself a trusted proxy — avoiding client-controlled leftmost entries.
• Spoof detection: If proxy headers are present but REMOTE_ADDR is not a trusted proxy, WPAuditor logs an IP_SPOOF_ATTEMPT event with the raw IP and XFF values, and uses REMOTE_ADDR for all security decisions. The spoof is logged only once per request to avoid log flooding.
• IPv6 support: Both IPv4 and IPv6 addresses are fully supported, including bracketed IPv6 notation and IPv6:port stripping.

SIEM Dashboard

Menu: WPAuditor → SIEM Dashboard

The SIEM Dashboard is the primary interface for monitoring your site's security posture. It reads directly from the WPAuditor log file and presents all event data in a filterable, searchable, paginated view — no separate database required.

Status section

At the top of the dashboard, a status strip shows whether the log file is valid and writable, whether ADS is enabled, and current alert configuration. This gives you a single-glance health check every time you open the dashboard.

KPI cards

Summary cards display total events, event counts broken down by severity (INFO through CRITICAL), and counts for the most important attack categories (WEB_APP_ATTACK, AUTH_FAIL, IP_BLOCKED) within the currently selected time range.

Charts (Chart.js)

The "Events Over Time" chart visualises attack and event volumes across a configurable date range. You can toggle between Line and Bar modes and optionally enable a Stacked view to see severity distribution per time bucket at a glance.

Filters

• Date range: Select a start and end date to narrow the view to a specific investigation window.
• Severity: Filter to one or more severity levels (INFO, NOTICE, WARNING, HIGH, CRITICAL).
• Category: Filter by event category (AUTH, WEB_APP_ATTACK, UNUSUAL_HTTP, PLUGIN, etc.).
• Search: Free-text search matched against IP, URI, username, user agent, and event details.

Log table

• Displays 100 rows per page with standard pagination controls.
• Mobile-friendly layout with no horizontal scroll on small screens.
• Per-row Expand / Collapse reveals the full URI, user agent, category, severity, and any extended details for the event. Long URIs are truncated by default to prevent layout breaks.
• Copy to clipboard buttons for IP addresses, URIs, and other common fields — useful during active investigations.
• Country flag icons next to IP addresses (where country code is available from Cloudflare or GeoIP headers).
• Inline Block IP action with a confirmation dialog. Clicking Block IP adds the address to the WPAuditor blocklist and optionally pushes a block rule to Cloudflare via API.

Live Logs

An optional Live On mode auto-refreshes the log table at a short interval during active investigations. A visual indicator shows when auto-refresh is active. Turn it off when you are done to avoid unnecessary server polling.

Timeline & Session Correlator

Menu: WPAuditor → Timeline

The Timeline view groups log entries into sessions and presents them in chronological order, making it easier to follow an attacker's full activity from initial probe to attempted exploitation. This is especially useful for post-incident analysis and for understanding the sequence of events leading up to a block or compromise.

How sessions are formed

WPAuditor groups log entries into sessions by matching on the combination of IP address, user agent string, and (where available) logged-in username. Events from the same IP and user agent within a contiguous time window are considered part of the same session. Sessions with a high cumulative severity score are surfaced prominently.

• Expandable session rows show the full ordered sequence of requests, logins, attack attempts, configuration changes, and block events for that session.
• Each session displays the first and last event timestamps, total event count, severity breakdown, and aggregate risk score.
• Country flag and IP address are shown at the session level for quick identification.
• Inline Block IP and Unblock IP actions are available directly from the session row.
• Time-based Chart.js visualisation shows attack bursts and dwell time across all sessions in the selected window.
• Pagination and filters (by IP, severity range, score range) keep the view responsive on busy sites with large log files.

Web App Attack Detection Engine

Feeds event categories: WEB_APP_ATTACK, UNUSUAL_HTTP, SENSITIVE_FILES, and more

WPAuditor's detection engine inspects every incoming request — query strings, request bodies, file upload parameters, and selected headers — against a library of PCRE regex signatures covering the OWASP Top 10 and WordPress-specific attack patterns. Detections are logged immediately and are eligible to trigger ADS scoring and alert emails.

Detection categories and example signatures

• SQL Injection (SQLi): Covers UNION SELECT (with spaces and URL-encoded variants), obfuscated UNION/**/SELECT, tautology payloads (OR 1=1, AND n=n), INSERT INTO, DROP TABLE, UPDATE ... SET, time-based blind injection (SLEEP(), BENCHMARK()), error-based injection (EXTRACTVALUE(), UPDATEXML()), INFORMATION_SCHEMA probes, GROUP_CONCAT(), LOAD_FILE(), and INTO OUTFILE. MySQL version-fingerprinting comments (/*!50000 UNION) are also detected.
• Cross-Site Scripting (XSS): Detects inline <script> tags, SVG onload handlers, abused HTML tags (<math>, <object>), srcdoc attribute injection, common event handlers (onfocus=, onerror=), javascript: URI schemes, <img onerror=>, <iframe> injections, document.cookie access, and attribute-level on* handler patterns.
• Remote Code Execution (RCE): Flags PHP execution functions in request parameters: exec(), system(), passthru(), shell_exec(), backtick operators, include($_GET[...])/assert($_GET[...]) patterns, and the PHP short echo tag.
• LFI / RFI (Local/Remote File Inclusion): Catches directory traversal sequences (../../), PHP stream wrappers (php://input, php://filter), data URI injections (data:text/html), include_path tampering, and remote HTTP/HTTPS includes.
• Command Injection: Detects shell metacharacter sequences including ; ls, ; cat, ; whoami, && id, && whoami, and || id.
• Obfuscation / Encoding: Identifies PHP obfuscation primitives: base64_decode(), eval(), gzuncompress(), str_rot13(), and urldecode() in request data.
• Tool Fingerprints & Recon: Matches common attacker tool indicators — phpMyAdmin and Adminer admin panel probes, /console/ path guessing, and cmd= / exec= parameter probing.
• WordPress-Specific Exploits: Flags known WordPress exploit vectors including admin-ajax.php abuse, RevSlider action parameter exploitation, and WordPress REST API user enumeration via rest_route=/wp/v2/users (both plain and URL-encoded variants).
• Suspicious File Uploads: Detects PHP webshell uploads disguised with dual extensions (e.g. shell.php.jpg), PHP files in upload parameters, and semicolon bypass techniques (e.g. file.php;.jpg).
• Sensitive File Probes: Detects attempts to access wp-config.php, .env files, .git metadata, .htaccess, and /etc/passwd-style paths.

All detections are assigned a severity (see the Severity Levels reference) and mapped to a MITRE ATT&CK tactic and technique ID. The full mapping is described in the Event Types & MITRE Mapping reference section below.

Active Defense System (ADS)

Menu: WPAuditor → Active Defense

The Active Defense System is WPAuditor's automated response engine. It periodically re-reads the log file, calculates a risk score for every unique IP address seen in the look-back window, and automatically applies temporary or permanent blocks to IPs that exceed configured thresholds.

Risk scoring

ADS scores each IP by summing weighted severity points from all of that IP's events within the configured look-back window (default: 30 minutes). Severity weights are:

• CRITICAL — highest weight, immediately pushes an IP toward the block threshold.
• HIGH — significant weight; multiple HIGH events within the window will trigger a temporary block.
• MEDIUM — moderate weight; accumulates with volume.
• LOW / INFO — minimal weight; routine events like successful logins do not score against the IP.

Neutral event types (INFO-level logins, media changes, routine admin activity) are excluded from scoring so that legitimate admin users are not penalised for normal work. URI-based boosts are applied for attack-pattern URIs, and normal /wp-admin/ access is explicitly excluded from boosts. Scores are capped at 100.

Thresholds and presets

• Temporary block threshold (default: 80) — when an IP's score reaches this value, ADS applies a temporary block for the configured block duration.
• Permanent block threshold (default: 90) — when an IP's score reaches this value, ADS adds the IP to the permanent blocklist.
• Cooldown (default: 10 minutes) — minimum time between repeated block actions for the same IP, preventing thrashing in log-intensive scenarios.
• Look-back window (default: 30 minutes) — how far back ADS reads when calculating scores. Shorter windows react faster; longer windows catch slow-scan attacks.

Three built-in presets are available:

• Safe — higher thresholds (permanent block at 97); blocks less aggressively; suitable for sites with many legitimate users making varied requests.
• Balanced — default configuration (permanent block at 90); recommended starting point for most sites.
• Aggressive — lower thresholds (permanent block at 85); blocks faster; suitable for high-attack-volume sites with low legitimate traffic variation.

IP exclusions

ADS automatically detects and excludes loopback addresses (127.x.x.x, ::1) and the server's own IP addresses from scoring and blocking. Server IP detection uses multiple methods: $_SERVER variables, DNS A/AAAA record resolution of the site hostname, and a UDP socket trick (no data sent) to determine the server's outbound IP. This prevents ADS from ever self-blocking the server.

Cloudflare integration

If you provide a Cloudflare API token and Zone ID in WPAuditor settings, ADS can push block rules directly to Cloudflare's firewall when it blocks an IP — meaning the block is enforced at the CDN edge before traffic reaches your server. Blocked IPs are shown with a Cloudflare sync status badge (Synced / Not Synced / Disabled) in the IP Blocklist page.

Dry Run mode

In Dry Run mode, ADS calculates scores and evaluates thresholds exactly as it would in live mode, but logs would-be actions to the "Recent Actions" ledger instead of actually blocking any IP. This is the recommended way to tune thresholds before enabling live enforcement.

Tip: Start in Dry Run, observe 24–48 hours of real traffic, review the Recent Actions ledger for false positives, adjust the preset or individual thresholds if needed, then enable live blocking.

Recent Actions ledger

The last ~30 ADS actions are shown in a ledger on the Active Defense page. Each entry shows the IP, the score that triggered the action, the action taken (temporary block, permanent block, or dry-run would-block), and the timestamp.

IP Blocklist

Menu: WPAuditor → IP Blocklist

The IP Blocklist is the central ledger of all blocked IP addresses — whether blocked manually from the SIEM Dashboard, automatically by ADS, or imported directly. It provides both a management interface and a real-time enforcement mechanism.

• Summary cards at the top show: Total Blocked, Cloudflare Synced, Not Synced, and Unknown status counts.
• Each blocked IP is listed with its block type (temporary or permanent), block timestamp, and Cloudflare sync status badge.
• Unblock actions remove the IP from the local blocklist and, if Cloudflare is configured, delete the corresponding Cloudflare firewall rule.
• Manual Add IP form lets you add individual addresses or CIDR ranges to the blocklist directly.
• Temporary blocks auto-expire after the configured block duration; expired temporary blocks are removed from the list automatically on the next ADS run.
• The blocklist is enforced on every WordPress request via the init hook — blocked IPs receive a 403 response before any WordPress content is served.

Global Rate Limiting

Menu: WPAuditor → Global Rate Limiting

Global Rate Limiting enforces a maximum request rate per IP address across your entire site using a sliding-window counter. It is designed to blunt automated scanners, credential-stuffing attacks, and denial-of-service probes before they can generate meaningful log noise.

How it works

On every WordPress request (hooked at init), the rate limiter retrieves or creates a per-IP counter keyed by a hash of the IP address. If the counter exceeds the configured limit within the time window, the IP is placed in a temporary ban and served a 429 Too Many Requests response with a Retry-After header. The Retry-After value accurately reflects the remaining ban duration. Counter state is stored in the WordPress object cache (wp_cache_get/set) if available, falling back to WordPress transients.

Configuration options

• Request limit (minimum 3) — maximum requests allowed per IP within the time window.
• Time window (minimum 3 seconds) — the sliding window duration in seconds.
• Ban duration (minimum 30 seconds) — how long a rate-limited IP is blocked before the counter resets.
• IP whitelist — comma, space, or newline separated list of IP addresses and CIDR ranges that are permanently exempt from rate limiting. Supports both IPv4 and IPv6, including CIDR notation. The whitelist is normalised and stored in a canonical form to avoid duplicates.

IP resolution

The rate limiter uses the same proxy-aware IP resolution logic as the event logger: Cloudflare and trusted-proxy headers are respected only when the connecting IP is verified as a trusted proxy. Self-hosted IPs (loopbacks and detected server IPs) are automatically excluded from rate limiting regardless of whitelist configuration.

Emergency disable

If rate limiting causes unexpected issues (e.g. a misconfigured whitelist blocks legitimate traffic), you can hard-disable the feature without accessing the admin panel by adding the following constant to wp-config.php:

define('WPAUDITOR_DISABLE_GLOBAL_RATELIMIT', true);

Threat Simulator (Dry Run)

Menu: WPAuditor → Threat Simulator (Dry Run)

The Threat Simulator lets you safely verify that WPAuditor's detection, SIEM charts, ADS scoring, and alert emails are all functioning correctly — without performing any real harmful actions or modifying site content. All simulated events are flagged in the log with a (simulated) marker.

Available simulations

• Brute-force attack: Generates a burst of LOGIN_FAILED events from the same IP to trigger a BRUTE_FORCE_ALERT and ADS scoring.
• SQL injection attempt: Injects a test SQL payload into the event pipeline to verify SQLi detection and categorisation.
• Generic scanner simulation: Produces a sequence of suspicious probe requests (tool fingerprints, sensitive file access attempts, unusual HTTP methods) mimicking an automated scanner.
• Remote Code Execution (RCE): Generates simulated parameters containing RCE-pattern strings to confirm the detection engine fires correctly.

After running a simulation, the Simulation Console appears below the run button, showing the events that were generated and logged. You can then open the SIEM Dashboard to verify chart updates, check the Alert Center for a triggered email, and review the ADS Recent Actions ledger to confirm scoring behaviour — all without touching your live site.

Note: The Threat Simulator is intended for use by administrators in a controlled testing context. Simulated events are clearly marked but do appear in SIEM charts and may trigger alert emails if alert thresholds are met.

Recently Modified Files (File Activity Monitoring)

Menu: WPAuditor → File Activity Monitoring

This scanner lists files under your WordPress installation that have been modified within a configurable look-back period (for example, the last 90 days), based on filesystem modification timestamps. The purpose is to surface unexpected file changes — plugin backdoors, injected scripts, or tampered theme files — among the noise of legitimate updates.

Scanned paths

• WordPress site root (ABSPATH)
• wp-content/ (plugins, themes, uploads, and all subdirectories)
• The uploads directory specifically, to catch suspicious files in media folders

The quarantine directory (wp-content/.quarantine) is automatically excluded from scan results to avoid noise from previously quarantined items. Common safe files (lock files, WPAuditor's own log file) are also excluded by default, and the exclusion list can be extended via the apply_filters hook.

Results and age badges

• Results are sorted newest-first by modification time.
• Each entry shows the full file path and an age badge: Most Recent (last 24 hours), Recent (last 7 days), Past Week (7–30 days), or Older.
• Suspicious or unrecognised files can be sent to Quarantine directly from this page. There is no direct delete action — quarantine is the only removal path, keeping the action reversible.

Obfuscated PHP Files Scanner

Menu: WPAuditor → Obfuscated PHP Files

This scanner detects PHP files that use obfuscation techniques commonly associated with web shells and malware droppers. It uses a multi-signal scoring model rather than a single pattern match, reducing false positives on legitimate minified or encoded code.

Detection signals

• Direct execution calls: Presence of eval(), assert(), create_function(), preg_replace() (with code execution flags), preg_replace_callback(), and similar functions.
• Chained decoder + executor patterns: Nested calls like eval(base64_decode(...)), eval(gzinflate(...)), assert(str_rot13(...)) — the canonical web shell structure.
• Encoding primitives in isolation: base64_decode(), gzuncompress(), gzinflate(), str_rot13(), pack().
• High signal counts: Files are ranked by the number of distinct suspicious signals found. The results are sorted descending by signal count so the most suspicious files appear first.

WordPress core file whitelisting

Before displaying results, WPAuditor fetches the official WordPress core file checksums from api.wordpress.org/core/checksums/1.0/ for your installed version and locale. Any PHP file that matches a known good core checksum is silently excluded from the obfuscated PHP results — ensuring that WordPress core files which legitimately use encoding functions (such as wp-includes/sodium_compat/) do not create false-positive noise.

Results show the file path and signal count. Suspicious files can be moved to Quarantine directly from this page. There is no direct delete action.

File Permission Scanner

Menu: WPAuditor → File Permission Scanner

Insecure file permissions — particularly world-writable files and directories — are a common vector for file-based attacks. This scanner detects permissions mismatches across your WordPress installation and offers one-click remediation where the server environment permits.

• Scans for files and directories with overly permissive modes, flagging 0777 (world-writable + executable), 0666 (world-writable), and other insecure combinations.
• Displays the current permission mode alongside the recommended mode for each flagged item.
• The Fix permissions action calls chmod() to apply the recommended mode. If the server environment prevents the fix (e.g. different owner, restricted hosting), a clear error message is shown explaining why the fix failed.
• Useful after migration or theme/plugin installations that sometimes set broad permissions during deployment.

WordPress Core File Integrity

Menu: WPAuditor → WordPress Core File Integrity

This scanner verifies your WordPress core files against the official checksums published by WordPress.org, providing high-confidence detection of core file tampering — including files that have been modified to contain injected code, files that have been replaced entirely, and unexpected PHP files placed inside core directories.

How it works

1. WPAuditor fetches the official checksum list for your installed WordPress version and locale from https://api.wordpress.org/core/checksums/1.0/?version=X.Y.Z&locale=XX.
2. It computes the MD5 hash of each file in your WordPress root, wp-admin/, and wp-includes/ directories.
3. It compares each computed hash against the expected hash from the checksums list.

Result categories

• Modified files: Core files whose hash does not match the expected value — a strong indicator of tampering or injection.
• Missing files: Core files listed in the checksums that are absent from your installation — possible deletion by an attacker or failed update.
• Extra / unexpected files: PHP files found inside core directories (wp-admin/, wp-includes/) that are not in the official checksums list — a common indicator of web shell placement in core directories.

Results can be filtered, exported, and re-scanned on demand. Unexpected PHP files inside core folders can be moved to Quarantine directly from the results view. For modified or missing core files, the recommended action is to re-download the affected files from WordPress.org or run a WordPress core reinstall via Dashboard → Updates → Re-install now.

Quarantine Manager

Menu: WPAuditor → Quarantine Manager

Quarantine is WPAuditor's safe-removal mechanism. Rather than deleting suspicious files immediately (which destroys evidence and is irreversible), quarantine moves files to a protected directory under wp-content/.quarantine/ and makes them non-executable. This lets you investigate files before deciding to restore or permanently delete them.

• Central listing of all quarantined files, showing the original file path, the scanner that triggered the quarantine action (File Activity Monitoring, Obfuscated PHP Scanner, Core Integrity, or manual), and the quarantine date.
• Quarantined files are moved — not copied — so they are no longer accessible from their original location and cannot be executed by the web server.
• Restore: Returns a quarantined file to its original path. Use this when investigation confirms the file is legitimate. You will be prompted to confirm before the restore proceeds.
• Delete permanently: Irrevocably removes the quarantined file from disk. Use this only after investigation confirms the file is malicious and you no longer need it for forensic purposes.
• The quarantine directory itself is excluded from all WPAuditor file scanners to prevent quarantined files from generating new scan results.

Design principle: All scanner pages in WPAuditor lead to Quarantine rather than direct deletion. Quarantine is always the first step — deletion is a separate, deliberate second action. This reduces the risk of accidentally destroying a legitimate file.

Backup & Restore

Menu: WPAuditor → Backup & Restore

WPAuditor's Backup & Restore feature creates complete, AES-256 encrypted ZIP archives of your entire WordPress site — database and filesystem together — so you can recover quickly after a compromise, a failed update, or accidental data loss.

Creating a backup

• Backups include both the MySQL database (full SQL dump) and the filesystem (all files under the WordPress root).
• The archive is encrypted with AES-256 using a password you supply at backup time. The password is never stored — you must supply it again at restore time.
• Backup jobs are executed asynchronously via WP-Cron (wpauditor_run_backup_job) to avoid HTTP timeouts on large sites. WPAuditor kicks the cron scheduler immediately after scheduling the job to minimise delay on hosts with infrequent cron triggering.
• Completed backup archives are stored in a non-public directory under wp-content/ and are available for download for 60 minutes after creation, after which they are automatically removed from the server. Download your backup immediately after the job completes.
• WPAuditor checks for ZipArchive AES-256 support at runtime and shows a clear error message if the server does not support encrypted ZIPs — allowing you to address the server configuration before relying on backups.

Restoring from a backup

• Upload the encrypted ZIP archive through the Restore form and supply the decryption password.
• WPAuditor validates the password and archive integrity before starting the restore job.
• The restore is executed asynchronously via WP-Cron (wpauditor_run_restore_job). The site enters WordPress maintenance mode during the restore operation.
• Restore overwrites both site files and the database. A confirmation dialog is shown before the process begins, warning that the operation is irreversible.
• Restore upload files are stored in a temporary location with a randomised filename and cleaned up after the job completes or fails.

Best practice: Run an on-demand backup before any major plugin update, theme change, or migration. Store the downloaded archive in a secure off-site location (cloud storage, local machine) — do not rely solely on the 60-minute server copy.

Custom Login URL

Menu: WPAuditor → Hardening → Custom Login URL

Moving your WordPress login page away from the well-known /wp-login.php path eliminates the vast majority of automated credential-stuffing and brute-force bots that target the default URL without adapting their scanner configuration.

• When enabled, /wp-login.php returns a 404 response to all visitors.
• The default custom slug is kitchen-key, making your login available at e.g. https://example.com/kitchen-key/. You can change this slug to any custom value at any time.
• A secret bypass parameter is available as a fallback in case your CDN, caching layer, or WAF misbehaves with the custom URL. The parameter is displayed only in the WPAuditor settings panel and should be kept private.
• A clear status notice on the settings page shows whether the feature is ENABLED or DISABLED, and displays your current custom login URL for reference.
• Emergency disable via wp-config.php: add define('WPAUDITOR_DISABLE_LOGIN_RENAME', true); to restore access to /wp-login.php without touching the admin panel — useful if you are locked out.

Important: After enabling this feature, update any saved browser bookmarks, password manager entries, and deployment scripts that reference /wp-login.php directly.

Disable XML-RPC

Menu: WPAuditor → Hardening → Disable XML-RPC

WordPress's XML-RPC interface (/xmlrpc.php) is a legacy remote publishing API that is rarely needed by modern sites. It is a well-known attack surface because it supports credential authentication in every request and can be abused for amplified brute-force attacks (testing hundreds of passwords in a single HTTP request via the system.multicall method).

• When enabled, WPAuditor blocks all requests to /xmlrpc.php, returning a 403 or 404 response.
• Disabling XML-RPC does not affect the WordPress REST API, the Block Editor (Gutenberg), or standard admin panel access.
• You may need to keep XML-RPC enabled if you use applications that rely on it: some mobile publishing apps, certain Jetpack features, ManageWP, MainWP, and similar remote management services. Check your dependencies before disabling.
• The feature can be toggled on or off from the WPAuditor UI at any time without requiring a WordPress reinstall or manual file editing.

REST API Hardening

Menu: WPAuditor → Hardening → Disable REST API

The WordPress REST API exposes site information — including user lists, post content, and plugin metadata — to unauthenticated requests by default. Restricting anonymous access limits the information available to attackers during reconnaissance and reduces exposure to REST API–based exploits.

• When enabled, unauthenticated requests to /wp-json/ endpoints are blocked and return an appropriate error response.
• Authenticated requests (logged-in admins, editors, and other users with valid cookies or application passwords) continue to work normally — this does not break the Block Editor or admin-side functionality.
• All blocked REST API attempts are logged as events in the SIEM Dashboard so you can monitor for REST API probing activity.
• Review which plugins and themes in your installation depend on public REST API access before enabling this restriction. The WooCommerce storefront, some page builders, and headless WordPress setups commonly require public REST API access.

Alert Center & Email Routing

Menu: WPAuditor → Alert Center

The Alert Center controls when, how, and to whom WPAuditor sends security notifications. It is organised into four tabs: Overview, Routing & Throttling, SMTP, and Tests & Diagnostics.

Overview tab

• Enable / Disable alerts: A master switch for all email notifications. The status strip shows ENABLED or DISABLED at a glance.
• Minimum severity: Only events at or above this severity level generate alert emails. Default is HIGH. Setting this to CRITICAL reduces alert volume significantly; setting it to WARNING or lower increases it. Choose based on your team's capacity to act on alerts.
• Default recipients: Comma-separated list of email addresses that receive all alerts meeting the minimum severity threshold.

Routing & Throttling tab

• Per-severity routing: Optionally specify separate recipient lists for each severity level (INFO, NOTICE, WARNING, HIGH, CRITICAL). If left blank for a level, the default recipients list is used.
• Alert cooldown: Minimum time in seconds between sending identical alerts (same event fingerprint). This prevents alert storms during large-scale attacks where the same type of event fires repeatedly. Set to 0 to disable throttling entirely. Default is 300 seconds (5 minutes).

SMTP tab

• WPAuditor includes a built-in SMTP client (via PHPMailer) as an alternative to WordPress's default wp_mail() function, which relies on PHP's mail() and often has poor deliverability on shared hosting.
• Configure SMTP host, port, encryption (TLS/STARTTLS/None), and authentication credentials (username and password).
• If you use a dedicated SMTP plugin (WP Mail SMTP, Post SMTP, etc.), leave the built-in SMTP disabled to avoid conflicts.

Tests & Diagnostics tab

• The Run SMTP Diagnostics button performs a multi-step connection test: DNS lookup, TCP connection check, SMTP banner grab, STARTTLS negotiation, and SMTP AUTH verification. Results are displayed inline so you can diagnose deliverability issues without leaving WordPress.
• A Send Test Alert option dispatches a test notification at a selected severity level to confirm end-to-end alert delivery.

Log Retention & Auto-Clean

Menu: WPAuditor → Settings → Logs tab

As your site accumulates security events, the log file grows. Log Retention settings let you control how long events are kept, balancing audit trail completeness against disk usage.

• Manual clean: A Clean Logs operation removes all log entries older than a date you select. A JavaScript confirmation dialog is shown before entries are permanently removed.
• Automatic clean (WP-Cron): Schedule automatic log cleanup to run periodically. For example, deleting logs older than 15 days. WPAuditor respects the WordPress timezone setting for all date comparisons — events are evaluated against your local timezone, not UTC.
• Improved scheduling: As of v1.4.1, the auto-clean scheduler uses improved WP-Cron handling to ensure scheduled cleans fire reliably even on sites with infrequent cron invocations.

Recommendation: Keep at least 30 days of logs available for meaningful security investigation and incident correlation. If disk space is a concern, use the auto-clean scheduler rather than disabling logging entirely.

Severity Levels

WPAuditor normalises all events into five severity levels. Severity is used by the Alert Center (minimum threshold for email), ADS (weighted scoring), SIEM Dashboard filters, and Timeline session risk scoring.

• INFO — Routine operational information. Examples: successful login, plugin activated, post created, media uploaded. These events are logged for audit trail completeness and do not typically require action.
• NOTICE — Noteworthy events that may warrant a second look but are often benign. Example: a login from a new IP address, a profile update, a sensitive WordPress option change.
• WARNING — Suspicious activity or misconfiguration that should be reviewed. Examples: obfuscation patterns in request parameters, unusual HTTP methods, sensitive file probes.
• HIGH — Clearly malicious or high-risk events that very likely require investigation. Examples: SQL injection attempt, XSS payload, command injection, suspicious file upload, brute-force alert, IP block action.
• CRITICAL — Severe incidents or high-confidence indicators of compromise. Examples: Remote Code Execution (RCE) attempt, Local/Remote File Inclusion (LFI/RFI) attempt. CRITICAL events should be treated as active incidents until ruled out.

The severity assigned to each event type is determined by the wpa_map_severity() function in the MITRE/severity mapping file. The mapping is fixed — it is not currently user-configurable — to ensure consistent ADS scoring across installations.

Event Types & MITRE ATT&CK Mapping

Below is a complete reference of WPAuditor event types, their default severity, and their mapping to MITRE ATT&CK tactics and techniques. Events not listed default to INFO severity.

Web Application Attacks

• SQL_INJECTION — Severity: HIGH. MITRE: Initial Access / T1190 (Exploit Public-Facing Application).
• XSS — Severity: HIGH. MITRE: Initial Access / T1190.
• REMOTE_CODE_EXECUTION — Severity: CRITICAL. MITRE: Initial Access / T1190.
• LFI_RFI — Severity: CRITICAL. MITRE: Initial Access / T1190.
• COMMAND_INJECTION — Severity: HIGH. MITRE: Initial Access / T1190.
• WORDPRESS_EXPLOITS — Severity: HIGH. MITRE: Initial Access / T1190.
• OBFUSCATION_ENCODING — Severity: MEDIUM (WARNING). MITRE: Defense Evasion / T1027 (Obfuscated Files or Information).
• ENCODED_PAYLOAD — Severity: MEDIUM. MITRE: Defense Evasion / T1027.
• TOOL_FINGERPRINTS — Severity: LOW. MITRE: Reconnaissance / T1595 (Active Scanning).
• UNUSUAL_HTTP_METHOD — Severity: MEDIUM. MITRE: Reconnaissance / T1595.
• SENSITIVE_FILES — Severity: MEDIUM. MITRE: Credential Access / T1552.001 (Credentials in Files).
• SUSPICIOUS_UPLOADS — Severity: HIGH. MITRE: Persistence / T1505.003 (Server Software Component: Web Shell).
• RAW_UPLOAD_ATTEMPT — Severity: MEDIUM. MITRE: Command and Control / T1105 (Ingress Tool Transfer).

Authentication & Identity

• LOGIN_SUCCESS — Severity: INFO. MITRE: Initial Access / T1078 (Valid Accounts).
• LOGIN_FAILED — Severity: LOW. MITRE: Credential Access / T1110 (Brute Force).
• BRUTE_FORCE_ALERT — Severity: HIGH. MITRE: Credential Access / T1110.
• PASSWORD_RESET — Severity: MEDIUM. MITRE: Persistence / T1098 (Account Manipulation).
• IP_SPOOF_ATTEMPT — Severity: HIGH. Logged when proxy headers are present from an untrusted connecting IP.

User Lifecycle

• USER_REGISTER — Severity: INFO. MITRE: Persistence / T1136.001 (Create Account: Local Account).
• ROLE_CHANGE — Severity: MEDIUM. MITRE: Privilege Escalation / T1098 (Account Manipulation).
• USER_DELETED — Severity: MEDIUM. MITRE: Impact / T1531 (Account Access Removal).
• PROFILE_UPDATED — Severity: INFO. No MITRE mapping (routine activity).

Site Configuration & Content

• PLUGIN_ACTIVATED — Severity: INFO. MITRE: Persistence / T1505 (Server Software Component).
• PLUGIN_DEACTIVATED — Severity: INFO. MITRE: Defense Evasion / T1562.001 (Impair Defenses: Disable or Modify Tools).
• THEME_SWITCH — Severity: INFO. MITRE: Persistence / T1505.
• SETTING_CHANGED — Severity: MEDIUM. Logged for: siteurl, home, admin_email, permalink_structure, users_can_register.
• POST_CREATED / POST_UPDATED — Severity: INFO. MITRE: Impact / T1491.001 (Defacement: Internal Defacement).
• POST_DELETED — Severity: INFO. MITRE: Impact / T1485 (Data Destruction).
• MEDIA_UPLOADED / MEDIA_DELETED — Severity: INFO. No MITRE mapping.

Defensive Actions

• IP_BLOCKED — Severity: HIGH. Logged when an IP is added to the blocklist (manually or by ADS). No MITRE mapping (defensive action).
• IP_UNBLOCKED — Severity: INFO. Logged when a block is removed.
• BACKUP_RUN — Severity: INFO. Logged when a backup job starts or completes.
• RESTORE — Severity: INFO. Logged when a restore job is initiated.

All event lines are structured and machine-parsable. You can forward WPAuditor log files to external SIEM platforms (Splunk, Elastic, Graylog, etc.) using standard file-based log shipping. The MITRE ATT&CK technique IDs can be used to correlate WPAuditor events with other data sources in your security toolchain.

Emergency Constants (wp-config.php)

Several WPAuditor features support a hard-disable constant in wp-config.php. These constants bypass the database-stored settings and take effect immediately on every request — useful when you are locked out of the admin panel or need to quickly disable a feature that is causing issues.

• WPAUDITOR_DISABLE_LOGIN_RENAME — Disables the Custom Login URL feature and restores access to /wp-login.php.

  define('WPAUDITOR_DISABLE_LOGIN_RENAME', true);

• WPAUDITOR_DISABLE_GLOBAL_RATELIMIT — Disables Global Rate Limiting entirely, allowing all traffic regardless of rate.

  define('WPAUDITOR_DISABLE_GLOBAL_RATELIMIT', true);

Add these constants to wp-config.php above the line /* That's all, stop editing! */. Remove them once the situation is resolved to restore normal WPAuditor behaviour.

Back to top ↑