High-severity findings.

Audited release

0.3.0

Findings

4

Worst severity

high

Content hash

ddd6486ba83be7bccb7b4db9… Copy

Findings

• high Okta-only mode does not disable WordPress password authentication

  auth_bypass

  The setting labeled 'Allow Native WordPress Login' claims that when unchecked, 'Okta will be the only way users can log in.' Enforcement is only in OktaSignIn::useWordpressLogin(), which is consulted from login_init to decide whether to render the widget or return to core wp-login.php. The first branch returns true for every HTTP POST before the option is read, so a crafted POST to wp-login.php (log/pwd or lostpassword) still runs wp_signon() / core password reset. The plugin never hooks authenticate, xmlrpc_enabled, or REST application passwords, so those password paths remain open too. An attacker with stolen or reused WordPress credentials — exactly what Okta MFA is meant to stop — logs in without Okta. The intended emergency GET bypass (?wordpress_login=true) is itself gated on get_option('okta-allow-wordpress-login') === null || === '1'; get_option returns false (not null) when unset, so that GET bypass is dead on a default install while POST always works.

  okta-widget.php:126-150

  Recommendation

  Do not treat REQUEST_METHOD=POST as permission to use native login. When okta-allow-wordpress-login is not enabled, hook authenticate (and disable XML-RPC / application-password auth) to reject password credentials, and only allow the native form POST when the documented wordpress_login=true fallback is on. Compare the option with a real empty/false value rather than === null.

• high Public ID-token login mints a WordPress session from a query-string JWT

  auth_bypass

  login_init handles unauthenticated GET wp-login.php?log_in_from_id_token=<jwt> with no nonce or capability check. logUserIntoWordPressWithIDToken POSTs the raw token to the issuer's introspection endpoint with only client_id (SPA public client). If claims['active'] is true, logUserIntoWordPressFromEmail takes claims['email'], get_user_by('email') or wp_create_user, then wp_set_current_user / wp_set_auth_cookie — including when that email is an administrator. After introspection the plugin never checks aud against okta-widget-client-id, iss against okta-issuer-url, token_type, or email_verified, so a valid token minted for a different Okta app on the same authorization server, or an unverified email claim, is enough to link or create the WP user. wp_remote_post failures are tested with === false (WordPress returns WP_Error, never false). The widget then puts the bearer token in the query string (templates/sign-in-form.php and log-in-existing-session.php), so it lands in access logs, proxies, and browser history and can be replayed until expiry.

  okta-widget.php:111-114,162-221

  Recommendation

  Switch to authorization-code + PKCE with server-side code exchange so the ID token never appears in a URL. After introspection (and is_wp_error / HTTP status checks), require aud, iss, exp, and email_verified before linking. Do not auto-link an existing administrator solely by email without those checks. Pass tokens in POST body or a one-time server-side code, not query strings.

• medium Open redirect after login via unsanitized redirect_to

  unsafe_input

  loginAction copies unsanitized $_GET['redirect_to'] into $_SESSION['redirect_to']. addLogInExistingSessionAction also sets that session key from $_SERVER['REQUEST_URI'] on every logged-out front-end request. After a successful ID-token login, logUserIntoWordPressFromEmail calls wp_redirect($redirect_uri) instead of wp_safe_redirect()/wp_validate_redirect(), so an absolute external URL is honored. An unauthenticated attacker sends a victim to wp-login.php?redirect_to=https://evil.example/; after Okta authentication the browser is sent off-site (phishing). A protocol-relative REQUEST_URI such as //evil.example can be stored the same way. WordPress core login uses wp_safe_redirect specifically to block this.

  okta-widget.php:101-104,215-221

  Recommendation

  Replace wp_redirect with wp_safe_redirect(wp_validate_redirect($redirect_uri, admin_url())) and allow only relative paths on the current site. Do not persist raw REQUEST_URI or redirect_to in the session without the same validation.

• medium Unsupported proof-of-concept SSO plugin with no maintenance path

  abandoned_plugin

  The v0.3.0 README states 'This is just a proof of concept!' The GitHub repo (oktadev/okta-wordpress-sign-in-widget) later added an explicit banner that the plugin is not supported by Okta, is not updated regularly, and that operators should use miniOrange instead; the last code change on main is from 2021 (v0.3.0 tags Okta Sign-In Widget 5.12.0 from CDN, while current widget releases are 7.x). There is no Update URI, so WordPress will not deliver fixes. An authentication plugin that mints sessions from IdP tokens is not safe to run unmaintained; the high findings above have no upstream patch in this tree.

  README.md:1-8

  Recommendation

  Do not run this sample in production. Replace it with a maintained OpenID Connect / Okta integration that performs authorization-code exchange and claim validation server-side, and remove this plugin.

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.