If you suspect a WordPress malware infection, logs are one of the fastest ways to see what happened, when it happened, and which account or file was involved.
This guide explains how to check WordPress logs after malware so you can identify suspicious activity without guessing.
Why logs matter after a WordPress malware incident
Malware often leaves a trail across multiple layers of a WordPress stack: application logs, web server logs, PHP logs, database logs, and security plugin records.
By reviewing them in order, you can piece together the initial entry point, the malicious actions, and any persistence mechanisms the attacker may have added.
Logs are especially useful for spotting:
- Unexpected admin logins or failed login attempts
- File uploads, edits, or plugin installations at unusual times
- Requests to suspicious PHP files in
/wp-content/ - Unauthorized changes to
.htaccess,wp-config.php, or theme files - Outbound connections to unfamiliar domains
Which WordPress logs should you check first?
Start with the logs most likely to show the attack path.
Different hosting providers expose different log sets, but the priority order is usually similar.
1. Web server access logs
Access logs record every HTTP request to your site.
On Apache, these are often in access.log; on Nginx, in access.log as well, usually under the site or server configuration path.
These logs help you identify suspicious URLs, repeated POST requests, brute-force traffic, and requests to malware payloads.
2. Web server error logs
Error logs show PHP warnings, fatal errors, permission problems, and rewrite issues.
Malware sometimes triggers unusual errors after injection, file modification, or failed execution, making these logs useful for narrowing the timeline.
3. PHP logs
PHP logs can reveal script execution errors, deprecations, and direct hits to compromised files.
If your host separates PHP-FPM logs from the web server logs, review both.
4. WordPress security plugin logs
Plugins such as Wordfence, Sucuri Security, or iThemes Security often record login events, file changes, IP blocks, and malware scans.
These logs are valuable because they connect activity to WordPress users and administrators rather than just raw server requests.
5. Hosting and control panel logs
cPanel, Plesk, and managed WordPress dashboards may include file manager activity, FTP/SFTP session records, and system alerts.
These can show whether an attacker used a stolen credential or another access channel.
How to check WordPress logs after malware step by step
Use a structured approach so you do not miss the earliest signs of compromise.
The goal is to correlate log entries across timestamps, IP addresses, user agents, and file paths.
1. Establish the incident window
Start by identifying when the malware was discovered, then work backward.
If a security plugin flagged a file at 3:15 PM, review logs from several days before that point to catch the initial compromise.
- Note the first suspicious symptom
- Estimate the likely infection window
- Check for changes before and after the discovery time
2. Search for suspicious requests
In access logs, look for repeated requests to unusual URLs, especially those ending in .php inside uploads directories, temporary folders, or cache paths.
Attackers often hide payloads in locations where execution should not normally occur.
Common indicators include:
/wp-content/uploads/requests for PHP files- Long query strings with encoded data
- POST requests to unknown endpoints
- Admin-ajax abuse or strange
wp-login.phppatterns - Requests from a single IP with many failed attempts
3. Check for login anomalies
Review WordPress login records and server logs for successful logins from unfamiliar IP addresses, especially if the account had no recent legitimate activity.
Many compromises begin with credential theft, phishing, password reuse, or brute-force attacks.
Pay attention to:
- Admin logins at odd hours
- Repeated failed logins followed by a success
- Logins from countries or networks you do not normally use
- New user creation followed by privilege escalation
4. Review file change and execution clues
Although standard WordPress does not include comprehensive file integrity logs, your security plugin, host, or backup system may record file changes.
Compare timestamps in those records with web server and PHP logs to see whether the malware was uploaded, edited, or executed immediately after a request.
Focus on files commonly targeted by attackers:
wp-config.php.htaccess- Theme
functions.php - Plugin directories
- Files in
wp-content/uploads
5. Search for persistence behavior
Attackers often try to maintain access after the first compromise.
Logs can show repeated access to the same backdoor, scheduled task, or hidden admin endpoint.
If you see recurring requests after cleanup efforts, the malware may not have been fully removed.
What suspicious patterns should you look for?
When learning how to check WordPress logs after malware, you are looking for patterns, not just isolated events.
A single odd request may be harmless, but a cluster of related entries can reveal a compromise.
Common log indicators of compromise
- Requests to unfamiliar PHP files in upload directories
- Multiple login failures from one IP address
- Successful logins immediately after brute-force attempts
- POST requests to obscure admin or AJAX endpoints
- 404 errors for files that should not exist
- Encoded or obfuscated URL parameters
- Unexpected cron-like activity or repeated scheduled hits
File and code indicators
If logs point you to a suspicious file, inspect it for signs such as base64 encoding, long unreadable strings, eval-like behavior, hidden redirects, or code that fetches content from remote domains.
Malware often uses small loader scripts that appear harmless until they execute.
How to correlate logs across the stack
Correlation is what turns raw data into a useful incident timeline.
Match entries by timestamp, IP address, request path, and user account.
- Access log: shows the request that reached the server
- Error log: shows whether the request triggered a PHP or server error
- WordPress plugin log: shows whether a user, plugin, or scan detected activity
- File system record: shows what changed and when
For example, an access log might show a POST request to a suspicious plugin endpoint, the error log might show a PHP warning in that plugin, and a security plugin log might show a new admin account created minutes later.
Together, those events can reveal the compromise path.
Where do you find WordPress logs?
Log locations vary by hosting environment, but these are common places to check:
- Apache:
/var/log/apache2/or/var/log/httpd/ - Nginx:
/var/log/nginx/ - PHP-FPM: systemd journal,
/var/log/php-fpm/, or host-specific paths - cPanel: Metrics, Raw Access, Errors, and Security sections
- WordPress security plugins: plugin dashboard or exported logs
If you use managed WordPress hosting, the provider may hide filesystem access and expose logs in the control panel instead.
If you cannot locate them, ask support for access to access logs, error logs, and authentication logs for the incident window.
What if the logs are incomplete or rotated?
Many servers rotate logs frequently, so older evidence may be missing.
If that happens, use the remaining data to reconstruct the attack as much as possible.
- Check backup snapshots for file changes
- Review CDN and firewall logs if you use Cloudflare or a WAF
- Inspect WordPress database tables for new users, injected content, or unknown options
- Compare current files against a clean WordPress core installation
When logs are limited, external services often fill the gap.
A web application firewall, DNS provider, or security plugin may retain records longer than your hosting account.
How can logs help with cleanup and recovery?
Logs do more than confirm an infection.
They help you remove the right files, reset the right credentials, and close the actual entry point.
Use what you learn to:
- Delete malicious files and backdoors identified in the timeline
- Reset passwords for WordPress users, SFTP, SSH, and hosting accounts
- Patch vulnerable plugins, themes, or outdated core files
- Block abusive IP addresses or regions if appropriate
- Audit scheduled tasks, admin users, and database content
After cleanup, continue monitoring the same logs for repeated access to previously compromised endpoints.
If those requests persist, the attacker may still have a foothold.
How to make future log reviews easier
Once the site is clean, improve logging before the next incident.
Better logging shortens investigation time and reduces the chance of missing important evidence.
- Keep WordPress, plugins, and themes updated
- Enable a reputable security plugin with activity logging
- Centralize access and error logs when possible
- Use a web application firewall such as Cloudflare or Sucuri
- Set longer log retention during active investigations
- Restrict file permissions and disable direct PHP execution in uploads
Good logging will not prevent every attack, but it makes it much easier to see how a compromise happened and whether it is truly gone.