Block 404 PHP File Scanning: block non-existent PHP file scanning to strengthen WordPress security

Why this module is useful

Malicious bots often test URLs of known or supposedly vulnerable PHP files, for example scripts in plugins/themes.
When these URLs don't exist, WordPress may respond with a 404. The problem: this confirms that a resource is being probed and feeds noise into the logs.

The Block 404 PHP File Scanning module adds a simple, effective defense:

1. detect a front-end request to a path ending in .php
2. check that WordPress has resolved it to 404
3. confirm that the targeted file does not physically exist
4. return a 403 Forbidden response
5. log event with PHP404 marker

As a result, you reduce the automated recognition surface and improve the readability of your logs.

Technical operation

The module executes its logic during template_redirect with high priority, to act at the right moment in the request cycle.

What's blocked

• Frontend requests to a .php path
• Requests already resolved as 404 by WordPress
• No target file under the WordPress root

What is deliberately ignored

• WordPress administration
• REST API
• AJAX
• CRON
• WP-CLI
• XML-RPC
• Requests that do not target .php
• Requests to a .php file actually present

Custom bypass via filter

If you have a specific business case, you can bypass protection with the wpmastertoolkit/block_404_on_php/bypass filter.

For example:

add_filter('wpmastertoolkit/block_404_on_php/bypass', function($bypass, $current_url) {
    if (strpos($current_url, '/mon-endpoint-technique.php') !== false) {
        return true;
    }
    return $bypass;
}, 10, 2);

Logs and observability

Each block is logged with code PHP404.
Sample message: Blocked nonexistent PHP request: URL requested.

Convenient for:

1. measure scan volume
2. identify attack patterns
3. prioritize complementary WAF/CDN rules

SEO + security best practices

Even though this module is security-first, it has a positive indirect SEO impact:

1. less server noise and greater stability on real crawlable pages
2. better analysis of technical logs
3. reduced risk of automated exploitation of historical endpoints

Implementation tips:

1. activate the module in production and pre-production
2. monitor logs for the first week
3. add a bypass only if a legitimate case is confirmed
4. combined with hardening of sensitive accesses and limitation of attempts

Quick FAQs

Does the module block normal WordPress pages?

No. It only targets non-existent .php URLs already seen as 404.

Why return 403 rather than 404

403 explicitly expresses a refusal of access and is often more dissuasive for automated scanners.

Does this module replace a WAF

No. It complements your application security strategy on the WordPress side.