Acceso Seguro – Control de acceso y registro avanzado WP Registry grade B. Medium-severity findings · 2 findingsWP RegistryMedium-severity findings · 2 findingsOpen the reportB

Medium-severity findings.

Audited release

1.1.0

Findings

2

Worst severity

medium

Content hash

729940399cd6c3161de0054d… Copy

Findings

• medium Default-on AJAX registration ignores users_can_register and does not need the popup

  missing_auth

  wp_ajax_nopriv_as_register is always registered. The only feature flag is Options::get('general.allow_register', true), which defaults to true in setDefaultsIfEmpty and never consults get_option('users_can_register') or WooCommerce’s my-account registration setting. A valid as_auth nonce is printed in wp_head on every front-end page (acceso-seguro.php), including when general.popup_auto is false and no shortcode is present, so an unauthenticated visitor can POST email/password/privacy=1 to admin-ajax.php and obtain a default_role account via wp_create_user (or wc_create_new_customer) plus wp_signon autologin. Role is not attacker-controlled. Sites that disabled membership in Settings → General and installed this plugin for antispam still expose account creation.

  src/Integrations/AjaxEndpoints.php:14-15,113-187

  Recommendation

  Default allow_register to false (or to (bool) get_option('users_can_register')). Gate handleRegister on both the plugin flag and users_can_register (and WooCommerce’s registration option when WC is active). Only print the as_auth nonce / register the AJAX action when the popup or a shortcode is actually on the page.

• medium Untrusted CF-Connecting-IP / X-Forwarded-For can lock IPs out of login

  dos

  ClientIp::get() prefers HTTP_CF_CONNECTING_IP then the first HTTP_X_FORWARDED_FOR hop with no trusted-proxy check and no FILTER_VALIDATE_IP. ProgressiveBlocker::ctxIpHash() always hashes that value, and Engine::evaluate() consults isBlocked() before any other check. WordPressHooks::filterAuthenticate (priority 5) runs this engine on every password authentication, including wp-login.php, wp_signon, and XML-RPC. An unauthenticated attacker who sets CF-Connecting-IP to a victim address and submits one as_login (or wp-login.php) with a short username (default username.short_points=40 ≥ score_threshold=8) writes {$prefix}as_blocks for action=login; the victim’s subsequent logins return WP_Error as_blocked for 5, then 30, 120, and 1440 minutes as strikes escalate. The default transient rate limiter still keys on REMOTE_ADDR, but general.rate_limit_storage=db uses ClientIp::hash() and can be bypassed by rotating the same headers. filter_var is never applied, so any header string becomes the block key.

  src/Infra/ClientIp.php:8-31

  Recommendation

  Use REMOTE_ADDR unless the request is from a configured trusted proxy, and then only honor CF-Connecting-IP / X-Forwarded-For from that proxy. Validate with filter_var(..., FILTER_VALIDATE_IP). Use one IP source for rate limit, progressive block, and logs. Consider requiring a confirmed failed password before counting login strikes so a single spoofed probe cannot lock an IP.

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.