High-severity findings.

Audited release

1.6165

Findings

3

Worst severity

high

Content hash

c13577d2fbca8065e3d0947f… Copy

Findings

• high Login URL hardening treatment bricks wp-login.php

  insecure_config

  Applying the shipped login-url-hardening treatment stores a 16-character mixed-case token in thisismyurl_shadow_login_url_token and then rejects every wp-login.php request whose GET wpstoken does not hash_equals that value. Two independent bugs make a successful login impossible: (1) WordPress core login/logout/lost-password forms post to site_url('wp-login.php') / site_url('wp-login.php','login'), which do not run the login_url filter, so the token is dropped on POST and on logout/reset URLs; password-reset emails from core also omit it. (2) on_login_init runs the supplied token through sanitize_key() (strtolower) before comparing it to the stored mixed-case value from random_bytes/base64, so even a correctly bookmarked GET URL fails whenever the token contains uppercase letters. Observable consequence: after an administrator clicks Fix on this finding, wp-login.php 302s to the homepage for everyone, including the current admin after their session expires. Recovery requires deleting the option via WP-CLI or the database. The UI confirmation toggle is not enforced in apply().

  includes/systems/core/class-treatment-hooks.php:302-318

  Recommendation

  Do not gate wp-login.php solely via login_url. Append the token on the site_url/network_site_url 'login' and 'login_post' schemes (or rewrite wp-login.php), preserve it on logout and reset URLs, compare the raw GET value with hash_equals against a lowercase hex/base32 secret, and refuse to enable the gate until apply() verifies the confirmation input. Add an emergency bypass (define in wp-config) documented in the treatment message.

• medium Login URL secret is leaked on every public login_url() output

  information_disclosure

  Treatment_Hooks::filter_login_url unconditionally appends wpstoken=<secret> to every URL produced by wp_login_url(). That helper is used by wp_loginout(), comment forms, many themes' header/footer login links, and third-party plugins. Once the treatment is enabled, the 'secret' that is supposed to hide wp-login.php is present in public HTML and in any email that goes through login_url. Combined with the lockout bugs, this both advertises a token that does not actually unlock login and, if the comparison is later fixed without changing the leak, would let any visitor recover the gate token from page source.

  includes/systems/core/class-treatment-hooks.php:281-287

  Recommendation

  Stop attaching the token to globally filtered login_url() output. If a hide-login control is required, use a rewrite slug that is never printed on the front end (WPS Hide Login model), or inject the token only into admin-generated bookmark copy shown once after apply().

• medium Login throttle and comment rate-limit trust client-controlled forwarding headers

  dos

  When login-throttling-active or form-rate-limiting-active is applied, Treatment_Hooks::get_visitor_ip() returns the first IP in HTTP_CF_CONNECTING_IP or HTTP_X_FORWARDED_FOR without confirming the request actually came from Cloudflare or a trusted proxy. An unauthenticated attacker can send five failed logins with X-Forwarded-For set to an administrator's IP and lock that IP out for one hour (authenticate returns WP_Error thisismyurl_shadow_login_lockout), or rotate the header to bypass the 5-attempt / 15-minute window. The same helper keys comment flood transients, so anonymous comment limits are equally spoofable. Login throttling is classified risk=safe and is auto-applied by Scan_Frequency_Manager::apply_automatic_treatments() on Guardian runs when run_treatments is true (the default in get_scan_config()).

  includes/systems/core/class-treatment-hooks.php:871-884

  Recommendation

  Use REMOTE_ADDR unless the site has an explicit trusted-proxy setting (or Cloudflare is detected via authentic CF headers / connecting IP ranges). Never take the left-most X-Forwarded-For hop by default. Document that login throttling is not safe to auto-apply on hosts without a real proxy hop.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.