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
        else

View on GitHub (pinned to 62c9cef471)

Solutions

  1. Confirm the endpoint: curl https://target/xmlrpc.php (a live endpoint typically answers GET with 405)
  2. Switch the attack: --password-attack wp-login (requires a detectable login page)
  3. Omit --password-attack entirely and let WPScan auto-detect the best available attack
  4. 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

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.