wpscanteam/wpscan · error · WPScan::Error::XMLRPCNotDetected
The XML-RPC Interface was not detected.
Error message
The XML-RPC Interface was not detected.
What it means
Raised by PasswordAttack#attacker_from_cli_options (app/controllers/password_attack.rb:87) when --password-attack xmlrpc is forced but Target#xmlrpc is nil — /xmlrpc.php was not detected as present on the target. Unlike Error::NoLoginInterfaceDetected, this error is not rescued in PasswordAttack#run, so it aborts the whole scan.
Source
Thrown at app/controllers/password_attack.rb:87
@attacker ||= attacker_from_cli_options || attacker_from_automatic_detection
end
# @return [ Model::XMLRPC ]
def xmlrpc
@xmlrpc ||= target.xmlrpc
end
# @return [ WPScan::Finders::Finder ]
def attacker_from_cli_options
return unless ParsedCli.password_attack
case ParsedCli.password_attack
when :wp_login
raise Error::NoLoginInterfaceDetected unless target.login_url
Finders::Passwords::WpLogin.new(target)
when :xmlrpc
raise Error::XMLRPCNotDetected unless xmlrpc
Finders::Passwords::XMLRPC.new(xmlrpc)
when :xmlrpc_multicall
raise Error::XMLRPCNotDetected unless xmlrpc
Finders::Passwords::XMLRPCMulticall.new(xmlrpc)
end
end
# @return [ Boolean ]
def xmlrpc_get_users_blogs_enabled?
if xmlrpc&.enabled? &&
xmlrpc.available_methods.include?('wp.getUsersBlogs') &&
!xmlrpc.method_call('wp.getUsersBlogs', [SecureRandom.hex[0, 6], SecureRandom.hex[0, 4]])
.run.body.match?(/>\s*405\s*</)
true
elseView on GitHub (pinned to 62c9cef471)
Solutions
- Confirm the endpoint: curl https://target/xmlrpc.php (a live endpoint typically answers GET with 405)
- Switch the attack: --password-attack wp-login (requires a detectable login page)
- Omit --password-attack entirely and let WPScan auto-detect the best available attack
- If you administer the site, temporarily re-enable xmlrpc.php for the duration of the scan
Example fix
# before wpscan --url http://target -P rockyou.txt --password-attack xmlrpc # => The XML-RPC Interface was not detected. # after wpscan --url http://target -P rockyou.txt --password-attack wp-login
Defensive patterns
Strategy: validation
Validate before calling
# Probe xmlrpc.php before forcing an xmlrpc attack
res = Typhoeus.get("#{url}/xmlrpc.php")
abort 'xmlrpc not usable — use the wp-login attack' unless [200, 405].include?(res.code) Try / catch
begin controller.attacker rescue WPScan::Error::XMLRPCNotDetected switch_to '--password-attack wp-login' # xmlrpc forced but endpoint absent end
Prevention
- Check /xmlrpc.php reachability before forcing xmlrpc attacks
- Prefer automatic attack detection for hardened targets
- Remember this variant aborts the scan (unlike the wp-login notice)
- Expect XML-RPC to be disabled on security-hardened sites
When it happens
Trigger: `wpscan --url http://target -P list.txt --password-attack xmlrpc` where the xmlrpc.php probe fails (404, blocked by a security plugin, .htaccess/host-level filter), so `target.xmlrpc` memoizes to nil and the guard `raise Error::XMLRPCNotDetected unless xmlrpc` fires.
Common situations: Security plugins (iThemes Security, BulletProof) disabling XML-RPC; server rules blocking xmlrpc.php; hardened WordPress setups removing the endpoint; forcing xmlrpc against sites that never exposed it.
Related errors
AI-assisted analysis of wpscanteam/wpscan@62c9cef471 (2026-08-21).
Data as JSON: /api/errors/b7e62eb840f40849.
Report an issue: GitHub.