| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.7, 11.4.7, and 12.0.10, SAML.verifySamlResponseSignature calls OpenSAML SignatureValidator.validate without first applying SAMLSignatureProfileValidator. The Core can therefore accept a cryptographically valid signature that references a different XML element from the Response or Assertion whose NameID and attributes are used for authentication. An ordinary user of the configured identity provider can move a genuinely signed element elsewhere in the document while supplying an attacker-authored identity-bearing element, causing XML Signature Wrapping authentication as another IdP user. Both response-level and assertion-level signing paths are affected, and SP-initiated login remains reachable without enabling allowIDPInitiatedLogin. This issue is fixed in versions 11.3.7, 11.4.7, and 12.0.10. |
| SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, a licensed deployment with a configured SAML client can authenticate an identity from an assertion that did not satisfy the audience check. When the identity provider uses assertion-level signing, an attacker who has a still-valid IdP-signed assertion naming the victim for any audience and the attacker's own valid assertion for the target audience can combine them because validateSamlResponseAudience accepts an audience from one assertion while extractAllClaims takes the final NameID and attributes from another; response-level signing does not expose this multi-assertion variant. Independently, an assertion from an identity provider configured for the target deployment but issued to another SuperTokens deployment using the shared default saml_sp_entity_id can satisfy the target's audience check. Successful exploitation authenticates the attacker as the victim IdP user. This issue is fixed in versions 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1. |
| The ManageWP Worker WordPress plugin before 4.9.37 does not bind the account being logged in to the signature which authorises the login, nor prevent an already used login link from being replayed, allowing attackers who obtain such a link to gain a session as any user on the site, including an administrator. |
| The Firebase Authentication WordPress plugin before 1.7.1 does not require the email address in an authentication token to be verified before matching it to a WordPress account and issuing a session, allowing unauthenticated attackers to log in as any user, including administrators. |
| The WP Social Media Login WordPress plugin through 1.0.6 does not verify that a social login was actually completed with the identity provider before authenticating a visitor, allowing unauthenticated attackers to log in as any existing user, including administrators, by supplying that user's email address. |
| The SmilePass Selfie Login WordPress plugin through 1.0.2 does not perform any server-side verification of the identity it is asked to authenticate, allowing unauthenticated users to log in as any registered account, including administrators. |
| The Booking for Appointments and Events Calendar WordPress plugin before 2.4.7 does not require authentication before processing its pending notification queue, allowing an unauthenticated user to force the dispatch of queued notifications and integration callbacks. |
| The BlogVault Backup & Staging WordPress plugin before 6.65, MalCare WordPress Security Plugin WordPress plugin before 6.65, The WP Remote WordPress Plugin WordPress plugin before 6.65 do not prevent unauthenticated users from obtaining data derived from the secret that binds a site to its remote management service, and generate that secret with a weak pseudo-random number generator, allowing attackers to recover it and gain administrative access to the site. |
| The User Profile Builder WordPress plugin before 4.0.1 does not properly restrict its front-end file upload feature, granting unauthenticated visitors capabilities reserved to privileged roles. This allows them to list the site's media library and to modify unpublished posts, pages and media items belonging to other users. |
| The OAuth Single Sign On WordPress plugin before 7.0.1 does not verify the identity assertion returned by its Steam single sign-on flow, allowing unauthenticated attackers to log in as an arbitrary non-administrator user, and to create new accounts. |
| The AutoNetTV Relay WordPress plugin before 3.0.14 does not perform any capability or authentication check before setting a WordPress administrator authentication cookie during its scheduled content-synchronization task. On server configurations where the scheduled task executes before the HTTP response is committed, an unauthenticated attacker who triggers the due task can receive the administrator's session cookie and gain administrator access without credentials. |
| The Block User Account WordPress plugin before 2.0.1 does not enforce its account block on every authentication path, allowing a blocked user who holds an application password created before the block to retain their full role-level read and write access through the REST API. |
| The CheckView WordPress plugin before 2.3.2 does not restrict its REST API authentication filter to its own routes and unconditionally discards the authentication error raised for any request whose URI merely contains a CheckView WordPress plugin before 2.3.2-specific string, making it possible for unauthenticated attackers to bypass the REST nonce check and perform any REST action available to a logged-in administrator, such as creating a new administrator account, via a crafted link an administrator is tricked into opening. |
| The Epeken All Kurir for Woocommerce WordPress plugin through 2.1.4 does not verify that a payment-confirmation request originates from the owner of the targeted order, nor that any payment actually occurred, allowing unauthenticated attackers to mark arbitrary orders as confirmed and, in a non-default configuration, paid. |
| The Backup Migration WordPress plugin before 2.1.7 does not properly restrict a post-restore automatic login mechanism, allowing a user who administers one site of a multisite network to obtain a long-lived authenticated session as an administrator of another site in the same network, without credentials and bypassing two-factor authentication. |
| The TabaPay Gateway WordPress plugin through 1.4.0 does not validate the payment callback before establishing a session for the account associated with the referenced order, allowing unauthenticated attackers to log in as any registered user, including an administrator. |
| The SAML Single Sign On WordPress plugin before 5.4.7 does not verify the signature of a SAML response before storing the certificate it carries, and offers an administrator a one-click control that promotes that stored certificate to the site's trusted signing certificate, allowing unauthenticated attackers to have a certificate of their own trusted and then authenticate as any user, including an administrator. |
| The WPML Multilingual CMS plugin for WordPress is vulnerable to Authentication Bypass via Race Condition in versions up to, and including, 4.9.7. This is due to the `process_iframe_request` function's language-per-domain SSO handler generating the cross-domain sign-in token via `wp_create_nonce('wpml_sso')` on the logout landing page, where the browser has already discarded its authentication cookies — so `wp_get_session_token()` returns an empty string and the token collapses to the shared anonymous nonce for the current 12-hour tick rather than a user-bound secret — and then storing it in the `wpml_sso_user_<token>_<sha256('wpml_sso'.$domain)>` transient mapped to the victim's `user_id` with no binding to the specific sign-out action or requesting client. Because an unauthenticated attacker can independently derive the identical token by triggering the logout confirmation flow on `wp-login.php?action=logout`, and because the `is_iframe_request()` gate conditions (the per-domain SSO `started` transient and domain-hash derived from the public constant `SSO_NONCE`) are fully computable within the 60-second `SSO_TIMEOUT` window, an unauthenticated attacker can submit the forged `wpml_sso_token_domain` parameter with a `wpml_user_signed_in` status to a secondary language-domain endpoint before the legitimate `wpml_user_signed_out` iframe fires, causing WordPress authentication cookies to be issued for the victim. This makes it possible for unauthenticated attackers to gain access to accounts of users — including administrators — who are actively in the process of logging out during the race window. |
| Improper Authentication in Apache Roller 5.1.0 through 6.1.6 allows a user whose account an administrator has disabled to sign in again through OpenID and read unpublished entries. The OpenID sign-in path did not check whether the account was enabled. Only sites that enable the non-default OpenID authentication mode are affected; later major versions do not include OpenID 2.0. Users are recommended to upgrade to Apache Roller 6.1.7 or later. |
| The Printaura-Woocommerce WordPress plugin through 4.0.2 does not properly restrict access to the WooCommerce REST API, causing every WooCommerce REST route to accept unauthenticated requests, which allows unauthenticated attackers to read and modify store data including customer orders and personal information, store and payment settings, and webhooks. |
