Vendure 3.7.3 patches eleven vulnerabilities — upgrade now

If you run Vendure 3.x, the version you are on right now allows an attacker to take over any customer account that was created through an external or SSO authentication strategy. They register that account's email address with a password of their choosing, and the account is theirs. No credentials needed, no prior access, no admin session. That is one of four critical vulnerabilities fixed in 3.7.3, and it is the one that should get you out of whatever you were doing.

The release notes describe 3.7.3 as "a patch release containing fixes for eleven reported vulnerabilities (four critical, two high, five medium)," alongside seller-order channel scoping for multi-vendor setups, shipping-line corrections, CLI monorepo support, and dashboard fixes. The security half is not optional and the behaviour changes it drags in are the reason this upgrade needs a staging pass rather than a same-day npm update in production.

The four critical issues are account takeover and cross-tenant control

Ranked by what an attacker actually gets:

Unauthenticated account takeover (GHSA-wr5h-x3x6-4h23). Any customer account created through an external/SSO strategy could be claimed by registering that email with an attacker-chosen password. This is the only one on the list that needs nothing but a storefront and an email address. If you run SSO, social login, or any custom AuthenticationStrategy that provisions customers, assume exposure.

Cross-channel payment IDOR (GHSA-7qvr-c5vf-xxfh). An administrator scoped to one channel could issue refunds and drive payment and fulfillment transitions against orders in another channel — moving money out of another tenant's payment gateway. In a marketplace, that means one seller's staff account can refund against another seller's gateway.

Cross-channel entity capture (GHSA-422x-jq57-j238). An administrator could assign another channel's Product, Collection, Facet, ProductOptionGroup or ProductVariant into their own channel and hold ongoing edit and delete control over it.

Cross-channel channel management (GHSA-22x4-937q-5fr5). An administrator holding UpdateChannel or DeleteChannel could rename or permanently delete any channel in the system, regardless of role scope.

Three of the four require an authenticated admin session. That is precisely the point of a multi-vendor marketplace: you hand out admin sessions to people you do not employ and do not control.

A private API is not a security boundary

The common misread of headless is that the Admin API lives behind a VPN or an allowlist, so channel-scoping bugs are theoretical. They are not, for two reasons.

First, in a multi-vendor deployment the threat model is inside the perimeter. Seller staff are legitimate API clients. Every cross-channel bug above is exploitable by someone you already gave a login to.

Second, 3.7.3 fixes a permissive CORS default (GHSA-vr2h-89r2-9rwv): the default configuration reflects any Origin back with Access-Control-Allow-Credentials: true, and Apollo's CSRF prevention was disabled. That combination allows Login CSRF and cross-origin response reading. A browser with a live admin session is the delivery vehicle; network placement of the API does not help.

Add the medium-severity session token disclosure via job data (GHSA-32jm-mf7r-7qw5) — the serialized RequestContext in job data contained a session token readable and reusable by anyone with ReadSettings or ReadSystem — and the stored XSS via SVG upload (GHSA-f4r3-h6jf-4m29), where @vendure/asset-server-plugin served uploaded SVGs inline with an executable content type. Both are privilege escalation paths that start from an account you deliberately handed out.

Patch order depends on what you run

Same target for everyone — 3.7.3 is the release that fixes all eleven, and the notes are explicit: if you are on an earlier 3.x, upgrade. Urgency differs:

1. Multi-vendor or multi-channel with third-party admins. Emergency. All four criticals apply directly.
2. External/SSO authentication of customers. Emergency regardless of channel count. The account takeover does not care how many channels you have.
3. Single-channel, native password auth only. High but not an emergency. You are still exposed to the CORS default, the SVG XSS, the account enumeration by login timing (GHSA-c63h-3vvx-48ph — the 3.5.3 mitigation missed accounts that exist with no native password), and the session token in job data.

Do not stage this through 3.7.0–3.7.2. They do not carry the fixes. Go to 3.7.3.

Several fixes change behaviour, so read the notes before you deploy

There are no breaking API changes, but the security fixes tighten previously permissive behaviour, and integrations built against the permissive version will break.

registerCustomerAccount no longer stores a supplied password when an account already exists for that email through another auth strategy and has no password yet. A verification token is emailed instead, and the password is set by passing that token to verifyCustomerAccount — regardless of authOptions.requireVerification. Such a customer cannot log in immediately after registering. Caller-supplied firstName, lastName, phoneNumber and custom fields are now ignored whenever a User already exists for the email. If your storefront's registration flow assumes immediate login, it is broken as of this upgrade.

Channel scoping now throws where it previously succeeded: duplicateEntity, assign-to-channel and remove-from-channel, updateChannel, deleteChannel, createProductOption, and Order payment, refund, fulfillment and customer note operations. deleteProductVariant and deleteProductVariants now throw EntityNotFoundError for an unknown id or one not in the active channel, where they previously returned DELETED silently. If you have delegated these to channel-scoped roles that operate across channels — an ops tool, a sync script, an integration service account — those calls will start failing.

Also: the administrators and administrator queries now only return administrators whose roles the caller has authority over. The asset server sends X-Content-Type-Options: nosniff and a CSP on every asset and serves SVG, HTML and XML with Content-Disposition: attachment, so opening those URLs directly downloads rather than renders (<img src> embeds are unaffected). Vendure now warns at startup when apiOptions.cors reflects any origin with credentials: true — set an explicit allowlist. apiOptions.csrfPrevention enables Apollo's built-in CSRF prevention on both APIs and defaults to false; enabling it imposes requirements on your clients. The file-type bump to ^21.3.1 in @vendure/core and @vendure/asset-server-plugin (for GHSA-5v7r-6r5c-r473, an infinite loop on malformed ASF input) renames four MIME types.

Shipping lines and seller orders can move totals quietly

The non-security changes most likely to surprise you are in order pricing. Shipping lines are no longer removed from an order when the shipping method is deleted, and active orders are recalculated when a shipping method is unassigned from a channel (#4492, #4494). Both are correct, and both change totals on existing orders relative to the old behaviour.

The seller Order channel-scoping work (#5100) changes more: price adjustments are now applied in the seller's channel, shipping lines are preserved when an order is split, and shipping promotions are re-applied to seller orders. If you run a marketplace with order splitting, your seller-order totals will differ after this upgrade — as they should, but verify rather than discover it in a payout reconciliation.

Regression-test in staging with production-shaped data: split an order across sellers and compare seller totals before and after; delete a shipping method that live orders reference; unassign a shipping method from a channel and confirm recalculation; run registration against an email that already exists under an SSO strategy; exercise every integration service account against the newly-throwing channel-scoped mutations.

What to do this week

Upgrade to 3.7.3 now if you run multi-vendor or external auth; schedule it inside the week otherwise. Then set an explicit CORS origin allowlist in production instead of relying on the default — the startup warning exists because the default is not safe. Audit which channel-scoped roles hold UpdateChannel and DeleteChannel and revoke what does not need them; the fix closes the hole, but the permission grant was too broad to begin with. Rotate admin sessions if anyone with ReadSettings or ReadSystem is outside your trust boundary. Review historical refunds across channels if you run a marketplace — the IDOR was exploitable before you patched, and the patch does not tell you whether it was used.

We track this kind of release because upgrade discipline is what makes a headless backend cheaper to own than the platform it replaced — a Vendure or Medusa build is only lower-maintenance than Magento if someone is actually reading the security advisories. If you are weighing a move off a legacy platform and want a straight answer about what ongoing maintenance really looks like, or you are mid-migration and want another set of eyes on channel scoping and permission design before launch, get in touch.