Skip to content

CVE-2026-7567 - WordPress Temporary Login auth bypass

The WordPress Temporary Login plugin versions <=1.0.0 contain a critical authentication bypass. The vulnerable login path does not first prove that the temp-login-token request value is a scalar string. When an unauthenticated attacker sends the token parameter as an array, the token lookup can be reduced to an empty value and WordPress may return users that have the temporary-login token metadata key.

The result is account takeover for any currently active temporary-login user, including high-privilege support or administrator access that a site owner created through the plugin. Wordfence lists 1.1.0 as the first patched version, and the public WordPress plugin directory currently offers newer fixed releases.

Affected versions

  • Vulnerable: Temporary Login WordPress plugin <=1.0.0
  • Fixed: Temporary Login WordPress plugin >=1.1.0
  • Preferred: Update to the latest available plugin release on the normal deployment channel, not just the minimum fixed release.

Indicator-of-exposure

  • The repository owns a WordPress site, image, Bedrock/Composer project, plugin bundle, deployment manifest, or runbook that installs temporary-login.
  • A deployable WordPress target resolves Temporary Login 1.0.0 or older.
  • The plugin is active in production or staging and temporary-login users may exist.
  • The public WordPress site can receive requests containing temp-login-token[] or equivalent array syntax.

Quick checks:

wp plugin list --fields=name,version,status | grep -E '^temporary-login[[:space:]]'
wp plugin status temporary-login
rg -n "temporary-login|wpackagist-plugin/temporary-login|temp-login-token|_temporary_login_token" .
find . -path "*/wp-content/plugins/temporary-login/*" -maxdepth 8 -type f | head

Remediation strategy

  • Upgrade Temporary Login to 1.1.0+, preferably the latest release available through WordPress.org, Composer/WPackagist, WP-CLI, or the repository’s plugin artifact channel.
  • If the plugin is not business-critical, remove or deactivate it and document the replacement support-access process.
  • Revoke all active temporary-login users after patching because exposed sites cannot trust existing temporary access links.
  • Review authentication logs, web access logs, and WordPress users for requests containing temp-login-token[], unexpected temporary-login use, or unexpected administrator activity.
  • If immediate upgrade is blocked, add temporary edge/WAF protection for array token requests and disable the plugin until a patched release is deployed.

The prompt 

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-7567 (WordPress Temporary Login authentication
bypass). Produce exactly one output:

- A reviewer-ready PR/change request that upgrades or removes the vulnerable
  plugin and documents required operator cleanup, or
- TRIAGE.md if this repository does not own the WordPress plugin deployment or
  cannot make a safe patch.

## Rules

- Scope only CVE-2026-7567.
- Treat all temporary-login URLs, tokens, cookies, and WordPress session data as
  secrets. Do not print them in logs, test output, screenshots, or PR text.
- Do not silently create, delete, demote, or relink WordPress user accounts.
- Do not hand-edit vendored plugin code unless no package/channel upgrade is
  available and the patch is explicitly documented as temporary.
- Do not auto-merge.

## Steps

1. Inventory WordPress ownership in this repository:
   - `wp-content/plugins/temporary-login`;
   - Composer or Bedrock references such as
     `wpackagist-plugin/temporary-login`;
   - WP-CLI install scripts, Dockerfiles, build artifacts, Helm charts,
     Terraform, Ansible, or deployment runbooks;
   - SBOMs, image manifests, and plugin lock/state files.
2. If the repository does not deploy or package a WordPress site with the
   Temporary Login plugin, stop with `TRIAGE.md` explaining what was checked and
   who owns the runtime remediation.
3. Determine the resolved Temporary Login version for every deployable target.
   A target is vulnerable if it resolves to `<=1.0.0`.
4. For every vulnerable target, upgrade the plugin to `>=1.1.0`, preferably the
   latest WordPress.org release available through the repo's normal dependency
   channel. Regenerate Composer locks, plugin manifests, image metadata, SBOMs,
   or deployment render output as appropriate.
5. If the plugin is optional or only used for support access, prefer removal or
   deactivation over carrying a temporary access plugin. Update runbooks to use
   a controlled support-access workflow.
6. Add a PR body section named `CVE-2026-7567 operator actions` that requires:
   - revocation of all active Temporary Login links/users after deployment;
   - review of WordPress users with `_temporary_login_token` metadata;
   - review of web/auth logs for `temp-login-token[]`, `temp-login-token%5B%5D`,
     or unexpected temporary-login activity;
   - session invalidation for affected temporary users when feasible;
   - confirmation that production now runs Temporary Login `>=1.1.0` or that
     the plugin is disabled/removed.
7. Add or update verification that an array-form token request cannot
   authenticate, for example an integration test, a WP-CLI smoke-test note, or
   an operator curl check against a non-production site. Do not include real
   tokens.
8. If the fixed plugin cannot be deployed immediately, add the safest temporary
   containment controlled by this repo: disable the plugin, block requests where
   `temp-login-token` is an array, restrict wp-admin access at the edge, or add
   an emergency runbook instructing operators to revoke temporary logins.
9. Run the relevant validation: Composer install/update checks, WordPress plugin
   inventory, image build, deployment rendering, PHP tests, and security scan
   available in this repository.
10. Use PR title:
    `fix(sec): remediate CVE-2026-7567 in Temporary Login`.

## Stop conditions

- No WordPress site or Temporary Login plugin deployment is controlled by this
  repository.
- The plugin version is managed exclusively in production outside the repo.
- A fixed plugin release cannot be consumed without a broader WordPress
  platform migration.
- The only apparent fix would automatically modify WordPress user accounts or
  expose temporary-login tokens.
- Validation fails for unrelated pre-existing reasons; document the failure
  instead of broadening scope.

Verification - what the reviewer looks for

  • No deployable target still resolves Temporary Login <=1.0.0.
  • The PR updates the real plugin delivery path, such as Composer lockfiles, WP-CLI install scripts, plugin artifact bundles, images, or deployment manifests.
  • Temporary-login revocation, log review, and session cleanup are explicit operator actions.
  • Verification covers temp-login-token[] or URL-encoded array syntax and does not expose real temporary-login tokens.
  • Build, dependency, image, and deployment checks pass or unrelated failures are documented.

Watch for

  • WordPress repositories that vendor plugins under wp-content/plugins while also installing plugins through Composer or WP-CLI.
  • Production plugin drift where the repository pins a safe version but runtime WordPress auto-updates or manual plugin management tell a different story.
  • Fixes that only block one spelling of the array parameter and miss encoded or repeated-parameter forms.
  • Treating user cleanup as a code-only problem; account/session review must stay operator-controlled.

References