@shopify/[email protected] pulls vulnerable lodash chain via @graphql-codegen/[email protected] (Dependabot PR #87 already exists) #98

Summary

@shopify/[email protected] exact-pins @graphql-codegen/[email protected], which transitively pulls @graphql-codegen/[email protected], which depends on lodash@~4.17.0. Newer versions of plugin-helpers (6.2.1+, released 2026-04-04) drop the lodash dependency entirely. Bumping @graphql-codegen/cli to a current 6.x or 7.x release transitively resolves all 13 lodash-chain advisories that consuming projects see in npm audit.

PR #87 (Bump @graphql-codegen/cli from 5.0.6 to 6.1.1) has been open since 2026-01-12 and would fix this. It just needs review and merge.

Reproduction

In any project that depends on @shopify/[email protected] (e.g. a Shopify Function extension generated via shopify app generate extension):

npm install
npm audit

Output (captured 2026-05-08):

13 high severity vulnerabilities

npm ls lodash confirms the chain:

└─┬ @shopify/[email protected]
  └─┬ @graphql-codegen/[email protected]
    ├─┬ @graphql-codegen/[email protected]
    │ └── [email protected]
    ├─┬ @graphql-tools/[email protected]
    │ └── [email protected] deduped
    └─┬ [email protected]
      └── [email protected] deduped

npm audit flags both GHSA-r5fr-rjxr-66jc (CVSS 8.1, code injection via _.template) and GHSA-f23m-r3pf-42rh (CVSS 6.5, prototype pollution in _.unset / _.omit). All 13 advisories report fixAvailable: false because @shopify/[email protected] is the latest published version and exact-pins the codegen versions, so consuming npm install cannot bump the chain on its own.

Why this is awkward to work around downstream

Consumers can apply an npm overrides block to force lodash: "^4.18.1", which we did in our project. But every consuming Shopify Function project has to repeat the workaround. And each Dependabot scan still re-flags the chain because the override is invisible to the advisory database walker.

Proposed fix

Merge PR #87 (Bump @graphql-codegen/cli from 5.0.6 to 6.1.1), or open a fresh PR bumping @graphql-codegen/cli to ^7.0.0.

Why this works:

• @graphql-codegen/[email protected] declares @graphql-codegen/plugin-helpers: "^6.1.0". Caret resolution floats to the latest 6.x, currently 6.3.0, which dropped the lodash dependency.
• @graphql-codegen/[email protected] declares @graphql-codegen/plugin-helpers: "^7.0.0", also lodash-free.

Either path fully clears the 13 lodash-chain advisories without further dependency edits.

Severity (honest)

The deployed Wasm function does not include lodash or any @graphql-codegen/* package, so this is not a runtime exploit. The risk is dev-time only: developer machines and CI runners load the vulnerable lodash code when running npx graphql-codegen or shopify app function typegen. The actual exploit primitives in both advisories (_.template injection, _.unset / _.omit prototype pollution) are not reached by [email protected], which calls lodash/merge.js only. So the realistic risk is "noise in npm audit output and Dependabot triage burden across every consuming project," not "active CVE in production."

Filing this anyway because:

1. The fix is one Dependabot PR merge. Mechanical, low risk.
2. A 4-month-old open Dependabot PR (Bump @graphql-codegen/cli from 5.0.6 to 6.1.1 #87) shouldn't be the bottleneck.
3. Every consuming extension currently has to apply the same overrides workaround.

Versions

• @shopify/[email protected] (latest, published 2026-01-30)
• npm 10.x
• Reproduced on macOS 14.x, Node.js 22.x

Related

• Issue This package depends on a vulnerable version @graphql-codegen/cli #23 (closed 2025-01-31): same package, different transitive vuln (ws chain). Maintainer fixed it in 1.0.4 within 2 days. Citing here to confirm the issue template / response loop works.
• Open PRs already addressing this: Bump @graphql-codegen/cli from 5.0.6 to 6.1.1 #87 (cli), Bump @graphql-codegen/typescript from 4.1.6 to 5.0.7 #86 (typescript), Bump @graphql-codegen/typescript-operations from 4.6.1 to 5.0.7 #85 (typescript-operations).