A Wordfence scan may start normally, complete several initial checks, and then stop making progress. The scan page continues to show that the scan is running, but no new activity appears in the log.

After several minutes, Wordfence may display the following warning:

The current scan looks like it has failed. Its last status update was several minutes ago. You may continue to wait in case it resumes or stop and restart the scan.

Restarting the scan may produce the same result. It starts successfully but never reaches the final stage.

This problem is commonly mistaken for a simple PHP execution-time or memory-limit issue. However, when the scan starts but fails partway through, the more likely cause is that Wordfence cannot successfully launch or resume the next scan stage.

Wordfence performs a scan through a sequence of separate PHP requests. After completing a small amount of work, it saves its progress and causes the server to connect back to the website to launch the next stage. A failure in this loopback process can leave the scan appearing to run forever. le Server Configuration

Consider a WordPress website using the following environment:

WordPress version: 7.0.2
Wordfence version: 8.2.2
Hosting provider: Tophost.it
Web server: Apache
PHP version: 8.4.8 64-bit
PHP SAPI: CGI/FastCGI
max_input_variables: 1000
max_execution_time: 120 seconds
memory_limit: 256M
max_input_time: 120 seconds
upload_max_filesize: 32M
post_max_size: 32M
Wordfence scan type: Limited

The following troubleshooting steps may already have been attempted:

• Changing the maximum execution time for each scan stage
• Increasing Wordfence’s requested memory
• Enabling and disabling remote scan starting
• Enabling Wordfence debugging mode
• Running the Wordfence connectivity test
• Temporarily disabling a login-hiding or security plugin
• Switching the scan type to Limited
• Confirming that /wp-admin/admin-ajax.php displays 0

Despite those changes, the scan still starts and then becomes stuck.

Most Likely Cause

For this specific behavior, the most likely causes are:

1. The hosting server terminates a PHP or FastCGI process before Wordfence completes the current stage.
2. The server cannot connect back to the website to resume the next scan stage.
3. WP-Cron is disabled, delayed, or not running reliably.
4. ModSecurity or another server firewall blocks a Wordfence callback.
5. Cloudflare, IPv6 routing, or DNS sends the callback through an unreachable path.
6. A cache or persistent object cache returns outdated Wordfence scan-status data.
7. A Wordfence database table is damaged or cannot be updated.
8. Wordfence repeatedly encounters an unusually large directory, backup archive, log file, or circular symbolic link.

Wordfence confirms that hosts may enforce process, memory, or CPU limits that are lower than the values reported by PHP. These restrictions do not always generate a visible PHP error, which can make the scan appear to stop silently. admin-ajax.phpReturning0` Does Not Prove Everything Works

Opening the following URL is a useful first test:

https://example.com/wp-admin/admin-ajax.php

Seeing this response is normal:

0

WordPress AJAX requests must include an action parameter so WordPress knows which callback to execute. A direct browser visit does not include a valid Wordfence action, so a response of 0 is expected. lt proves that the file is publicly reachable through the browser. It does not prove that:

• The server can connect to its own domain
• Wordfence’s authenticated callback is accepted
• WP-Cron can execute the resume event
• A firewall is not blocking the Wordfence action
• The server can write the new scan status to the database
• The next FastCGI process remains alive long enough

Therefore, admin-ajax.php returning 0 is only a basic endpoint test.

Complete Wordfence Scan Troubleshooting Process

Step 1: Capture the Exact Point Where the Scan Stops

Go to:

Wordfence → Tools → Diagnostics

Temporarily enable:

Enable debugging mode

Then return to:

Wordfence → Scan

Start a new scan and open:

Scan Detailed Activity → View activity log

Watch for the final message recorded before progress stops.

Wordfence debugging mode writes significantly more information to the database and may increase CPU and database usage. It should only be enabled temporarily while reproducing the problem. Wordfence recommends using it for a short troubleshooting period rather than leaving it permanently enabled. on final log messages

“Scan process ended after forking”

This usually points to a failed callback or stage handoff.

Check for:

• Password protection on /wp-admin/
• An .htaccess rule blocking /wp-admin/
• A security plugin blocking admin-ajax.php
• A maintenance-mode plugin
• A stale Memcached or object-cache entry
• A firewall blocking the server’s own IP address

Wordfence specifically associates this message with blocked access to wp-admin or stale object-cache data. tempting to resume scan stage”

This means the scan could not reliably continue from the previous stage.

Increase:

Maximum number of attempts to resume each scan stage: 5

The default is normally two attempts, while Wordfence permits up to five. This retry feature depends on WP-Cron working correctly. log stops without any error

This commonly indicates that the hosting provider silently terminated the PHP process because of:

• CPU limits
• Account resource throttling
• FastCGI timeouts
• Process-lifetime limits
• Memory limits applied across multiple processes
• ModSecurity intervention
• A hosting “killer” process

Check the server error log at the exact time shown in the Wordfence activity log.

HTTP 403, 406, or 429

These responses usually indicate a firewall, security rule, rate limit, or bot-protection system.

HTTP 500 or 503

These responses can indicate:

• A PHP fatal error
• An exhausted hosting account
• A database error
• A FastCGI process failure
• A temporary hosting restriction

Step 2: Apply a Stable Wordfence Scan Configuration

Go to:

Wordfence → Scan → Scan Options and Scheduling

Use the following baseline configuration.

Scan type

Set:

Scan Type: Limited Scan

A Limited Scan is appropriate for hosting accounts with restricted resources or scans that do not complete.

Use low-resource scanning

Enable:

Use low-resource scanning

This spreads the work over a longer period and reduces peak CPU and memory usage. The scan may take two to four times longer, but it is less likely to trigger shared-hosting resource limits. mum execution time for each scan stage

Start with:

15 seconds

If the scan still fails, test:

12 seconds

Then:

8 seconds

Wordfence divides scans into multiple requests. A shorter stage time allows Wordfence to save its progress before the hosting provider terminates the process.

Wordfence recommends testing different values and notes that values below eight seconds are normally ignored unless an advanced constant is used. utomatically set this value to the PHP limit of 120 seconds. The web server or hosting platform may enforce a lower hidden limit.

Wordfence requested memory

Use:

256 MB

Or test:

300 MB

Increasing this further is unlikely to help unless the PHP or server error log contains an actual memory-exhaustion error.

A PHP memory_limit of 256M is generally enough for a Limited Scan on an ordinary website. Hidden hosting limits can still terminate the process even when PHP reports 256M.

Total scan time limit

Leave this field blank initially:

Time limit that a scan can run in seconds: [blank]

Wordfence currently uses a default total limit of three hours when the field is empty. ng the total limit does not fix a failed stage handoff. It only allows a healthy scan to continue for longer.

Maximum resume attempts

Set:

Maximum number of attempts to resume each scan stage: 5

This can help when loopback requests fail intermittently.

Step 3: Disable Expensive Scan Options

Even when the scan type is set to Limited, review the individual scan options.

Temporarily disable:

Scan files outside your WordPress installation
Scan images, binary, and other files as if they were executable

Scanning outside the WordPress installation can include:

• Old website copies
• Staging installations
• Backup directories
• Server logs
• Temporary files
• Email storage
• Other applications
• Circular symbolic links

Wordfence warns that circular symbolic links or unusual directories can make a scan continue indefinitely. Scanning outside WordPress can also cause the host to terminate the scan because of resource usage. xclude the entire uploads directory unless there is a specific reason. Instead, exclude known backup, cache, and generated-file directories.

Possible examples include:

wp-content/cache/*
wp-content/updraft/*
wp-content/ai1wm-backups/*
wp-content/uploads/backup-guard/*
wp-content/wflogs/*
error_log
*.zip
*.tar
*.tar.gz
*.wpress

Adjust the list for the plugins and directory structure used by the website.

Do not exclude files that are actively being investigated for malware.

Step 4: Test the Server’s Loopback Connection

A Wordfence scan repeatedly requires the web server to connect back to the website.

Go to:

Tools → Site Health → Status

Look for a loopback-request failure.

A loopback failure can affect WP-Cron, scheduled tasks, plugin updates, file verification, and Wordfence scans. WordPress Site Health includes a loopback test specifically because many WordPress background operations depend on it. with SSH

When SSH access is available, run:

curl -L -sS https://example.com/wp-admin/admin-ajax.php

The expected body is:

0

Also test the response code and connection time:

curl -L -sS -o /dev/null \
-w "HTTP: %{http_code} Time: %{time_total}s\n" \
https://example.com/wp-admin/admin-ajax.php

The expected response is normally:

HTTP: 200

A result such as 403, 406, 429, 500, 503, a TLS error, or a long timeout needs investigation.

Run this command from the hosting server, not only from a personal computer. A URL may work from a browser while failing when the server tries to connect to itself.

Check how the domain resolves

Run:

dig example.com A
dig example.com AAAA

Or:

getent hosts example.com

Confirm that the returned address is reachable from the hosting server.

Problems can occur when:

• The domain resolves to an old server
• An IPv6 record exists but the host cannot use IPv6
• The domain is routed through Cloudflare and the origin blocks Cloudflare
• The host cannot connect to its own public IP
• A local DNS cache contains outdated information

Step 5: Force Wordfence to Use IPv4

When the website uses Cloudflare or has an IPv6 DNS record, enable:

Wordfence → Scan → Scan Options and Scheduling
→ Advanced Options
→ Use only IPv4 to start scans

A domain may resolve to IPv6 even when the hosting server cannot make outbound IPv6 connections. This can cause Wordfence callbacks to fail intermittently.

Wordfence specifically recommends the IPv4 option when Cloudflare or an IPv6 connectivity problem interferes with scans. abling it, stop the failed scan and start a completely new scan.

Step 6: Configure “Start All Scans Remotely” Correctly

The option is located under:

Wordfence → Tools → Diagnostics → Debugging Options

Wordfence normally starts a scan by making a local callback from the server to itself. When that initial callback fails, the remote-scan option asks Wordfence’s servers to call back to the website instead. this option is mainly useful when a scan does not start.

In this case, the scan already starts and becomes stuck later. Therefore:

1. Test one scan with remote starting enabled.
2. Test one scan with remote starting disabled.
3. Leave it disabled when it does not change the result.

Remote starting may solve the first request but not a later stage-resume, WP-Cron, database, or hosting process problem.

Step 7: Verify WP-Cron

Wordfence uses WP-Cron when retrying failed scan stages. A disabled or unreliable cron system can prevent a stalled stage from resuming. -config.php` and look for:

define('DISABLE_WP_CRON', true);

When this line exists, WordPress will not start cron tasks through normal page requests.

That configuration is acceptable only when a real server cron job has been created.

Test WP-Cron with WP-CLI

Run:

wp cron test

Then list scheduled events:

wp cron event list

Run due events manually:

wp cron event run --due-now

If the commands fail, inspect the returned error and the PHP error log.

Create a real cron job

For a website using DISABLE_WP_CRON, create a server cron job that runs every five minutes.

Example using wget:

*/5 * * * * wget -q -O - "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

Example using PHP CLI:

*/5 * * * * /usr/bin/php /home/account/public_html/wp-cron.php >/dev/null 2>&1

Replace the PHP binary and WordPress path with the values used by the hosting account.

The PHP CLI method avoids DNS, Cloudflare, and external loopback problems, but the CLI PHP configuration must be compatible with the website.

Do not add DISABLE_WP_CRON unless a replacement server cron has been configured.

Step 8: Check Apache and FastCGI Timeouts

The reported PHP SAPI is:

cgi-fcgi

This means PHP is running through a CGI or FastCGI layer rather than directly inside Apache.

PHP’s max_execution_time is therefore not necessarily the only timeout.

Depending on the server configuration, Apache may use:

• mod_fcgid
• mod_proxy_fcgi
• PHP-FPM
• Another managed FastCGI implementation

Apache’s mod_fcgid includes independent controls such as:

FcgidIOTimeout
FcgidIdleTimeout
FcgidProcessLifetime
FcgidMaxRequestsPerProcess

Apache’s proxy module can also apply a separate ProxyTimeout value. These limits exist outside the PHP max_execution_time displayed in WordPress. d hosting, these values usually cannot be changed through WordPress, .user.ini, or .htaccess.

Ask the hosting provider to check:

• FastCGI timeout events
• Terminated PHP processes
• Apache proxy timeout events
• CPU throttling
• Process limits
• Account memory limits
• I/O limits
• CloudLinux LVE faults
• ModSecurity audit records
• HTTP 403, 406, 500, or 503 responses
• Requests to wp-admin/admin-ajax.php
• Requests made at the exact timestamp where the scan log stops

Do not add FastCGI server directives to .htaccess unless the hosting provider confirms that they are permitted. Unsupported directives can cause an immediate 500 Internal Server Error.

Step 9: Check ModSecurity and Hosting Firewall Logs

A server firewall may permit a plain request to admin-ajax.php while blocking a specific Wordfence request body or action.

This explains why visiting the AJAX file manually may work even though the scan callback fails.

Ask the hosting provider to search the ModSecurity audit log for the affected domain and timestamp.

Look for rules involving:

/wp-admin/admin-ajax.php
wordfence
wfScanEngine
wfsf
cron
fork

Do not permanently disable ModSecurity for the entire website.

The correct solution is to:

1. Identify the exact triggered rule.
2. Confirm that the request belongs to Wordfence.
3. Whitelist that rule for the required endpoint or domain.
4. Run another scan.
5. Confirm that other ModSecurity protection remains active.

Step 10: Check Cloudflare

The reported origin server is Apache, not LiteSpeed. However, Cloudflare can still sit in front of Apache.

When Cloudflare is active:

• Enable “Use only IPv4 to start scans.”
• Check Cloudflare Security Events while starting a scan.
• Confirm that no custom WAF rule blocks wp-admin/admin-ajax.php.
• Confirm that no cache rule caches /wp-admin/*.
• Check whether Bot Fight Mode or rate limiting blocks origin callbacks.
• Verify that the origin permits Cloudflare IP ranges.
• Temporarily pause Cloudflare or switch the DNS record to DNS-only for one controlled test.

Do not leave Cloudflare disabled permanently just to make Wordfence scan.

If the scan works with Cloudflare bypassed, identify the specific Cloudflare rule responsible and create a narrow exception.

Step 11: Do Not Apply LiteSpeed Fixes to an Apache Server

Wordfence provides a LiteSpeed-specific noabort fix because LiteSpeed may terminate a background PHP process after a visitor disconnects. the reported server is:

Apache

Therefore, do not add LiteSpeed directives such as:

RewriteRule .* - [E=noabort:1]

unless the hosting provider confirms that the website is actually served through LiteSpeed or OpenLiteSpeed despite the displayed server information.

Adding irrelevant LiteSpeed rules will not fix an Apache FastCGI timeout.

Step 12: Check Wordfence Database Tables

Wordfence records scan state and activity in its database tables.

A damaged status table can allow a scan process to run while preventing Wordfence from saving or displaying progress.

Open phpMyAdmin and find the Wordfence tables. The table prefix may not be wp_.

Look for tables similar to:

wp_wfStatus
wp_wfConfig
wp_wfIssues
wp_wfKnownFileList
wp_wfFileMods
wp_wfBlocks7

Select the Wordfence tables and run:

Check table

If phpMyAdmin reports a crashed table, use:

Repair table

Wordfence documents cases where a damaged wfStatus table prevents scan activity from being recorded and causes database errors in the server log. epairing or changing database tables, create a complete database backup.

Do not manually empty or delete Wordfence tables unless following a controlled reset process.

Step 13: Flush Persistent Object Cache

A persistent object cache can return outdated scan status or cron data.

Check for:

• Redis Object Cache
• Memcached
• W3 Total Cache database cache
• Hosting-level object cache
• LiteSpeed object cache, when the server uses LiteSpeed
• A custom drop-in at wp-content/object-cache.php

Temporarily:

1. Purge the page cache.
2. Flush the object cache.
3. Disable database caching.
4. Stop the existing scan.
5. Start a new scan.

Wordfence notes that database caching can return outdated scan records and that Memcached may retain a stale scan cron key. isable page caching permanently unless it is confirmed to be the cause.

Step 14: Check for Large Files and Directories

A scan can appear stuck while repeatedly processing an unexpectedly large directory.

With SSH access, count all files:

find public_html -type f | wc -l

Find the largest directories:

du -h --max-depth=2 public_html | sort -h

Find unusually large files:

find public_html -type f -size +100M -print

Common causes include:

Old backup archives
Multiple staging copies
Large error logs
Database exports
Cache directories
Video files
Email storage
Migration backups
Malware-generated files
Circular symbolic links

Move backup archives outside the WordPress installation whenever possible.

Do not delete unknown files merely because they are large. Confirm their purpose first and keep a backup.

Step 15: Test for a Plugin or Theme Conflict

A theme or plugin can interfere with:

• AJAX requests
• WordPress cron
• Database queries
• Authentication cookies
• REST and loopback requests
• PHP shutdown behavior
• Wordfence JavaScript
• Wordfence scan callbacks

Perform this test on a staging website whenever possible.

Temporarily activate only:

Wordfence

Use a default WordPress theme and run another scan.

When the scan completes, reactivate the other plugins one at a time until the failure returns.

Pay particular attention to:

• Login URL hiding plugins
• Other security plugins
• Maintenance-mode plugins
• Database caching
• Object caching
• Query Monitor
• Firewall plugins
• Plugins that block /wp-admin/
• Plugins that disable WP-Cron
• Plugins that modify outgoing HTTP requests

Wordfence specifically warns that plugins blocking admin-ajax.php, modifying database queries, or generating admin-side JavaScript errors can interfere with its operation. 16: Test PHP 8.3 as an Isolation Step

PHP 8.4 should not automatically be blamed for the failure.

However, when every loopback, cron, firewall, database, and hosting check passes, temporarily test the website with PHP 8.3.

Before changing PHP:

1. Create a complete backup.
2. Test the website on staging.
3. Record the active PHP extensions.
4. Run a Wordfence scan on PHP 8.3.
5. Compare the PHP and server logs.

If the scan works on PHP 8.3 but not PHP 8.4, inspect the logs for a specific fatal error, type error, or compatibility issue.

Do not permanently downgrade PHP without identifying the actual incompatibility.

Warnings and deprecation notices alone normally do not explain a silently terminated scan unless the website converts them into exceptions or sends them into an excessively large log file.

Step 17: Use the Failure-Threshold Constant Only for False Warnings

Wordfence provides this advanced constant:

define('WORDFENCE_SCAN_FAILURE_THRESHOLD', 600);

It increases the period before Wordfence displays the failed-scan warning from the default threshold to 600 seconds.

Add it above this line in wp-config.php:

/* That's all, stop editing! Happy publishing. */

Example:

define('WORDFENCE_SCAN_FAILURE_THRESHOLD', 600);

/* That's all, stop editing! Happy publishing. */

This does not repair a scan that has genuinely stopped.

It should only be used when:

• The activity log continues progressing
• The scan eventually completes
• A slow cache or database causes the interface to report an outdated status
• The failure warning appears prematurely

Wordfence documents this constant as a way to adjust the warning threshold when scan results are delayed by cache or database behavior. ctivity log has completely stopped, increasing the threshold only delays the warning.

Recommended Fix Order for This Configuration

For the reported Apache, CGI/FastCGI, PHP 8.4, and shared-hosting environment, use this order:

1. Stop the currently stuck scan.
2. Enable Wordfence debugging temporarily.
3. Set the scan type to Limited.
4. Enable low-resource scanning.
5. Set each scan stage to 15 seconds.
6. Set resume attempts to five.
7. Leave the total scan-time limit blank.
8. Keep requested scan memory at 256M or test 300M.
9. Disable scanning outside the WordPress installation.
10. Disable binary and image executable scanning.
11. Enable “Use only IPv4 to start scans.”
12. Confirm WP-Cron is working.
13. Test server-side access to admin-ajax.php with curl.
14. Temporarily disable cache, object-cache, and security plugins.
15. Check Cloudflare Security Events, when Cloudflare is active.
16. Check the PHP, Apache, FastCGI, ModSecurity, and hosting resource logs.
17. Check and repair damaged Wordfence tables.
18. Ask the host whether the account is hitting CPU, process, I/O, or FastCGI limits.
19. Test PHP 8.3 only after the infrastructure checks pass.
20. Export the Wordfence diagnostics report when support is still required.

Message to Send to the Hosting Provider

Use the following message when contacting the host:

A Wordfence scan starts successfully but stops making progress during a later scan stage. PHP reports max_execution_time of 120 seconds and memory_limit of 256M, but Wordfence still stops without a PHP memory or execution-time error.

The site uses Apache with PHP through CGI/FastCGI. Please check the server logs at the scan timestamp for terminated PHP/FastCGI processes, ModSecurity blocks, CPU or memory throttling, process limits, I/O limits, Apache proxy timeouts, FastCGI I/O timeouts, and CloudLinux LVE faults.

Please also check whether the server can make loopback HTTPS requests to its own domain and whether requests to /wp-admin/admin-ajax.php are returning 403, 406, 429, 500, or 503 responses.

The endpoint is publicly reachable and returns 0 when opened directly, but that does not confirm that Wordfence’s authenticated scan-stage callback is being permitted.

Please provide the relevant Apache, FastCGI, PHP, and ModSecurity log entries instead of only confirming the values shown in phpinfo.

Frequently Asked Questions

Why does the Wordfence scan start but never complete?

Wordfence runs its scan through multiple separate PHP requests. After each stage, the server must connect back to the website to continue. When the callback, WP-Cron event, database update, or new PHP process fails, the scan can stop without immediately displaying a clear error.

Does admin-ajax.php returning 0 mean Wordfence is working?

No. It only confirms that the basic WordPress AJAX endpoint is publicly accessible. It does not test Wordfence’s action, authentication, loopback connection, cron event, database write, or hosting resource limits.

Should I increase PHP memory above 256M?

Only when the error log shows an actual memory-exhaustion error. Continuously increasing memory does not solve a failed loopback, FastCGI timeout, ModSecurity block, cron failure, or damaged database table.

What scan-stage execution time should I use?

Start with 15 seconds. Test 12 seconds and then eight seconds when the scan still fails. Shorter stages can prevent the host from terminating the process before Wordfence saves its progress.

Should I enable “Start all scans remotely”?

Use it when the scan cannot start. When the scan starts normally but fails later, remote starting may not help because the problem is probably occurring during a later stage handoff.

Can WP-Cron stop a Wordfence scan?

Yes. Wordfence’s stage-retry system depends on WP-Cron. When WP-Cron is disabled or unreliable, a failed stage may never resume.

Do I need the LiteSpeed noabort rule?

Not when the website genuinely uses Apache. The noabort rule is a LiteSpeed-specific solution. Verify the actual web server before adding it.

Can Cloudflare cause Wordfence scans to fail?

Cloudflare can contribute when IPv6 routing, custom WAF rules, rate limiting, or bot protection blocks a callback. Enable Wordfence’s IPv4-only option and review Cloudflare Security Events during the scan.

Can a large backup directory make the scan run indefinitely?

Yes. Backup archives, staging copies, cache directories, large logs, and circular symbolic links can greatly increase scan time or trap the scanner in an abnormal directory structure. Exclude known backup directories or move them outside WordPress.

Does the failed-scan warning mean the website is infected?

No. It means the security scan did not complete. It does not prove that malware is present or absent.

Until Wordfence completes successfully, use another trusted server-side malware scanner or manually inspect the website when compromise is suspected.

Final Diagnosis

For a Wordfence scan that starts but never completes on Apache with PHP running through CGI/FastCGI, the most likely issue is not upload_max_filesize, post_max_size, or max_input_variables.

The likely failure occurs when Wordfence attempts to save and resume a scan stage.

The primary areas to investigate are:

Server loopback requests
WP-Cron execution
FastCGI and Apache timeouts
Hosting CPU and process limits
ModSecurity rules
Cloudflare or IPv6 routing
Persistent object cache
Wordfence database tables
Large or circular directories

The most useful immediate configuration is:

Limited Scan
Low-resource scanning enabled
15-second scan stages
Five resume attempts
IPv4-only scan starting
Scanning outside WordPress disabled
Binary and image executable scanning disabled

If the scan still stops with this configuration, the hosting provider must inspect the Apache, FastCGI, ModSecurity, and resource-limit logs at the exact time of failure. Increasing WordPress memory repeatedly or changing random plugin settings will not resolve a server process that is being silently terminated.