[polylane]

The CMS resolved known high-severity vulnerable versions of several dependencies, including its GraphQL library, email sender, HTTP client and build tooling, and Dependabot flagged seven high alerts. After this change those packages resolve to patched versions and the alerts clear, while one nested validation library stays on its current major because the session package that uses it has no compatible release.

flowchart TD
  A["Upstream manifests pin exact transitive versions"] --> B["npm resolves vulnerable versions into package-lock.json"]
  B --> C["Dependabot and Trivy high advisories"]
  D["package.json overrides (this fix)"] -.->|re-resolve| B
  C --> E["Patched: undici 8.12.2, nodemailer 10.1.4, webpack-dev-middleware 7.4.6, graphql-tools utils 12.0.2, zod 4.6.7"]
  C --> F["Residual: zod 3.25.76 under koa-body / koa-session"]

Loading

flowchart LR
  A["PR head e287f0d"] --> B["package.json overrides"]
  A --> C["engines.node >=22.19.0"]
  B --> D["package-lock.json re-resolved"]
  D --> E["GraphQL, Apollo, session, mailer, dev-middleware: load and execute OK"]
  C --> F["Strapi Cloud Node: dashboard setting, not engines"]
  G["No deploy edges / no cloud account"] -.->|unknown| H["deployed resource node"]
  E --> I["pass: no production path regresses"]
  F --> I

Loading

Detection evidence

Affected: int_17ad4b457001o98datdn4tkm

Why this fix

The lockfile held exact vulnerable versions because the Strapi SDK declares them exactly, so a plain install could not move them. Overrides re-resolve each package to its lowest patched version, which clears every high Dependabot alert. I confirmed the changed modules load and that GraphQL schema building, Apollo query execution, nodemailer and the dev server work with the new versions. The remaining risk is zod under the koa session and body middleware: koa-session only accepts zod v3, so moving it to v4 crashes the build. That needs an upstream fix and is recorded on the issue.

Fix walkthrough

Watch the fix explained (1:15). Recorded for commit e287f0d57e5b5c7efa93c42e75fc8d81264057a4.

Out of scope

• Medium and low advisories (qs, uuid, react-router, stream-json, @apollo/server, deepmerge): outside this issue's high-advisory scope.
• zod 3.25.76 under koa-body/koa-session: cannot be patched without crashing koa-session at load; tracked as a follow-up on the issue timeline.

Production impact: Dependency overrides and the Node floor keep the CMS runtime working

I checked the repository node at head e287f0d. It has no deploy edges and no cloud account is connected, so no deployed resource node exists in this workspace to regress, and the live traffic read returned empty. The change only re-resolves transitive versions in package.json and package-lock.json and raises the declared Node floor. I loaded every changed subtree in the working tree, and the GraphQL schema build, Apollo query execution, session middleware, mailer and dev-middleware all still work. The head adds engines.node >=22.19.0; the base already shipped @strapi/core's undici 8.12.1 declaring the same floor, and Strapi Cloud reads the Node version from the project dashboard rather than engines, so the floor does not change the runtime.

Checked and not affected: provider#code#account#datum-cloud#region#earth#type#code.repository#id#datum-cloud/datum.net-cms.

Observability

• Dependabot alerts on datum-cloud/datum.net-cms (existing): the seven high alerts should close once the lockfile reaches the default branch.
• npm audit (existing): high-severity entries drop from 33 to the ten that all trace to the single zod-v3 leaf under koa-body/koa-session.
• Strapi Cloud build logs (external, not connected here): would show an engines/dashboard Node mismatch, which keeps the current deployment live rather than degrading it.

Polylane assessed this pull request at e287f0d.

Causal chain

• Signal (alert): High-severity npm advisories in datum-cloud/datum.net-cms (Trivy DB 2026-10-27 + Dependabot)
• Surfacing site: datum-cloud/datum.net-cms at package-lock.json (resolved npm dependency tree)
• Mechanism: Upstream @strapi/* packages and @apollo/server pin exact/narrow transitive versions, so npm resolved vulnerable versions (undici 8.12.1, zod 4.4.3, @graphql-tools/utils 10.11.0 & 9.2.1, nodemailer 9.0.1, webpack-dev-middleware 6.1.3) into package-lock.json, which Dependabot and Trivy flag as high.
• Producer: Upstream npm dependency manifests (@strapi/*, @apollo/server), external to every connected repository and provider
• Blast radius: unknown other resource(s), unknown other tenant(s); data at risk: none named
• Producer evidence:
  • @strapi/core pins undici 8.12.1 and zod 4.4.3 exactly; @strapi/provider-email-sendmail pins nodemailer 9.0.1; @strapi/strapi pins webpack-dev-middleware 6.1.3 (package-lock.json).
  • npm audit on the HEAD lockfile: 33 high, 7 moderate, 2 low.

2 files changed (+545/-146)

• package-lock.json: modified, +531/-145
• package.json: modified, +14/-1

---

Generated by Polylane. You can ask follow-ups by mentioning @polylane in a comment.

[polylane]

@felixwidjaja Verdict: pass. No production path regresses from this pull request, so the production impact check is green for head e287f0d.

Details:

The deciding evidence is that no deployed resource node exists for this repository, and every changed module was verified to still load and run. The change reaches only package.json and package-lock.json, which re-resolve transitive dependency versions; nothing in a served path changes its behavior.

What I checked at this head:

• Repository node datum-cloud/datum.net-cms has zero deploy edges, and no cloud account is connected, so there is no deployed resource to regress and no live traffic series to read (the read is empty, not zero).
• GraphQL API (enabled at /graphql) uses only pruneSchema from @graphql-tools/utils. I confirmed v12.0.2 exports it and pruning works, and @apollo/server.executeOperation returns data.
• Session middleware: @strapi/core loads; koa-session/koa-body keep zod v3 (the override scopes zod v4 to @strapi/*), so no load crash.
• Mailer: nodemailer 10 loads and the sendmail provider loads. The email plugin is not enabled in config/plugins.js, so it is not on a live path.
• Build tooling: webpack-dev-middleware 7 loads; it is a dev dependency.
• Lockfile sync: npm ci --dry-run exits 0, so the Strapi Cloud build resolves cleanly. npm run lint passes (0 errors).

What changed since my last assessment: the head added commit e287f0d, which raises engines.node from >=20.0.0 to >=22.19.0 in package.json and package-lock.json. This does not change the runtime. The base branch already shipped @strapi/core's undici 8.12.1, which declares the same floor, and Strapi Cloud takes the Node version from the project dashboard rather than engines; .npmrc sets legacy-peer-deps without engine-strict. A dashboard/engines mismatch fails the build but keeps the current deployment live, so even that case does not degrade production.

Not run: npm run build. It stops on a @swc/core native binding load failure in the sandbox (Node 20.20.2). @swc/core is version 1.16.20 on both base and head and is absent from the diff, so this is an environment limitation, not a tree change.

[ecv]

Approve.

package.json and package-lock.json agree on every dependency, and the lock resolves the advisory packages to the patched versions the PR names. Several resolve across major versions, and the repo has no CI that builds or tests them.

• Majors moved: nodemailer 9.0.1 to 10.1.4, webpack-dev-middleware 6.1.3 to 7.4.6, and the @graphql-tools/utils override collapses @apollo/server's nested 9.2.1 and the top-level 10.11.0 into 12.0.2. Upstream manifests did not declare these ranges, so none is covered by a compatibility promise. The PR says GraphQL, Apollo, session, mailer and dev-middleware load and run.
• engines.node goes from >=20.0.0 to >=22.19.0. Strapi Cloud reads the Node version from its dashboard, not engines, so confirm that setting is 22.19 or newer before merge or the deploy build breaks.
• koa-body and koa-session stay on nested zod@3.25.76, as the PR states.

Follow-ups:

• Add a CI job that runs npm ci and a Strapi build, so an advisory fix like this has a check at its head.
• Send a test email and open an admin edit page after deploy, since the mailer and dev-middleware majors have no test coverage.

[polylane]

@ecv I can help with this once you have access to the Datum workspace. Already have a Polylane account? Link your GitHub account and I'll pick this up.

[ecv]

Superseded by #35.