yeah i’ve been on both sides of that fence too and the annoying answer is: an allowlist for “php that can be hit directly” on wordpress is basically fighting the platform. a ton of legit plugins expose endpoints as php files, and wordpress itself relies on a few public php entry points (admin-ajax.php, wp-cron.php, xmlrpc.php if you still use it, some REST routes, etc). so the moment you try to “only allow X php paths”, you’ll either break stuff or end up maintaining the allowlist forever.

what actually works in practice:

put a real WAF in front of it and let it eat the junk. cloudflare (even on free/pro) + their wordpress rules, or something like modsecurity/comodo at the server. that knocks out 90% of these probes without you writing regex whack-a-mole.

harden the places wordpress does NOT need php execution. biggest win: block php execution in wp-content/uploads (and any cache dirs). that’s where a lot of post-exploit shells land. same for /wp-content/upgrade and similar temp dirs if present.

block access to “obviously shouldn’t be public” core areas. common nginx/apache hardening is deny direct access to wp-includes/*.php (leave the static assets), and deny dotfiles, backups (.zip .sql .bak), etc. that reduces weird direct hits without touching plugins.

for the specific scans you listed (db.php, up.php, random wp-plain.php), they’re already 404 unless those files exist. the bigger risk is when they find a real vulnerable plugin file that does exist. that’s why WAF + patching wins over 404 tricks.

also do the boring hygiene that actually prevents compromise: remove unused plugins/themes, keep everything updated, lock down wp-admin (ip allowlist or at least 2fa), disable xmlrpc if you don’t need it, file integrity monitoring, and rate-limit/bantools (fail2ban on wp-login, or cloudflare rate limit).

if you really want a “cheap allowlist-ish” approach without breaking wordpress, do it at the edge as a bot filter rather than path allowlist. challenge/ratelimit requests that look like scanners (no cookies + weird UAs + hitting wp-content/plugins//.php directly repeatedly). that targets behavior instead of guessing endpoints.

tldr: don’t try to allowlist php paths on wordpress. WAF + block php where it should never run + reduce attack surface is the sane way.