wpscanteam/wpscan · error · WPScan::Error::WordPressHosted

The target appears to be hosted on WordPress.com. Scanning…

Error message

The target appears to be hosted on WordPress.com. Scanning such site is not supported.

What it means

Raised by Core#check_wordpress_state (app/controllers/core.rb:224) via Target#wordpress_hosted?: the host matches *.wordpress.com, or — when no content_dir is detected — the homepage references wp.com-hosted URIs. Both indicate a WordPress.com-managed site, which WPScan deliberately refuses to scan because it is not a self-hosted WordPress install.

Solutions

Confirm the target is really self-hosted WordPress; if the actual install lives elsewhere, point --url at it
Accept that WordPress.com sites cannot be scanned — no flag bypasses this check
For WordPress.com-hosted sites, rely on Automattic's platform security rather than WPScan

Example fix

# before
wpscan --url https://myblog.wordpress.com
# => The target appears to be hosted on WordPress.com. Scanning such site is not supported.

# after
wpscan --url https://myblog-selfhosted.example.com

Defensive patterns

Strategy: validation

Validate before calling

# Reject WordPress.com hosts before building the scan
host = Addressable::URI.parse(url).host
abort 'WordPress.com targets are not supported' if /\.wordpress\.com$/i.match?(host)

Try / catch

begin
  scan.run
rescue WPScan::Error::WordPressHosted
  mark_unsupported(url) # deterministic — skip, do not retry
end

Prevention

Curate target lists to exclude *.wordpress.com subdomains
Remember custom domains can also be WordPress.com-hosted (wp.com asset references)
Do not retry this error in automation — it is deterministic
Verify a target is self-hosted before adding it to a scanning queue

When it happens

Trigger: `wpscan --url https://something.wordpress.com` (host matches /\.wordpress\.com$/i), or a custom-domain site actually served by WordPress.com whose homepage HTML references wp.com assets before any wp-content dir is found.

Common situations: Scanning a blog believed to be self-hosted but actually on a WordPress.com plan; custom domains mapped to WordPress.com Business/Enterprise; attempting to audit Automattic-managed infrastructure (unsupported by design).

AI-assisted analysis of wpscanteam/wpscan@62c9cef471 (2026-08-21). Data as JSON: /api/errors/2f65b2be9dafade9. Report an issue: GitHub.

Appendix: source

Thrown at app/controllers/core.rb:224

      def update_db
        @updating_db = true
        output('db_update_started')
        output('db_update_finished', updated: local_db.update, verbose: ParsedCli.verbose)
        @updating_db = false

        exit(0) unless ParsedCli.url
      end

      # @return [ Boolean ] Whether the DB update is currently in progress
      def updating_db?
        @updating_db
      end

      # Raises errors if the target is hosted on wordpress.com or is not running WordPress.
      # Also checks if the homepage_url is still the install URL.
      def check_wordpress_state
        raise Error::WordPressHosted if target.wordpress_hosted?

        if %r{/wp-admin/install.php$}i.match?(Addressable::URI.parse(target.homepage_url).path)

          output('not_fully_configured', url: target.homepage_url)

          exit(WPScan::ExitCode::VULNERABLE)
        end

        raise Error::NotWordPress unless target.wordpress?(ParsedCli.detection_mode) || ParsedCli.force
      end

      # Loads the related server module into the target and includes it on WpItem
      # (needed to check if directory listing is enabled etc.).
      #
      # @return [ Symbol ] The server module loaded
      def load_server_module
        server = target.server || :Apache # auto-detect

View on GitHub (pinned to 62c9cef471)