Array confusion in Temporary Login plugin allows unauthenticated takeover

TL;DR - temporary-login <= 1.0.0: send temp-login-token[] as a PHP array and token validation silently collapses. sanitize_key() returns an empty string, WordPress returns every user with the _temporary_login_token meta key, and an unauthenticated attacker logs in as the first one. Patched in 1.1.0.

What happened

Temporary Login is a WordPress plugin that creates time-limited access credentials - commonly used for handing off site access to support staff, contractors, or agencies.

Wordfence identified an authentication bypass in maybe_login_temporary_user(). The function reads the temp-login-token GET parameter but never enforces that it is a scalar string. Supply the parameter as an array - temp-login-token[] - and two things happen in sequence: PHP's empty() check passes, then sanitize_key() receives an array instead of a string and returns an empty string.

That empty string flows into a get_users() call as the meta_value filter. WordPress ignores an empty meta_value and returns every user matching the meta key _temporary_login_token. The attacker is then authenticated as an active temporary-login account - no valid token required. One crafted GET request.

This is the classic PHP type-confusion footgun: treat an HTTP parameter as a string without enforcing it, accidentally turn "no token" into "match everyone." It shows up regularly in WordPress plugin code because $_GET values can be arrays without any special effort from an attacker.

Who is impacted

• WordPress sites running temporary-login at versions <= 1.0.0.
• Highest risk: sites where temporary-login accounts are currently active - support handoffs, contractor access, agency staging credentials. Those are the accounts an attacker lands on.

What to do now

• Update immediately. Apply the patched release per vendor guidance.

  "Remediation: Update to version 1.1.0, or a newer patched version"

• Audit your WordPress fleet for the temporary-login plugin and confirm the installed version before assuming you're safe.
• Reduce immediate exposure while patching:
  • Expire or delete all active temporary-login accounts and tokens created by the plugin.
  • Search web server logs for requests containing temp-login-token%5B%5D or temp-login-token[] - array-style query parameters are a clear indicator of exploitation attempts.
• If you suspect compromise, treat this as a full session and credential integrity event:
  • Rotate credentials reachable from the WordPress runtime: database, SMTP, third-party API keys.
  • Invalidate all active sessions.
  • Audit WordPress admin user changes and role modifications for unexpected activity around the disclosure window.