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

SAML authentication is required to access this resource. Ple

Error message

SAML authentication is required to access this resource. Please ensure correct authentication credentials.

What it means

WPScan::Error::SAMLAuthenticationFailed raised in BrowserAuthenticator.authenticate (lib/wpscan/browser_authenticator.rb:21) when the interactive Ferrum session returns a nil or empty cookie jar (browser.cookies.all). Despite the 'ensure correct credentials' wording, it fires whenever zero cookies were captured after you press enter - the code never inspects whether the login itself succeeded, only that some cookies exist to serialize into a Cookie header.

Source

Thrown at lib/wpscan/browser_authenticator.rb:21

require 'ferrum'

module WPScan
  module BrowserAuthenticator
    # Characters that, if present in a cookie name or value, would corrupt the
    # serialized Cookie header. Per RFC 6265 these are forbidden in cookie-octets,
    # but a noncompliant IdP could still emit them.
    COOKIE_DELIMITERS = /[;,\s]/

    def self.authenticate(login_url)
      unless $stdin.tty?
        raise WPScan::Error::BrowserFailed,
              'SAML authentication needs an interactive terminal to wait for login, but stdin is not a TTY. ' \
              'Run wpscan from a real shell when using --expect-saml.'
      end

      cookies = run_login_session(login_url)

      raise WPScan::Error::SAMLAuthenticationFailed if cookies.nil? || cookies.empty?

      serialize_cookies(cookies)
    end

    # Drives the interactive browser session and returns the resulting cookie jar.
    # Translates Ferrum failures into BrowserFailed with a context-specific message.
    def self.run_login_session(login_url)
      browser = Ferrum::Browser.new(headless: false)

      puts 'SAML authentication needed. Log in via the browser window that just opened, then press enter.'
      browser.goto(login_url)
      gets # Waits for user input

      # Attempt an innocuous command to check if the browser is still responsive
      browser.current_url

      browser.cookies.all
    rescue Ferrum::BinaryNotFoundError, Ferrum::EmptyPathError => e

View on GitHub (pinned to 62c9cef471)

Solutions

Re-run and wait: complete the login in the opened Chrome window, confirm the browser landed back on the target site, only then press enter
Verify the login URL opens and redirects correctly in a normal browser first
Confirm the resource is actually behind SAML (if it is not, remove --expect-saml)
Check the Chrome window for errors (cert warnings, proxy errors) - fix those, then retry

Example fix

# before
SAML authentication needed. Log in via the browser window ... then press enter.
<enter pressed while still on the IdP login form>
# => SAMLAuthenticationFailed

# after
SAML authentication needed. Log in via the browser window ... then press enter.
<complete login, wait until the target site is shown, then press enter>
# => scan continues with the captured cookies

Defensive patterns

Strategy: try-catch

Try / catch

begin
  cookie_header = WPScan::BrowserAuthenticator.authenticate(login_url)
rescue WPScan::Error::SAMLAuthenticationFailed
  retry if (attempts += 1) < 3 # empty jar usually means 'enter pressed too early'
  raise
end

Prevention

Train users to wait until the browser shows the target site before pressing enter
Pre-verify the login URL and the SAML redirect chain in a normal browser
Treat repeated empty-jar results as a signal the target is not SAML-protected; drop --expect-saml

When it happens

Trigger: Pressing enter at the prompt before the IdP/SP set any cookies (e.g. before the redirect back to the target completes); the login_url being unreachable so no page ever sets cookies; the target not actually being SAML-protected; Ferrum's cookie API returning {} because the browser profile blocks cookies or the session landed on an error page.

Common situations: Impatient users hitting enter immediately; typo in the configured login URL; corporate proxy in front of the IdP breaking the redirect chain; browser extension-like interference is rare here, but Chrome instances with cached 'block all cookies' settings from a previous profile do occur.

Understand the failure class

Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

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