WPAuditor User Documentation

What WPAuditor does

WPAuditor gives WordPress administrators a security visibility layer inside the WordPress dashboard. It records important site activity, highlights suspicious requests, helps investigate potentially dangerous files, verifies WordPress core files, and provides controlled hardening options.

WPAuditor is one part of a defense-in-depth program. It does not replace secure hosting, timely updates, tested backups, least-privilege access, multifactor authentication, or professional incident response.

Important limitations

• A detection is an indicator that needs review, not proof that a site is compromised.
• A clean scan cannot guarantee that a site is free from compromise.
• WPAuditor Free observes and records suspicious requests; it does not automatically block attacking IP addresses.
• Quarantining or restoring the wrong file can break the site. Always confirm a recovery path first.
• Restricting WordPress APIs can affect plugins, themes, mobile applications, remote management tools, and headless sites.

Free and Pro editions

“Yes” means the capability is included in the edition; the exact screens and options can vary by release and license plan. Consult the in-product interface and the official WPAuditor website for current plan availability.

Requirements

WPAuditor Free 1.0.0

• WordPress 6.0 or later.
• PHP 8.0 or later.
• An administrator account with the manage_options capability.
• Write access to the WordPress content and uploads areas so protected logs and quarantine data can be created.
• Working WordPress scheduled tasks for automatic log retention.
• Outbound HTTPS access to WordPress.org when running a core integrity scan.

WPAuditor Pro

Requirements vary by Pro release and enabled feature. Scheduled defense, alerting, and backup workflows require reliable WordPress scheduled tasks. Some integrations require outbound HTTPS, and encrypted backup features can require compatible server archive support. Check the requirements shown by your installed Pro version before relying on these features.

Installation and updates

Install WPAuditor Free

1. In WordPress, go to Plugins → Add New → Upload Plugin.
2. Select the WPAuditor Free ZIP file and choose Install Now.
3. Activate WPAuditor.
4. Open WPAuditor Free → Dashboard.
5. Open WPAuditor Free → Settings and confirm that event logging is active and the site timezone is correct.

You can also install the plugin using your normal managed deployment or SFTP workflow. Do not rename or modify plugin files unless instructed by support.

Install or upgrade to Pro

WPAuditor Free and WPAuditor Pro must not run at the same time. Before activating one edition, deactivate the other. A safe upgrade sequence is:

1. Take a current site and database backup.
2. Download any security logs you must retain.
3. Deactivate WPAuditor Free.
4. Install and activate the Pro package supplied through the official WPAuditor channel.
5. Complete licensing and any on-screen migration or setup steps.
6. Confirm that logging and scheduled jobs are healthy.

Do not share your license key. Obtain updates only from WordPress.org or an official WPAuditor source. Verify that backups and monitoring still work after every update.

Uninstalling

Before uninstalling, download any logs or evidence that must be retained and review quarantined files. Deactivation stops scheduled Free-edition cleanup tasks but should not be treated as a data-export or evidence-preservation process. Follow your organization’s retention and incident-handling policy before removing the plugin.

Quick start

Recommended Free setup

1. Open Settings and verify the timezone, event-log status, and scheduled cleanup status.
2. Set a retention period that meets your privacy, compliance, and investigation needs.
3. Open Dashboard and review the initial event and severity summaries.
4. Perform a normal test login, then confirm the activity appears under Security Events.
5. Open File Forensics and allow its initial scan to complete.
6. Run Core Integrity and review anything marked modified, missing, unexpected, or unreadable.
7. Evaluate Custom Login and API Access Control in a staging environment before enabling them on a production site.
8. Document who reviews alerts and findings, how often reviews happen, and when incidents are escalated.

Recommended Pro setup

Complete the shared checks above, then:

1. Configure alert recipients and test delivery.
2. Start automated defense in its observation or dry-run mode, if available in your version.
3. Review simulated decisions and tune the configuration before enabling live enforcement.
4. Add trusted administrative addresses or networks to exclusions where appropriate.
5. Validate rate limiting against normal users, APIs, payment callbacks, uptime monitors, and integrations.
6. Create and download a test backup, then verify the documented restore procedure in a safe environment.

Dashboard

WordPress adminWPAuditor Free → Dashboard

The Free dashboard summarizes the events in the selected period. It provides:

• Time-range and severity filters.
• Counts for all security events and for critical/high-severity events.
• Unique source counts and repeat-source context.
• Threat, event, source-IP, and targeted-endpoint summaries.
• Recent activity and an activity chart.
• Links into the filtered Security Events view.
• Automatic refresh while the page remains open.

Use a short time range during an active investigation and a longer time range for trend review. A high event count does not by itself mean the site is compromised; compare severity, source, target, timing, and the affected account or file.

Security Events

WordPress adminWPAuditor Free → Security Events

This page is the primary audit and investigation view.

Filter events

You can filter by:

• Event type.
• Severity.
• Start and end date.
• Category when following a category link from the dashboard.

Choose Apply Filters to update the list or Reset to return to the unfiltered view. The date range is interpreted using the WordPress timezone shown in Settings.

Read an event

Each row can include a timestamp, event name, category, source IP, HTTP method, severity, and request URI. Expand a row to see available detail such as the full URI, event details, user agent, and relevant MITRE ATT&CK or OWASP classification.

Values such as IP addresses and URIs can be copied for investigation. Treat copied event data as sensitive because it may contain personal data or confidential site information.

Live refresh

Use the live-refresh control during a short, active investigation. Turn it off when it is no longer needed to avoid unnecessary polling. Refreshing the view does not itself scan files or block a source.

What Free records

Depending on the event, WPAuditor Free can record:

• Successful and failed logins.
• User registration, deletion, profile changes, and role changes.
• Post creation, update, and deletion.
• Media uploads and deletion.
• Plugin activation and deactivation.
• Theme changes.
• Suspicious HTTP methods and requests associated with common web-application attack classes.
• Suspicious uploads, sensitive-file probes, reconnaissance, and obfuscated payload indicators.
• File-forensics, core-integrity, and quarantine activity.

WPAuditor redacts recognized password-like parameters, nonces, tokens, API keys, secrets, and Custom Login recovery values before logging. Redaction reduces risk but does not make logs public-safe. Administrators must still protect and review them.

Detection and severity

WPAuditor inspects request context for suspicious behavior and assigns a severity and category. It can also add recognized security-framework context to help analysts classify activity. Detection coverage includes broad classes such as injection, cross-site scripting, command or code execution attempts, file inclusion or traversal, unsafe object or XML behavior, suspicious uploads, sensitive-resource probing, reconnaissance, and encoded or obfuscated payloads.

This documentation deliberately omits detection expressions and exact decision rules.

Severity guide

Severity is a prioritization aid. A repeated set of lower-severity events can be more important than a single high-severity false positive.

File Forensics

WordPress adminWPAuditor Free → File Forensics

File Forensics looks for suspicious files in relevant WordPress locations. The Free edition combines two investigation perspectives:

• Upload threats: files in upload-related locations with characteristics that require review.
• Sensitive exposure: sensitive or unexpected files that may be exposed or misplaced.
• Correlated findings: files identified by more than one detector.

Opening the page starts a complete scan. A progress indicator remains visible while it runs. Results are temporary and user-specific; in Free 1.0.0 they remain available for approximately 30 minutes. Large result sets retain the highest-risk findings in the short-lived view, so use the available filters and narrower views when appropriate.

Review results

The summary shows total findings and useful groupings such as severity, detector, and correlation. Filter by detector or severity, or search by path, reason, rule label, or file hash. Each finding can include:

• Relative file location.
• Forensic evidence and reason for the finding.
• Risk score, severity, and confidence.
• Detected file type and modification time.
• A file hash when available.

Respond to a finding

1. Confirm whether a recent plugin, theme, media upload, deployment, or administrator action explains the file.
2. Compare the file with a trusted copy from the original vendor.
3. Take a backup and confirm you can recover the site.
4. Quarantine only when the file is suspicious and moving it will not remove a required site component.
5. Re-scan after remediation.

Do not permanently delete a file during the initial investigation. Quarantine preserves a controlled path to restoration.

WordPress Core File Integrity

WordPress adminWPAuditor Free → Core Integrity

This scanner compares installed WordPress core files with the official checksum manifest for the site’s WordPress version and locale. It also looks for unexpected files in core areas.

When an administrator starts a fresh scan, WPAuditor contacts the official WordPress.org checksum service. The WordPress version and locale are included in that request; WPAuditor logs and site content are not sent.

Result statuses

• Verified: the installed file matches the official checksum.
• Modified: the file exists but its checksum differs.
• Missing: an expected core file is absent.
• Unexpected: a file exists in a core area but is not part of the official manifest.
• Unreadable: the server could not read or hash the file.

You can filter by status and search by file path or hash. Modified and unexpected files may be eligible for quarantine. Missing files cannot be quarantined because no file is present.

Recommended response

• Confirm that the WordPress update is not currently running.
• Take a backup before changing core files.
• Prefer reinstalling the same WordPress version from a trusted source to repair modified or missing core files.
• Investigate unexpected files before quarantining them.
• Treat an unreadable file as a permissions or ownership problem until verified.
• Run a new integrity scan after repair.

Quarantining a core file can immediately break WordPress. Use it only when you understand the impact and have a tested recovery path.

Quarantine Manager

WordPress adminWPAuditor Free → Quarantine Manager

Quarantine moves a selected file away from its original location into protected storage. The manager lists available metadata such as an item identifier, original location, forensic source, size, file hash, quarantine time, and the administrator responsible.

Restore

Use Restore Selected only after verifying that a quarantined file is legitimate or required. If a file already exists at the original location, WPAuditor avoids silently overwriting it and restores the item with a distinguishable name. Review the result and resolve the duplicate manually.

Delete permanently

Use Delete Selected only after:

1. Confirming the item is malicious or no longer required.
2. Preserving any evidence needed for an investigation.
3. Confirming a clean replacement or backup exists.

Permanent deletion cannot be undone through WPAuditor.

Operational cautions

• Quarantining a plugin, theme, or core dependency can cause errors immediately.
• Restoring malicious code returns it to an executable site location.
• Do not download or open suspicious files on an unprotected workstation.
• If the site is actively compromised, preserve evidence and involve a qualified responder before making broad changes.

Custom Login

WordPress adminWPAuditor Free → Custom Login

Custom Login replaces the public WordPress login location with an administrator-selected path. It is disabled by default.

Before enabling

• Take a backup.
• Test on staging when possible.
• Confirm that administrators have an alternate recovery route through hosting or server access.
• Check password managers, single sign-on, security tools, caching, CDN rules, and remote management integrations.
• Choose a path that is difficult to guess and unrelated to your brand or staff names.

Enable and manage

1. Open Custom Login and choose Enable Custom Login.
2. Set and save a private custom path.
3. Store the resulting login address in an approved password manager.
4. Test it in a private browser window before signing out of the working administrator session.
5. Use Open Login to verify the route.

The page also provides private recovery access information. Treat it like a password: never publish it, place it in documentation, send it through unencrypted chat, or include it in a screenshot. Regenerate it if exposure is suspected.

Choose Reset to Default to disable the custom path and restore the native WordPress login location.

Custom Login reduces noise from basic automated login probes, but it is not a substitute for strong unique passwords, multifactor authentication, rate limiting, or account monitoring.

API Access Control

WordPress adminWPAuditor Free → API Access Control

Both controls are disabled by default and operate independently.

XML-RPC Access

Choose Block XML-RPC to disable WordPress XML-RPC requests and remove related discovery behavior. Choose Allow XML-RPC to restore access.

Before blocking it, confirm that you do not rely on a mobile publishing app, remote management service, legacy integration, pingbacks, or another tool that requires XML-RPC.

REST API Access

Choose Restrict REST API to block unauthenticated REST requests and remove public WordPress user endpoints. Authenticated requests remain available. Choose Allow Public REST API to restore public access.

Test this control carefully if the site uses WooCommerce, a headless frontend, forms, page builders, mobile applications, external publishing tools, or custom API clients. If a feature stops working, restore public access and identify the required routes before trying again.

Settings and log management

WordPress adminWPAuditor Free → Settings

General status

The General section shows:

• Plugin version.
• WordPress timezone and current local time.
• Scheduled cleanup status and next run.
• Event-log health.
• Log size and entry count.
• First and last recorded event.
• Current retention period.

Correct the WordPress timezone under Settings → General if timestamps do not match local time.

Download logs

Choose Download All Logs to export the current event log before cleanup, migration, or incident analysis. Store the download in access-controlled, encrypted storage and delete unneeded copies according to policy.

Manual cleanup

• Select a From and To date, then choose Delete to permanently remove matching entries.
• Choose Delete All Logs to permanently remove every current event.

Both actions are irreversible. Download required evidence first and confirm that deletion is allowed by your retention or legal-hold policy.

Retention policy

WPAuditor Free supports a retention period from 30 to 180 days and defaults to 90 days. Cleanup runs through WordPress scheduled tasks. Low-traffic sites or sites with disabled WP-Cron may run scheduled cleanup late; use a reliable system trigger for WordPress cron when timing matters.

Choose a period based on:

• Incident investigation needs.
• Applicable privacy and compliance obligations.
• Available disk space.
• Your organization’s documented retention policy.

Incident response workflow

1. Confirm and scope

• Record the site, time window, affected accounts, source addresses, endpoints, and severity.
• Look for related events before and after the initial alert.
• Determine whether a deployment, administrator, plugin, theme, or scheduled job explains the activity.

2. Preserve evidence

• Download relevant WPAuditor logs.
• Record times using the configured WordPress timezone and UTC where possible.
• Preserve suspicious files and hashes without opening them on an unsafe workstation.
• Do not clear logs or permanently delete quarantine items while an investigation or legal hold is active.

3. Contain

• Put the site in maintenance mode if active compromise is likely and business policy allows it.
• Revoke suspicious sessions and reset affected credentials from a known-clean device.
• In Pro, use carefully validated blocks or rate limits where appropriate.
• Quarantine confirmed suspicious files only after establishing a recovery path.

4. Eradicate and recover

• Replace compromised WordPress, plugin, and theme files with clean copies from trusted sources.
• Remove unauthorized users and review role changes.
• Rotate WordPress, hosting, database, SFTP/SSH, mail, CDN, and integration credentials as appropriate.
• Patch the original vulnerability.
• Restore from a known-clean backup when repair cannot be trusted.

5. Verify and learn

• Re-run file and core-integrity scans.
• Confirm normal frontend, admin, API, cron, email, and checkout behavior.
• Monitor closely for recurrence.
• Document the cause, timeline, response, and preventive changes.

For a serious compromise, contact your hosting provider and a qualified WordPress incident-response professional.

Privacy and data handling

WPAuditor logs are stored locally on the WordPress server and can contain personal or confidential information, including IP addresses, request URLs, user agents, usernames, content titles, country information when available, and file paths.

WPAuditor Free does not require a license or external account and does not include analytics, AI-provider transmission, external update callbacks, or edge-provider synchronization. A core integrity scan sends the installed WordPress version and locale to the official WordPress.org checksum service; it does not send WPAuditor logs or personal data.

Administrators are responsible for:

• Establishing a lawful basis for security logging where required.
• Disclosing relevant logging in the site privacy notice.
• Restricting WPAuditor access to authorized administrators.
• Choosing an appropriate retention period.
• Protecting downloaded logs and backup archives.
• Responding to data access, deletion, retention, and legal-hold obligations.
• Reviewing subprocessors and data flows for Pro integrations they enable.

Do not assume that redaction catches every secret in an arbitrary URL or event detail. Applications can place sensitive data in custom fields. Avoid credentials in URLs and review logs before sharing them.

Security guidance

• Grant administrator access only to people who need it.
• Use unique passwords and multifactor authentication for WordPress, hosting, and connected services.
• Keep WordPress, PHP, plugins, and themes supported and patched.
• Use HTTPS everywhere.
• Maintain tested, encrypted, off-site backups.
• Protect log and quarantine storage from direct web access. Apache and IIS protection may be created automatically; Nginx and custom web-server configurations require equivalent deny rules from the server administrator.
• Do not expose directory listings.
• Do not edit, execute, or browse quarantined files directly.
• Do not publish screenshots containing IP addresses, paths, URLs, event details, account names, license keys, integration tokens, or recovery information.
• Use staging for hardening, blocking, rate-limit, backup, and restore tests.
• Review findings manually; never use a security score as the sole basis for destructive action.

Troubleshooting

Event logging needs attention

1. Confirm the WordPress content area is writable by the web-server user.
2. Confirm sufficient disk space and inode availability.
3. Check whether a security policy, host control panel, or filesystem ownership rule blocks file creation.
4. Deactivate and reactivate the plugin after correcting permissions.
5. Review the server error log without posting it publicly.

Do not solve a permissions issue by making the entire WordPress tree world-writable.

No events appear

• Confirm logging is active under Settings.
• Check the selected date, severity, event, and category filters.
• Confirm the WordPress timezone.
• Generate a normal test event, then refresh the page.
• Check available disk space and the server error log.

Scheduled cleanup is not running

• Confirm WordPress scheduled tasks are enabled.
• Low-traffic sites may need a host-level scheduler to call WordPress cron reliably.
• Check for loopback-request or authentication restrictions affecting cron.
• Confirm the displayed next-run time after saving the retention policy.

File scan fails or times out

• Check PHP memory and execution-time limits.
• Confirm WordPress files are readable by the web-server user.
• Review host resource limits and the private server error log.
• Re-run during a low-traffic period.
• On very large sites, use narrower scan scopes when the interface offers them.

Scan results expired

Free file-forensics results are intentionally short-lived. Open File Forensics again to run a fresh scan. Filters and pagination operate on the currently stored result set.

Core checksums cannot be retrieved

• Confirm the server can make outbound HTTPS requests to WordPress.org.
• Check DNS resolution, TLS certificates, firewall rules, and proxy configuration.
• Confirm the installed WordPress version and locale are valid and supported by the checksum service.
• Try again later in case the service is temporarily unavailable.

Unexpected core findings after an update

Wait for the update to finish, clear relevant server caches, and run a fresh scan. If findings remain, compare them with a clean package for the exact installed version. Do not quarantine core files merely because a scan ran during an update.

Quarantine action fails

• Confirm the source file exists and is readable.
• Confirm the uploads/content area is writable and has free disk space.
• Check filesystem ownership and host security restrictions.
• Re-run the scan so the finding and file state are current.

Restored file has a different name

A file already existed at the original location, so WPAuditor avoided overwriting it. Compare both files, decide which is legitimate, and resolve the conflict using a trusted deployment or file-management workflow.

Locked out after enabling Custom Login

Use the private recovery information that was shown in the administrator interface or regain access through your approved hosting/server recovery process. Do not post the private URL publicly. After recovery, disable or reset Custom Login and test the site’s rewrite, cache, CDN, and security configuration before enabling it again.

A plugin or frontend feature broke after API restriction

Restore the affected API access control first. Identify the plugin, theme, mobile app, or integration that depends on public XML-RPC or REST access. Test compatibility in staging before reapplying the restriction.

Pro blocks legitimate users

Use your documented emergency access method, pause enforcement, remove the mistaken block, and review exclusions and traffic patterns. Check for shared networks, proxies, CDN configuration, webhooks, and bursty API clients before re-enabling live enforcement. Keep exact thresholds and trusted addresses private.

Pro alerts are not delivered

• Send a test alert from the product interface.
• Confirm recipients and the minimum severity.
• Check throttling and spam folders.
• Run built-in mail diagnostics if available.
• Verify DNS, firewall, SMTP, and WordPress mail-plugin configuration.
• Never paste SMTP passwords or full diagnostic output into a public ticket.

Where to get help

Use the support channel listed on the official WPAuditor website. Before contacting support, record the plugin version, WordPress version, PHP version, approximate incident time, and the exact on-screen error. Redact all secrets, personal data, private URLs, internal paths, IP addresses, and customer information unless support provides an approved secure upload method and specifically requests them.