Medium-severity findings.

Audited release

1.4.0

Findings

2

Worst severity

medium

Content hash

68c9fa68bc0c6468a591fa12… Copy

Findings

• medium Unauthenticated destruction of pending OnePress SSO tokens

  missing_auth

  GET/POST wp-login.php?mpcp_token= is handled on plugins_loaded with no capability or nonce check. The handler base64-decodes the parameter, explode('-')s it into user_id, token, site_id, user_agent, constructs WP_User from the first field (numeric ID, or login name when non-numeric — so 'admin' works), then immediately delete_user_meta($user->ID, 'mpcp_auth_token') before testing emptiness, expiry, User-Agent, or md5(token). Pressable's API plants that meta as a 30-second one-time secret (POST /v1/sites/{id}/one_press_login). Any unauthenticated visitor who sprays base64('{id}-x-x-x') for common IDs/logins therefore burns a live SSO attempt and learns from the redirected one_click_error whether a pending token was present ('User not found' vs expired/UA/invalid). Password login still works; the blast is denial and oracle of the control-panel magic login, not a session. The same delete-first order also means a stolen URL and a junk request racing the victim will invalidate the secret even when the junk token cannot log in.

  class-pressable-onepress-login-plugin.php:22-40

  Recommendation

  Do not delete mpcp_auth_token until after expiry, User-Agent, and hash_equals(md5($token), $meta['value']) all succeed. Reject non-existent users before touching meta. Rate-limit failures per IP/user_id and return a single generic error so presence of a pending token is not oracled. Keep the post-success delete (single use).

• medium OnePress User-Agent binding is taken from the URL, not stored meta

  auth_bypass

  Pressable documents that the generated SSO URL 'must' be visited by a browser whose User-Agent is an exact match for the user_agent passed into POST /v1/sites/{id}/one_press_login. The plugin implements that check as md5($_SERVER['HTTP_USER_AGENT']) !== $user_agent, where $user_agent is the fourth hyphen-separated field of the attacker-controlled mpcp_token string. Stored user meta only contains ['exp'] and ['value'] (md5 of the secret); the UA hash is never persisted. Anyone who obtains a still-valid URL (API JSON, proxy logs, a slow custom integration inside the 30s TTL) can base64-decode it, replace the fourth field with md5 of their own User-Agent, re-encode, and complete wp_set_auth_cookie as the target Administrator without spoofing the original UA. The md5 comparison is also not hash_equals, but single-use plus delete-first currently prevents timing use. This does not mint a session without the platform-issued secret; it removes the only documented stolen-URL binding.

  class-pressable-onepress-login-plugin.php:77-95

  Recommendation

  Store the User-Agent hash (or a HMAC of it) inside mpcp_auth_token alongside exp/value when the control plane plants the secret, and compare the request UA to that stored value with hash_equals. Do not trust a UA digest carried in the URL. Prefer a HMAC over the whole token payload keyed by a site secret so fields cannot be rewritten independently.

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.