Scan Troubleshooting

Most scan problems fall into one of four buckets: a scan that never starts, a scan that starts but never finishes, a scan that finishes but produces nonsensical results, or a scan that produces correct results but with too many false positives. This article walks through each.

In This Article

• Scan never starts
• Scan stalls or never finishes
• Timeouts and resource limits
• Connectivity to VMP Security servers
• File permission errors
• Scan finishes but results look wrong

Scan never starts

If you click Start a new scan and the status never moves past “queued,” the most likely cause is the WordPress cron system. The scanner is dispatched as a cron event, so if cron is not running, the scan does not start.

Quick checks:

1. Open VMP Security → Tools → Diagnostics and look for the “WP-Cron” section. It tells you whether cron has run recently.
2. If it has not, your site may not be receiving enough traffic to keep WP-Cron firing. WP-Cron only runs when someone visits the site.
3. Install a real cron job that hits wp-cron.php every few minutes, and disable the built-in WP-Cron by adding define('DISABLE_WP_CRON', true); to wp-config.php. This is generally a good practice for any site beyond the smallest.

If WP-Cron is healthy but scans still do not start, check whether the site has a security plugin or host-level rule that blocks admin-ajax.php calls. The scanner uses admin-ajax to coordinate its stages.

Scan stalls or never finishes

A scan that gets to, say, 60% and then stops moving is almost always a stage that hit a timeout. The scanner divides its work into stages of bounded duration; each stage runs, exits, and queues the next. If a stage is killed by the host before it finishes, no “queue the next” signal is sent and the scan effectively pauses.

Fixes, in order of preference:

1. Open Scan Options and Scheduling, switch to the Limited Scan card, or enable Use low-resource scanning in Performance Options. This shortens each stage so it is more likely to fit inside the host timeout.
2. Reduce Maximum execution time for each scan stage to a value safely below your host’s PHP timeout. If your host kills processes after 30 seconds and a stage was set for 25 seconds, that is too close — cut it to 15.
3. Disable any advanced scan options you do not specifically need. The malware-signature scan and the content scan are particularly heavy.
4. If none of the above helps, run the scan from a server-side cron rather than from the WordPress admin. The scanner runs faster and without browser-imposed timeouts when invoked via cron.

Timeouts and resource limits

The most common limits that interfere with scans:

• PHP max_execution_time. Caps how long a single PHP request may run. Default is often 30s. Increase to 60-120s if your host allows it.
• PHP memory_limit. Caps how much memory a single PHP process may allocate. The scanner’s memory use is roughly proportional to the size of the file being scanned. Most sites are fine at 256MB; large media libraries may need more.
• Web-server request timeout. Apache, NGINX, and load balancers each have their own timeouts. These can kill a request even if PHP itself would let it continue.
• Process CPU limits. Shared hosts often kill processes that use too much CPU for too long, regardless of execution time. The Limited scan profile is designed to stay under these.

The Diagnostics page shows the current values for the limits the scanner cares about, so you can compare them against your stage configuration without leaving the admin.

Connectivity to VMP Security servers

The scanner reaches out to the VMP Security API for several things: fetching malware signatures, fetching firewall rule updates, and checking installed component versions against the vulnerability database. It also calls out to api.wordpress.org and downloads.wordpress.org to compare your installed core, theme, and plugin files against their official copies. If outbound HTTP is blocked, the scanner runs but with limited information.

Verify connectivity from Tools → Diagnostics. If outbound calls fail, check:

• The WP_HTTP_BLOCK_EXTERNAL constant. If set without WP_ACCESSIBLE_HOSTS including the VMP Security API hostnames (contact support for the current list), *.wordpress.org, and raw.githubusercontent.com, outbound HTTP from WordPress is blocked.
• Host-level firewall rules. Some shared hosts block outbound HTTP except to a small allowlist.
• DNS. If the host’s DNS resolver is mis-configured, the API hostname will not resolve.

File permission errors

Scans can fail with permission errors when:

• The web server cannot read a file in the WordPress installation. The scanner reports the file path and the error.
• The scanner cannot write to its own working directory in wp-content. This shows up as “cannot save scan progress.”

The right fix depends on your host. As a general rule, files owned by the web-server user should be readable by that user; the scanner’s working directory should be writable. If files are owned by a different user (e.g., installed by FTP as a different account), align ownership or permissions so the scanner’s process can read them.

Scan finishes but results look wrong

If the scan completes but the results are confusing — everything dismissed, everything flagged, or numbers that change between runs — check:

• Excluded paths. An overbroad exclusion can make many findings disappear. Open the Exclusions section and verify each entry is narrow.
• Stale ignore list. Findings you have previously marked as Ignored on the Scan results page do not reappear on the next run. If you suspect important issues are being hidden, open the Scan page and review the ignored findings filter.
• Different scan profile across runs. Comparing a Limited-profile scan against a High-Sensitivity scan will produce different totals; this is expected, not a bug.