Socialify WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

0.9.251011

Findings

2

Worst severity

high

Content hash

8485cd1ceb29f4452263a270… Copy

Findings

• high OAuth login auto-authenticates existing users by email and permanently links the provider

  auth_bypass

  Google and Yandex actionAuth call authenticateByProviderProfile → tryRegisterUserByProviderProfile. If the IdP profile email exists in wp_users, the plugin loads that user, saveDataToUserMeta (permanent socialify_{provider}_id_* binding), and setCurrentUser (wp_set_auth_cookie, remember=true) with no prompt. This runs before the users_can_register check, so it works even when registration is disabled, and it applies to administrators who never used social login. HybridAuth Google already sets emailVerified from oauth2/v3 userinfo email_verified; the plugin never reads that field and will honor a missing/unverified email. wp_set_auth_cookie bypasses password and typical 2FA plugins that hook wp_authenticate. After the first matching login, getUserByIdFromProvider succeeds forever on that provider id even if the WP email later changes. Google and Telegram actionAuth also skip isEnabled(), so a provider whose checkbox was turned off still authenticates if credentials remain in socialify_config. Observable: unauthenticated GET /wp-json/socialify/google-auth or yandex-auth yields an auth cookie for the matching wp_users row and new usermeta keys socialify_google / socialify_yandex.

  includes/AbstractProvider.php:209-241

  Recommendation

  Do not log in or link an existing WordPress user solely because emails match. Require providerProfile->emailVerified (Google) and a verified Yandex email, then require an explicit link confirmation while the user is already authenticated (password/email). Refuse auto-link when users_can_register is off unless that user already has socialify_{provider}_id_* meta. Honor isEnabled() on every auth route. Let 2FA plugins run (do not call wp_set_auth_cookie as the only login path without wp_signon / wp_authenticate).

• medium Post-login open redirect via unrestricted _redirect_to / Yandex state

  unsafe_input

  redirectAfterAuth() takes $_GET['_redirect_to'] and, if filter_var(..., FILTER_VALIDATE_URL) succeeds, wp_redirects to that URL. That helper runs after Google/Telegram auth, after connect, and after disconnect. FILTER_VALIDATE_URL allows any absolute http(s) URL, unlike wp_validate_redirect / wp_safe_redirect which restrict to the site host. Telegram auth copies _redirect_to onto the widget data-auth-url, so the parameter survives the IdP round-trip on the domain allowlist (BotFather domain, not a full-URI allowlist). Yandex actionConnect treats OAuth state as the redirect target the same way (state is set from _redirect_to in request_code) and wp_redirects it after linking. Disconnect is a same-request GET, so /socialify/google-disconnect?_redirect_to=https://evil.example is an immediate external redirect for any logged-in user. After a successful social login the auth cookie is already set, so this is a post-authentication phishing/relay redirect and also hides the connect-CSRF success page. Observable: HTTP Location: https://attacker.example after wp_set_auth_cookie.

  includes/AbstractProvider.php:125-134

  Recommendation

  Replace wp_redirect(filter_var URL) with wp_safe_redirect(wp_validate_redirect($redirect_to, home_url('/'))). Do not put the raw redirect URL in OAuth state; store a signed token or a relative path. Drop _redirect_to from Telegram callback URLs or allowlist it to local paths only.

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.