Hardcoded dep version make it hard to patch vulnerabilities

3rd party dependencies like

$ bun audit

nanoid  >=4.0.0 <5.1.16
  workflow › @workflow/nitro › @workflow/builders › @workflow/core › nanoid
  high: nanoid: non-secure generators can loop indefinitely with negative size - https://github.com/advisories/GHSA-28wg-ghj8-5hjv
  high: nanoid: custom generators can loop indefinitely when size is zero - https://github.com/advisories/GHSA-2v37-7h3g-55p8

undici  >=7.0.0 <7.29.0
  workflow › @workflow/core › @workflow/world-vercel › undici
  moderate: undici vulnerable to downstream response desynchronization via retry interceptor - https://github.com/advisories/GHSA-8xcm-r25x-g524
  high: undici vulnerable to cross-user information disclosure and parse-time crash via degenerate private cache directives - https://github.com/advisories/GHSA-4cwx-7wf7-3272
  moderate: undici vulnerable to CRLF Injection via blob-like body 'type' property - https://github.com/advisories/GHSA-m8rv-5g2x-5cg5
  moderate: undici vulnerable to cross-user information disclosure via whitespace around equals in Cache-Control directives - https://github.com/advisories/GHSA-jr45-8vmc-qm54
  moderate: undici vulnerable to cookie attribute injection via unsanitized domain and unparsed setCookie fields - https://github.com/advisories/GHSA-v3r7-h72x-cjcm

come with vulnerabilities that cannot be easily patched by upgrading workflow (since the version is fixed!), we need to manually add overrides to the package.json. This is not a scalable solution since we may have multiple versions of the same package and we only need to upgrade one.

Is there any plan to patch these and keep track of the potential vulnerabilities that workflow ships with?

[core] Bump nanoid to 5.1.16 on stable (GHSA-28wg-ghj8-5hjv)

[core] Bump nanoid to 5.1.16 (GHSA-28wg-ghj8-5hjv)

(AI)

Severity: S3. Every workflow install gets a high-severity npm audit/bun audit finding, and apps can only clear it with overrides. We don't believe Workflow's own use is exploitable: nanoid is only called with a fixed size of 21, and undici is only used for the SDK's own outbound requests. The findings are still real for anyone who has to pass an audit. Fresh installs today:

workflow@latest (4.8.9): nanoid@5.1.6 (GHSA-28wg-ghj8-5hjv) and undici@7.28.0 (GHSA-4cwx-7wf7-3272 and 4 moderate). 16 findings in total.
workflow@beta (5.0.0-beta.55): nanoid@5.1.6 only; undici is already 7.29.0.

Reproduction: npm init -y && npm i workflow@latest && npm audit --omit=dev reproduces the report above.

One caveat on the nanoid override: nanoid only feeds the seeded generator for default createHook() tokens, and nanoid@5.1.16 draws a different number of random bytes per id. With the override, a run that started before the change and is replayed after it gets different hook tokens and a shifted Math.random() sequence, which can cause replay divergence. That mostly matters on Local and Postgres Worlds, where in-flight runs pick up new code on restart. The undici override is safe.

Related:

Package has many high severity depencies #2284: same class of report (devalue/undici), fixed then by bumping the pins.
chore(deps): upgrade nanoid to ^5.1.16 #3545: community PR that bumps nanoid to ^5.1.16. It has the replay problem described above.
[deps] Dedupe zod and undici by publishing caret ranges #3498: parked PR that switches undici/zod to caret ranges, i.e. the "don't pin exactly" direction this issue asks about.
chore(deps): upgrade undici to 7.29.0 #3315: bumped undici to 7.29.0 on main but was never backported to 4.x, because the backport check treated it as a routine bump.

Fix PRs:

[core] Fix vulnerable nanoid pin by dropping the dependency #4335 (main): removes the nanoid dependency from @workflow/core. It inlines nanoid 5.1.6's exact algorithm for the seeded generator, with a golden test, so hook tokens stay identical across versions.
[core] Fix vulnerable nanoid pin on stable by dropping the dependency #4336 (stable/4.x): the same change, plus the undici 7.29.0 backport.

Installing either PR's pre-release gives found 0 vulnerabilities. The remaining CI failures on both PRs are flaky e2e/timing jobs that fail the same way on other PRs. Whether to move to caret ranges or add an audit gate to CI is still a maintainer decision.

To see if this fix solves your issue, could you try to install the pre-release in your package.json? Just replace the workflow dep like so (4.x / latest line):

{
  "dependencies": {
    "workflow": "https://workflow-tarballs-git-triage-workflow3842-undici-stable.labs.vercel.dev/workflow.tgz",
    "@workflow/ai": "https://workflow-tarballs-git-triage-workflow3842-undici-stable.labs.vercel.dev/workflow-ai.tgz",
  }
}

For the 5.0 beta line, use https://workflow-tarballs-git-triage-workflow3842-hardcoded-dep-version.labs.vercel.dev/ as the base URL instead.

[core] Drop nanoid; freeze the seeded hook-token generator

Would it be possible to allow at least patch (if not minor) versions for workflow's dependencies in general? Having the fixed versions in the package.json severely limits consumers' ability to maintain a vulnerability free security report, even when there's no realistic attack vector. Overriding all the time the version in our package.json is not a good idea since it can affect other 3rd party libraries

To back-up my previous comment, here's another package that now it's reported as vulnerable

devalue@5.9.2
  workflow › @workflow/nitro › @workflow/builders › @workflow/core › devalue
  high: devalue: `stringify`/`uneval` serialize shared memory (>=5.1.0 <=5.9.2) - https://github.com/advisories/GHSA-j22f-vq7h-c4qm
  moderate: devalue: Residual sparse-array CPU amplification in uneval (<=5.9.2) - https://github.com/advisories/GHSA-hx4r-w6wj-j8fg
  high: devalue: Repeated primitive strings cause quadratic expansion in uneval (<=5.9.2) - https://github.com/advisories/GHSA-mcm9-63f2-9j32
  low: devalue: Sparse arrays emitted by uneval cause eager allocation when evaluated (>=1.0.0 <=5.9.2) - https://github.com/advisories/GHSA-wf3x-273g-mvxv
  high: devalue: stringifyAsync can cause an unhandled rejection despite a caught returned promise (>=5.8.0 <=5.9.2) - https://github.com/advisories/GHSA-x5rw-q4pp-hg5g
  moderate: devalue: Malformed null-prototype object keys bypass __proto__ rejection via property-key coercion (<=5.9.2) - https://github.com/advisories/GHSA-4q55-j62x-fr9h

[core] Fix vulnerable nanoid pin by dropping the dependency (#4335)

[core] Fix vulnerable nanoid pin on stable by dropping the dependency (…

[core] Fix vulnerable nanoid pin by dropping the dependency (#4335)

Navigation Menu

Repository navigation

Hardcoded dep version make it hard to patch vulnerabilities #3842

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Hardcoded dep version make it hard to patch vulnerabilities #3842

Description

Activity

pranaygp commented on Sep 23, 2026

octavian-mto commented on Oct 2, 2026

octavian-mto commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions