Another instance — admin toolchain pins vite@^5.4.21 (blocks the only fix for GHSA-4w7w-66w2-5vf9)
Same pattern, the most clear-cut yet because the pin literally caps out below the only available fix:
@medusajs/admin-bundler → dependencies.vite: "^5.4.21"@medusajs/admin-vite-plugin → peerDependencies.vite: "^5.4.21"
^5.4.21 resolves to 5.4.21 (the newest 5.4.x), which is vulnerable to GHSA-4w7w-66w2-5vf9 (Vite path traversal in optimized-deps .map handling, vulnerable range <=6.4.1). There is no 5.x backport — the fix exists only in vite@>=6.4.2 — so the ^5.4.21 cap means apps on the Medusa admin toolchain cannot reach a patched Vite without forcing it past your declared range.
Good news: forcing it works. I overrode vite to ^8.0.16 in a 2.16-preview backend and the admin frontend builds cleanly:
@medusajs/admin-bundler → @medusajs/admin-vite-plugin → vite@8.0.16 (deduped)
...
info: Frontend build completed successfully (8.73s)
Only one non-fatal deprecation surfaced: optimizeDeps.rollupOptions / ssr.optimizeDeps.rollupOptions is deprecated → use optimizeDeps.rolldownOptions (Vite 8 is rolldown-based; the option is set by the admin plugin). So the ^5.4.21 peer appears to be a stale declared range rather than a real incompatibility.
Request: widen the admin toolchain's Vite range (at minimum to allow >=6.4.2; ideally ^6 || ^7 || ^8 given it already builds on 8) so downstream apps can pick up the security fix without an override. Updating the optimizeDeps.rollupOptions → rolldownOptions call in admin-vite-plugin would also clear the Vite 8 deprecation warning.
Severity note for triage: in production the admin is prebuilt (medusa build) and no Vite dev server runs, so practical exposure of this particular advisory is dev-time — but it still trips Dependabot/OSV/Snyk on every Medusa app.
Another instance — admin toolchain pins vite@^5.4.21 (blocks the only fix for GHSA-4w7w-66w2-5vf9)
Same pattern, the most clear-cut yet because the pin literally caps out below the only available fix:
@medusajs/admin-bundler → dependencies.vite: "^5.4.21"@medusajs/admin-vite-plugin → peerDependencies.vite: "^5.4.21"
^5.4.21 resolves to 5.4.21 (the newest 5.4.x), which is vulnerable to GHSA-4w7w-66w2-5vf9 (Vite path traversal in optimized-deps .map handling, vulnerable range <=6.4.1). There is no 5.x backport — the fix exists only in vite@>=6.4.2 — so the ^5.4.21 cap means apps on the Medusa admin toolchain cannot reach a patched Vite without forcing it past your declared range.
Good news: forcing it works. I overrode vite to ^8.0.16 in a 2.16-preview backend and the admin frontend builds cleanly:
@medusajs/admin-bundler → @medusajs/admin-vite-plugin → vite@8.0.16 (deduped)
...
info: Frontend build completed successfully (8.73s)
Only one non-fatal deprecation surfaced: optimizeDeps.rollupOptions / ssr.optimizeDeps.rollupOptions is deprecated → use optimizeDeps.rolldownOptions (Vite 8 is rolldown-based; the option is set by the admin plugin). So the ^5.4.21 peer appears to be a stale declared range rather than a real incompatibility.
Request: widen the admin toolchain's Vite range (at minimum to allow >=6.4.2; ideally ^6 || ^7 || ^8 given it already builds on 8) so downstream apps can pick up the security fix without an override. Updating the optimizeDeps.rollupOptions → rolldownOptions call in admin-vite-plugin would also clear the Vite 8 deprecation warning.
Severity note for triage: in production the admin is prebuilt (medusa build) and no Vite dev server runs, so practical exposure of this particular advisory is dev-time — but it still trips Dependabot/OSV/Snyk on every Medusa app.
Originally posted by @ianrothfuss in #15625
Another instance — admin toolchain pins
vite@^5.4.21(blocks the only fix for GHSA-4w7w-66w2-5vf9)Same pattern, the most clear-cut yet because the pin literally caps out below the only available fix:
@medusajs/admin-bundler→dependencies.vite: "^5.4.21"@medusajs/admin-vite-plugin→peerDependencies.vite: "^5.4.21"^5.4.21resolves to5.4.21(the newest 5.4.x), which is vulnerable to GHSA-4w7w-66w2-5vf9 (Vite path traversal in optimized-deps.maphandling, vulnerable range<=6.4.1). There is no 5.x backport — the fix exists only invite@>=6.4.2— so the^5.4.21cap means apps on the Medusa admin toolchain cannot reach a patched Vite without forcing it past your declared range.Good news: forcing it works. I overrode
viteto^8.0.16in a 2.16-preview backend and the admin frontend builds cleanly:Only one non-fatal deprecation surfaced:
optimizeDeps.rollupOptions/ssr.optimizeDeps.rollupOptionsis deprecated → useoptimizeDeps.rolldownOptions(Vite 8 is rolldown-based; the option is set by the admin plugin). So the^5.4.21peer appears to be a stale declared range rather than a real incompatibility.Request: widen the admin toolchain's Vite range (at minimum to allow
>=6.4.2; ideally^6 || ^7 || ^8given it already builds on 8) so downstream apps can pick up the security fix without an override. Updating theoptimizeDeps.rollupOptions→rolldownOptionscall inadmin-vite-pluginwould also clear the Vite 8 deprecation warning.Severity note for triage: in production the admin is prebuilt (
medusa build) and no Vite dev server runs, so practical exposure of this particular advisory is dev-time — but it still trips Dependabot/OSV/Snyk on every Medusa app.Originally posted by @ianrothfuss in #15625