Fairly new to running my own WordPress site and I got a fright the first time I opened the login logs, dozens of failed attempts a day from IPs all over the place. From what I've read since, this is mostly background noise: automated bots spraying credentials at the default login on basically every install, and unless the numbers are huge or paired with other symptoms it isn't a targeted attack. I tightened the obvious things, a strong unique password, a second factor on the admin account, and capping how many tries an IP gets before it's locked out, and the volume dropped noticeably.

Two things I'd love a reality check on from people who've run sites longer: at what point should a spike in failed logins actually worry me versus just being noise, and is limiting attempts + 2FA genuinely enough on its own, or is there one more thing you'd treat as non-negotiable? Don't want to bolt on five plugins for a problem that's already handled.

Been going back and forth on this one. My logs fill up with failed logins on the default /wp-login.php every day, as far as I can tell it's just bots hitting the same path they hit on every WordPress site, nothing targeted at me. Limiting attempts and adding a challenge to the form quieted most of it, but I keep wondering whether moving the login off the default path is genuinely worth it or just security-through-obscurity that breaks more than it fixes.

For those of you who've hidden the login URL: did it actually cut the noise in your logs, or did it mostly create headaches with things that expect wp-login.php (mobile app, integrations, the odd plugin)? And if you deliberately don't hide it, what's your reasoning, rate-limiting at the edge and calling it done? Trying to figure out where the real payoff is before I fiddle with it further.

https://preview.redd.it/krk2vsiajzih1.png?width=1762&format=png&auto=webp&s=379a2494f2b3d48cad954ad9e1b770de023c1f6e

The 7.0.x releases have restarted the oldest argument in this sub. Auto-updates on, because a patched hole beats a broken layout. Auto-updates off, because you don't push untested code to production at 4am. Both camps have been making the same case for a decade, and both are working from an assumption I think is the actual problem.

Both assume the update itself is safe.

The case for patching fast is strong and I'm not arguing against it. Patchstack's State of WordPress Security in 2026 puts the weighted median time from disclosure to first exploitation at five hours, across 11,334 vulnerabilities disclosed in 2025, 91% of them in plugins. If you're patching on a weekly review cycle you are losing that race, every time, and the 4am-broken-layout crowd is trading a rare outage for a common breach.

Here's the number from that same report that nobody quotes though. 46% of those vulnerabilities had no patch available at the moment they were disclosed. Patchstack's own conclusion is that this "shows why website owners can't rely on plugin updates as a security measure." Their words, not mine.

But look at what the update actually is. Your site fetches a package from a vendor's server, unpacks it, and executes it. That's a write path the site trusts by design. There's no authentication event anywhere in that chain to harden and no second opinion on what arrived. 2FA, lockouts, a firewall sitting in front of the login page, none of them are in that request path at all.

That's not hypothetical this month. An agency posted a writeup here on the 3rd describing their plugin vendor's update server being compromised and a backdoor landing on client sites through a routine update. Someone in another thread described a window in early August where pressing update in wp-admin could hand you a tampered package. Both are those posters' accounts and neither is independently verified, so treat the specifics as claims. The shape is what I'm interested in.

So my position is that both sides of the argument are defending the wrong door. The useful question isn't auto or manual. It's how you'd know.

There is a partial answer built into WP-CLI that hardly anyone runs. wp plugin verify-checksums compares the plugin files on your site against the checksums wordpress org publishes for that version. If a file changed after install, it says so.

Then you hit the part that matters here. It only works for plugins from the repo. Point it at a premium plugin and you get "could not retrieve the checksums, skipping," because there is no published source of truth to compare against. The vendor ships the package themselves.

So the one integrity check built into the tooling covers everything except the category where vendor-delivered tampering actually happens. In the ShapedPlugin case reported in June, the backdoor went into the Pro builds on 21 May and the first customer reports landed on 10 June. Twenty days, three paid plugins, delivered through the vendor's own update system. That timeline is from Wordfence's data as reported at the time, not something I measured.

Which brings me to the part I don't have a good answer for, and the reason I'm posting.

If a plugin update you installed last month had been tampered with in transit, how would you find out? Not in theory. What in your current setup would actually tell you?

This comes up every few weeks, and the answer never seems to be wherever people go looking for it. So, here.

You open your firewall summary and find something like:

Blocked for [Plugin Name] <= 2.1.4 - Unauthenticated Sensitive Information Exposure via REST API in query string: rest_route = /[plugin-slug]/v1/tests/mock-data 

You have never installed that plugin. It isn't in your plugins folder, it isn't sitting there deactivated, it was never there at all. Two things are getting confused here, and separating them makes the whole thing boring, which is the correct outcome.

The request is generic. WordPress serves REST routes at /wp-json/..., and it also accepts ?rest_route=... as a query-string fallback so the API still works when pretty permalinks are off. That fallback resolves on every WordPress install. So a bot needs to know nothing about your site to try it. It takes a list of recently disclosed plugin vulnerabilities, builds the request for each one, and fires the whole list at every WordPress site it can find. The sites running that plugin answer with something useful. The rest return nothing, because the route was never registered.

The block is a pattern match, not a detection. Your firewall recognized the shape of the request and stopped it before WordPress got a chance to shrug at it. That's why the log names a plugin and a version range: it's describing the exploit the request was written for, not something it found on your site. The phrasing makes it read like you were targeted and narrowly got away with it. You weren't, and there was nothing to get away from.

So: nothing is installed that shouldn't be, there's nothing to clean up, and it isn't related to some other plugin of yours with a similar name.

What the alert does tell you is that your site is on somebody's list. About 91% of last year's disclosed WordPress vulnerabilities were in plugins rather than core, per Patchstack's 2026 report, so those lists are long and they get worked constantly. Being on one only means your site answered a WordPress fingerprint check at some point.

If you'd rather be on fewer of them, look at what an anonymous request can learn about your install. Version strings hanging off your CSS and JS URLs. Readme files sitting under plugin directories. Directory listings nobody turned off. None of that is secret and none of it is why anyone gets hacked. It's just what makes a site cheap to sort into "worth coming back to" rather than "no idea what this is."