wpscanteam/wpscan · error · WPScan::Error::Download
Unable to get #{response.effective_url} (status: #{response.
Error message
Unable to get #{response.effective_url} (status: #{response.code}) What it means
WPScan::Error::Download raised in Updater#remote_file_checksum (lib/wpscan/db/updater.rb:137-138) when the GET of https://data.wpscan.org/<file>.sha512 (or https://enterprise-data.wpscan.org/... for enterprise dumps) times out or returns a non-200 status. The error object wraps the Typhoeus response; its to_s (lib/wpscan/errors/http.rb:32-46) prints 'Unable to get <effective_url> (status: N)' - or the return_message when code is 0 - and, for data.wpscan.org, appends the Cloudflare Ray ID and support links. It fires during 'wpscan --update' and during the automatic DB refresh at scan start (Updater#update).
Source
Thrown at lib/wpscan/db/updater.rb:138
params.delete(:proxyuserpwd)
end
params
end
# @return [ String ] The raw file URL associated with the given filename
def remote_file_url(filename)
host = enterprise_file?(filename) ? ENTERPRISE_HOST : DEFAULT_HOST
"https://#{host}/#{filename}"
end
# @return [ String ] The checksum of the associated remote filename
def remote_file_checksum(filename)
url = "#{remote_file_url(filename)}.sha512"
res = Typhoeus.get(url, request_params(filename))
raise Error::Download, res if res.timed_out? || res.code != 200
res.body.chomp
end
# @return [ String ]
def local_file_path(filename)
repo_directory.join(filename.to_s).to_s
end
def local_file_checksum(filename)
Digest::SHA512.file(local_file_path(filename)).hexdigest
end
# @return [ String ]
def backup_file_path(filename)
repo_directory.join("#{filename}.back").to_s
end
View on GitHub (pinned to 62c9cef471)
Solutions
- Retry after a moment - transient CDN/network glitches are the most common cause
- Verify reachability: curl -I https://data.wpscan.org/metadata.json.sha512 (through the same proxy wpscan uses)
- For enterprise files, check the token: unset WPSCAN_ENTERPRISE_DB_TOKEN or pass a valid --enterprise-db-token, since a bad token makes every enterprise fetch 401/403
- If it persists, check https://status.wpscan.com/ and contact WPScan support including the Cloudflare Ray ID printed in the error
Example fix
# before $ wpscan --update # => Unable to get https://data.wpscan.org/wp_fingerprints.json.sha512 (status: 403) # after (proxy was stripping the User-Agent) $ wpscan --update --proxy http://corporate-proxy:8080 # or, once the network path is fixed $ wpscan --update # => databases updated
Defensive patterns
Strategy: retry
Validate before calling
# Preflight the checksum host before running the updater
require 'typhoeus'
res = Typhoeus.get('https://data.wpscan.org/metadata.json.sha512', timeout: 30)
abort "DB host unreachable (#{res.code})" unless res.code == 200 Try / catch
begin
WPScan::DB::Updater.new(db_dir).update
rescue WPScan::Error::Download => e
if (tries += 1) <= 3 && e.response.code != 401 && e.response.code != 403
sleep(2**tries)
retry # transient CDN/network failures usually clear
end
warn e # includes Cloudflare Ray ID + support links for data.wpscan.org
end Prevention
- Verify proxy/firewall egress to data.wpscan.org (and enterprise-data.wpscan.org when using an enterprise token) before scheduling scans
- Keep WPSCAN_ENTERPRISE_DB_TOKEN fresh; a dead token turns every enterprise checksum fetch into 401/403
- Run 'wpscan --update' on a schedule so scan-time updates are small and rarely hit timeouts
When it happens
Trigger: Fetching any of the FILES checksums (metadata.json.sha512, wp_fingerprints.json.sha512, etc.) through a broken proxy (request_params merges the CLI --proxy settings), DNS/firewall blocking data.wpscan.org, a 403 from Cloudflare/WAF, or an enterprise dump checksum request with an invalid/expired --enterprise-db-token (X-DB-JSON-AUTH rejected by enterprise-data.wpscan.org, typically 401/403).
Common situations: Corporate egress proxies blocking CDN hosts; scans inside locked-down Docker/K8s networks with no NAT; expired WPSCAN_ENTERPRISE_DB_TOKEN env var; Cloudflare incidents (check status.wpscan.com); local clock/MTU issues causing the 600s timeout to hit.
Related errors
- The option #{opt.to_long} is required
- One of the following options is required: #{opt.to_long}, --
- SAML authentication needs an interactive terminal to wait fo
- SAML authentication is required to access this resource. Ple
- --expect-saml requires Chrome or Chromium to be installed an
AI-assisted analysis of wpscanteam/wpscan@62c9cef471 (2026-08-21).
Data as JSON: /api/errors/2cd2eb8ec0a746c1.
Report an issue: GitHub.