Brand new sveltekit project depends on vulnable package - but upgrade not possible

[goldbach]

Describe the bug

Brand new sveltekit project depends on vulnable package (cookie) - but upgrade not possible.

Reproduction

npx sv create foobar
npm audit

Logs

# npm audit report

cookie  <0.7.0
cookie accepts cookie name, path, and domain with out of bounds characters - https://github.com/advisories/GHSA-pxg6-pf52-xh8x
fix available via `npm audit fix --force`
Will install @sveltejs/kit@0.0.30, which is a breaking change
node_modules/cookie
  @sveltejs/kit  >=1.0.0-next.0
  Depends on vulnerable versions of cookie
  node_modules/@sveltejs/kit
    @sveltejs/adapter-auto  >=1.0.0-next.0
    Depends on vulnerable versions of @sveltejs/kit
    node_modules/@sveltejs/adapter-auto

3 low severity vulnerabilities

To address all issues (including breaking changes), run

System Info

System:
    OS: macOS 14.4.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 80.32 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 22.8.0 - ~/.asdf/installs/nodejs/22.8.0/bin/node
    npm: 10.9.0 - ~/.asdf/plugins/nodejs/shims/npm
    pnpm: 8.11.0 - ~/.homebrew/bin/pnpm
  Browsers:
    Chrome: 130.0.6723.70
    Safari: 17.4.1
  npmPackages:
    @sveltejs/adapter-auto: ^3.0.0 => 3.3.1
    @sveltejs/kit: ^2.0.0 => 2.7.3
    @sveltejs/vite-plugin-svelte: ^4.0.0 => 4.0.0
    svelte: ^5.0.0 => 5.1.3
    vite: ^5.0.3 => 5.4.10

Severity

annoyance

Additional Information

No response

[Conduitry]

I'm really confused by the note about installing @sveltejs/kit@0.0.30. That seems bizarre.

The cookie vulnerability is a known issue though. Later versions of cookie brought stricter validation to cookie names, which would be a breaking change, so we can't upgrade until SvelteKit 3. If you don't need that, you can use an override to force a later version.

See also #12768 and #12799.

[memark]

Thanks for the information, I'll try that.

I wonder though if this issue should not be left open, and possibly pinned? Everyone who has some sort of npm audit in their CI will be coming here to try to find a solution.

[philsherry]

@memark Exactly, this should not be closed for that reason.

[keltonhalbert]

Spent the better part of an hour trying to debug this before finding this issue. +1 for pinning it instead of closing it.