Sentinela.
← Volver al blog

5 de mayo de 2026 · 5 min · Carol

WordPress seguridad ASM vulnerabilidades

WordPress seguro en 2026: checklist de lo que un atacante ve

La mayoría de los tutoriales de WP seguro termina recomendando el mismo plugin de firewall. Este mira lo que un atacante realmente ve — antes que él.

Every "secure WordPress" article ends recommending the same firewall plugin and two wp-config.php tweaks. That fixes half the problem. The other half lives in what any anonymous visitor can see without ever touching your admin panel.

This checklist is what an attacker tries first. Run the list. Anything red, fix today.

1. Version exposed in page source

Open the site in an incognito tab, view-source, search for wp-content/themes/ or wp-content/plugins/. You'll see things like:

?ver=6.4.3
?ver=4.9.8

That ?ver= is the plugin/theme version exposed to the world. An attacker cross-checks the WPScan Vulnerability Database and knows exactly which exploit to try.

Fix: strip the version query string from production assets (style_loader_src and script_loader_src filters), or use a cache plugin that minifies everything into a single bundled file.

2. /wp-json/wp/v2/users open

Hit https://yoursite.com/wp-json/wp/v2/users. If it returns JSON listing users (including the slug — which is the WordPress login), you just handed half the brute force away.

Fix: disable REST users endpoints for unauthenticated users:

add_filter('rest_endpoints', function ($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) unset($endpoints['/wp/v2/users']);
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    return $endpoints;
});

3. /?author=1 reveals login

https://yoursite.com/?author=1 redirects to /author/your-real-login/. In seconds, the attacker has the username and starts brute-forcing /wp-login.php.

Fix: block the redirect via template_redirect, or change the admin user's slug to something different from the login.

4. /wp-admin/ with no rate-limit

Try the wrong password 10 times in a row. If on the 11th you can still try, there's no rate-limit. Default bots do 50 passwords per minute until they give up.

Fix: Limit Login Attempts (plugin), Fail2Ban on the server, or a Cloudflare challenge rule for /wp-login.php.

5. Backups left in the public folder

The worst one. Attackers blindly try:

/backup.zip
/site.sql
/db.sql
/database.sql
/wp-content/backups/
/wp-content/uploads/2024/db.sql
/.git/config
/wp-config.php.bak
/wp-config.old

Each of these hits some online store somewhere today. Exposed SQL dump = entire database leaked, customer password hashes included.

Fix: never leave backups in an HTTP-served folder. Use S3, off-site FTP, or a directory above public_html. And deny *.sql, *.zip, *.bak, *.old, .git/ in .htaccess or nginx.conf.

6. xmlrpc.php enabled

/xmlrpc.php accepts XML-RPC auth. Attackers use system.multicall to test 500 passwords per request — bypassing /wp-login.php rate-limit.

Do you use Jetpack, the WP mobile app, or pingbacks? No? Block it.

Fix: Deny from all for xmlrpc.php in .htaccess, or block at Cloudflare.

7. PHP and Apache version in headers

curl -I https://yoursite.com/ and look at:

Server: Apache/2.4.18 (Ubuntu)
X-Powered-By: PHP/7.2.34

PHP 7.2 has been unsupported since 2020. Apache 2.4.18 has a critical CVE. These headers scream "try this" to the attacker.

Fix: expose_php = Off in php.ini, ServerTokens Prod in Apache, server_tokens off in nginx.

8. Abandoned plugin

Look at your active plugins. Any without an update in over 2 years? A plugin with 50k installs and last commit in 2022 is a prime mass-attack vector — when the exploit drops, everyone falls together.

Fix: swap for a maintained alternative. A plugin untouched for 2 years isn't stable, it's abandoned.

9. wp-content/uploads/ with executable PHP

Upload an image called test.php.jpg. Access it. If the server executes it as PHP, you have RCE on a platter from any plugin with a broken upload check.

Fix: deny .php execution inside /uploads/:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

10. HTTPS without redirect and without HSTS

Does the site respond on http:// and https://? No Strict-Transport-Security header? Session cookies can leak on public networks.

Fix: 301 redirect HTTP to HTTPS at the server, and header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

How Sentinela covers this automatically

We run this sweep every night on your domain:

  • WP, plugin, and theme versions exposed
  • Sensitive REST endpoints open
  • Backup files probed across 200+ known paths
  • Server and PHP headers leaking
  • xmlrpc.php active
  • Auth via /?author=N
  • SSL certificate and HSTS
  • CVE matching for each detected version

When you connect your repo, we also run SAST and secret scanning only on your code — without drowning the report in WP core noise (a common anti-pattern we covered before).

Free 14-day trial. Drop in your domain and in 10 minutes you'll see how many of these 10 are open in your house. For a deeper dive into headers specifically, see 5 HTTP security headers.

The simple rule

Most WordPress sites hacked in 2026 don't fall to an expensive exploit. They fall to one of these 10. Run the list today.

Sigue leyendo