Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
External-authentication account takeover: external login linked to a pre-existing account by email without requiring verification Package: @vendure/core (vendure-ecommerce/vendure, latest master) · [!IMPORTANT] This vulnerability only affects deployments that use external / social authentication (an AuthenticationStrategy other than the built-in native email/password strategy) where that strategy can return an email address the external provider has not verified the user owns. You are affected if all of these are true: - Your store configures one or more external AuthenticationStrategy implementations (custom OAuth / social login / SSO), and - At least one forwards an emailAddress to ExternalAuthenticationService without guaranteeing the provider verified ownership of it (e.g. it doesn't check the provider's emailverified claim, or leaves verified unset/false), and - Customer accounts exist that share an email address with those external identities. You are NOT affected if: - You use…
Recommended action: Upgrade to 3.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Shop API products, collections and facets queries inject a mandatory filter to restrict results to publicly-visible entities (Product.enabled = true, Collection.isPrivate = false, Facet.isPrivate = false). This injected guard was combined with the caller-supplied filter using the caller-controlled filterOperator. When a caller sets filterOperator: OR, the guard is OR-combined instead of AND-combined, so a caller can retrieve disabled products and private collections/facets by supplying a predicate that matches them. Impact Exposure of catalog entities intended to be hidden from the Shop API. The Shop API is publicly accessible, so no authentication is required. Patches The injected guard is now always AND-combined with the caller-supplied filter, regardless of filterOperator. Workarounds None other than upgrading.
Recommended action: Upgrade to 3.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
[!IMPORTANT] Only instances running on the SQLite driver (better-sqlite3) are affected; SQLite is usually used in development/testing backend, so production deployments on PostgreSQL or MySQL/MariaDB are unaffected. The StringOperators.regex filter exposed on the public Shop GraphQL API is evaluated inside the Node.js event loop via a synchronous SQLite user-defined function (UDF). Supplying a catastrophically backtracking pattern blocks the entire event loop, causing a complete denial of service with no authentication required. --- Details Vendure registers a JavaScript UDF so that SQLite can handle the REGEXP operator: packages/core/src/service/helpers/list-query-builder/list-query-builder.ts lines 917–931 The pattern argument is the raw value of StringOperators.regex submitted by the caller. No length limit, timeout, or safe-regex validation is applied before constructing new RegExp(pattern). packages/core/src/service/helpers/list-query-builder/parse-filter-params.ts lines…
Recommended action: Upgrade to 3.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated SQL injection vulnerability exists in the Vendure Shop API. A user-controlled query string parameter is interpolated directly into a raw SQL expression without parameterization or validation, allowing an attacker to execute arbitrary SQL against the database. This affects all supported database backends (PostgreSQL, MySQL/MariaDB, SQLite). The Admin API is also affected, though exploitation there requires authentication. Affected versions - @vendure/core < 2.3.4 - @vendure/core = 3.0.0, < 3.5.7 - @vendure/core = 3.6.0, < 3.6.2 Note: versions 2.3.4 and above in the 2.x line are patched. There were no 2.4.x or 2.x releases between 2.3.x and 3.0.0. Patched versions - @vendure/core 2.3.4 - @vendure/core 3.5.7 - @vendure/core 3.6.2 Details In ProductService.findOneBySlug, the request context's languageCode value is interpolated into a SQL CASE expression via a JavaScript template literal: TypeORM has no opportunity to parameterize this value because it is…
Recommended action: Upgrade to 3.6.2, 3.5.7 or 2.3.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NativeAuthenticationStrategy.authenticate() method is vulnerable to a timing attack that allows attackers to enumerate valid usernames (email addresses). Details In packages/core/src/config/auth/native-authentication-strategy.ts, the authenticate method returns immediately if a user is not found: The significant timing difference (~200-400ms for bcrypt vs ~1-5ms for DB miss) allows attackers to reliably distinguish between existing and non-existing accounts. Impact - Attackers can enumerate valid user accounts - Enables targeted brute-force or phishing attacks - Information disclosure (account existence) Recommended Fix Perform a dummy bcrypt check when user is not found to ensure consistent response times.
Recommended action: Upgrade to 3.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Currently, in many Vendure deployments it's possible to select any currencyCode (really any, doesn't need to be assigned to the channel) and pay through Mollie and Stripe in that particular currencyCode. The prices are not transformed. The result is the Order is in Payment Settled in the foreign currency. See SS, CZK is not in the channel. I've tested with Mollie and Stripe it both works. Further notes After looking into this further and with help from the comments below, the root cause of this vulnerability is the ability to specify an arbitrary currencyCode as a query parameter to an API call, and then Vendure will use this and pass it to the rest of the system as RequestContext.currencyCode. The solution is to add validation to the passed currencyCode to ensure that it matches one of the available availableCurrencyCodes of the active Channel. Furthermore, an additional check has been added for when the currencyCode changes during the AddingItems stage - in this case we need…
Recommended action: Upgrade to 2.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Vendure is an e-commerce GraphQL framework with a number of APIs and different levels of authorization. By default the Cookie settings are insecure, having the SameSite setting as false which results in not having one (originates from the cookie-session npm package’s default settings). Patches In progress Workarounds Manually set the authOptions.cookieOptions.sameSite configuration option to 'strict', 'lax' or true. References Are there any links users can visit to find out more?
Recommended action: Upgrade to 2.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.