Vulnerabilities
WordPress XML-RPC vs wp-login.php for Public Site OPSEC
July 10, 2026
WordPress XML-RPC vs wp-login.php is a two-door problem on a lot of marketing CMSs. wp-login.php is the browser form. xmlrpc.php is a legacy remote-procedure endpoint that can still authenticate users if it is enabled. Hardening only the form leaves the API door lonely. If you do not use Jetpack, the mobile app, or a pingback you actually want, disable XML-RPC. If you must keep it, put the same WAF rate limits, bot fights, and MFA on that path as on wp-login.php. RoastMyOpsec may notice common admin/login paths with soft GETs. It does not spray passwords, does not send XML-RPC auth methods, and does not prove your limits work.
The practical difference
The login page is a document with cookies and, if you did it right, MFA. XML-RPC is machine talk. Features that needed it in 2012 are often unused on a 2026 brochure site. Presence of /xmlrpc.php is discoverability, not a breach. A 200 that still accepts authentication is a second stuffing target.
Pingbacks and trackbacks are a separate product decision. Most marketing sites can live without them.
How to choose based on the site
Pure brochure WordPress: disable XML-RPC at the host or with a maintained plugin, rate-limit wp-login.php, MFA for administrators, keep the site updated. Editorial shops that need the official mobile app: keep XML-RPC or the replacement API, but do not leave it unmetered. Do not 'hide' wp-login.php as the only control.
| Door | Who uses it | When it wins to keep | Takeaway |
|---|---|---|---|
| wp-login.php | Humans in a browser | You edit the site | MFA + rate limit + CAPTCHA/WAF |
| xmlrpc.php | Apps, Jetpack, old pingbacks | A real feature still depends on it | Same abuse controls; else disable |
| /wp-admin/ | After login | Always, for editors | Discoverability ≠ bypass; see admin guide |
| REST /wp-json/ | Blocks, headless, apps | The theme needs it | Authz on routes; not the same as XML-RPC |
What a URL roast will not do
No XML method lists as an attack, no credential stuffing, no pingback amplification tests. A missing xmlrpc.php or a deny at the edge is a healthy signal. A 200 on the path is an inventory item — confirm in WordPress whether the feature is on, then decide.
Common mistakes
The first mistake is CAPTCHA on wp-login.php and unlimited XML-RPC.
The second mistake is renaming wp-login.php and leaving xmlrpc.php stock.
The third mistake is robots.txt Disallow for xmlrpc as if that authenticated anyone.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is xmlrpc.php a vulnerability by itself?
- No. It is an extra authentication surface. Unused, it should be off. Used, it needs the same abuse controls as login.
- Will RoastMyOpsec brute-force WordPress?
- No. Soft GETs for presence and status. No password spraying, no XML-RPC auth attempts.
- Should I hide wp-login.php instead of disabling XML-RPC?
- Hiding is not authentication. Disable unused XML-RPC, MFA the real login, and rate-limit both doors you keep.