@lenne.tech/nest-server 11.43.4 → 11.43.5

package/.claude/rules/package-management.md

@@ -330,6 +330,26 @@ on `FIX AVAILABLE` (a `first_patched_version` now exists) or on a withdrawn advi
 API is reported as `UNVERIFIED` and tolerated locally — but **fails under `CI`**, because a skip
 nobody reads is indistinguishable from a check that ran.
 
+**A fix nobody named is still a fix (11.43.5).** GitHub leaves `first_patched_version` null on some advisories
+after a release outside the vulnerable range shipped: GHSA-86w9-cpqp-85rv (node-forge) read
+`<= 1.4.0` / null a day after 1.4.1 was published. Until 11.43.4 the guard skipped such an advisory,
+so its suppression passed every run. It now reads the package's packument from the registry pnpm
+installs from and, per vulnerable copy in the lockfile, looks for a stable release above it that
+lies outside **every** range the advisory lists. A deprecated release is held back, not ruled out: it
+counts only when every such release is deprecated, because some packages deprecate all of them
+(node-sass: 132 of 132 stable releases), and ruling them out reads a published fix as "no fix" for good.
+
+| Finding | Verdict |
+|---------|---------|
+| every copy has such a release, past `minimumReleaseAge` | `FIX AVAILABLE`, naming it — `unusableFixConsumers` applies as for a named fix |
+| one is published but younger than `minimumReleaseAge` | passes, printed as `pending` with the date the gate clears (pnpm would refuse it, so failing would order a `minimumReleaseAgeExclude` nobody decided on) |
+| some copy has none | passes — the suppression is still justified |
+| no version the lockfile resolves is in the range any more | `NOT IN TREE` — the entry hides nothing |
+| registry or lockfile unreadable | `UNVERIFIED`, with the reason (fails under `CI`) |
+
+`--advisory-file` runs stay offline: they take packuments from `--packument-file` and never ask the
+registry.
+
 One consequence worth knowing before you reach for this mechanism: the guard fires when the advisory
 has a patched version for **any** affected range. For most findings that is the honest outcome — a
 fix exists, take it, and the case is an override problem rather than a suppression problem.
@@ -341,7 +361,7 @@ removed an export its consumer imports, or the consumer pins the vulnerable rang
 `FIX AVAILABLE` is not advice but a dead end, and the only ways out used to be a permanently red
 build or a guard switched off for that entry.
 
-Measured case (lt-crm, 2026-10-06): three `simple-git` advisories, one CRITICAL requiring `>=4.0.1`,
+Measured case (a consuming Nuxt project, 2026-10-06): three `simple-git` advisories, one CRITICAL requiring `>=4.0.1`,
 reachable only via `nuxt > @nuxt/devtools > simple-git`. simple-git 4 dropped the default export
 devtools imports, so the override made `nuxt prepare` fail outright. The newest devtools in the 3.x
 line still imports it that way, and devtools is a hard `dependencies` entry of `nuxt` — so it can be
@@ -372,6 +392,25 @@ any has moved:
    second version of the same consumer is a path nobody assessed, and comparing by name alone let
    one ride along on the other's declaration, with the winner decided by lockfile order.
 
+**"Pulls an affected package" means an affected VERSION (11.43.5).** Checks 3 and the idle check below
+count an edge only when its resolved version lies in one of the advisory's `vulnerable_version_range`s.
+A parent pulling the FIXED release is no consumer of the vulnerability. Until 11.43.5 every parent
+counted, so lifting one subtree to the fixed major (glob 14.0.3 pulling minimatch 11.0.3 next to
+consumers still on minimatch 10) failed a correct declaration for good. An edge whose version cannot be
+read (`link:`, `file:`), or any edge of an advisory that lists no range, still counts: "I could not tell
+which version it pulls" must not read as "it pulls the fixed one" (mutations
+`unusable-fix-counts-fixed-edges`, `unusable-fix-skips-unreadable-edge`). An edge is matched by the package it
+PULLS, not by its key: pnpm keys an npm alias by the alias (`mm-cjs: minimatch@5.1.9`, an importer's
+`version: minimatch@5.1.9`), so a key match missed every consumer behind an alias and read an edge keyed
+`minimatch` that pulls a fork as a minimatch edge (mutation `unusable-fix-matches-alias-by-key`).
+
+**Several consumers (11.43.5)** are joined with ` + `, each at its assessed version —
+`'@nestjs/cli@11.0.24 + rimraf@6.1.3 cannot use 14.0.2'`. One vulnerable package often sits under
+several dev tools at once, and before this a declaration could name only one, so such a finding had no
+honest way in. Every listed consumer gets checks 1 and 3, and one more: a listed consumer that no
+longer pulls an affected package fails too (mutation `unusable-fix-accepts-idle-consumer`), because a
+list is where a path that is gone would otherwise keep covering.
+
 The third check reads **both halves** of the lockfile. `importers:` holds what the repository itself
 declares (`.`, `projects/api`, `projects/app`), `snapshots:` the edges between third-party packages
 — and the first is the likelier production path, because a direct dependency can simply be raised.
@@ -401,12 +440,22 @@ plus one for the opposite failure, a guard that rejects a declaration which is s
 matters just as much: a check that cries wolf on correct entries is a check that gets switched off,
 which is how the hole this feature closes came about in the first place.
 
-**Current entry (since 2026-10-11):** `GHSA-vfj7-8cjw-p6xm` (braces, via nodemon / npm-watch), a
-dev-tooling-only path of an advisory with no patched release at all; the justification sits next to
-the entry in `pnpm-workspace.yaml`. **Do not copy it into nest-server-starter without thinking it
-through:** since lt CLI 1.42.0 the starter's `auditConfig` is hoisted as a union into every
-generated project, so an entry there hides the advisory in every customer workspace — including
-production paths this repository does not have.
+**Current entries on `release/11.x` (since 11.43.5).** `GHSA-gcqx-w48m-w2h4` (deepmerge `<= 4.3.1`, low,
+since 11.43.4): dev tooling only, through @nestjs/cli 11 > fork-ts-checker-webpack-plugin, with no patched
+release at all. `GHSA-g3hv-75wg-m249` (minimatch `< 11.0.1`) and `GHSA-3g3m-2fjr-6pw4` (glob `<= 14.0.1`), both
+moderate, both fixed only in a new major released 2026-10-27 that none of their consumers can take yet — five
+for minimatch (@nestjs/cli 11.0.24 pins fork-ts-checker-webpack-plugin 9.1.0, which needs minimatch ^3), two for
+glob (@nestjs/cli 11.0.24 pins glob 13.0.6 exactly, rimraf 6.1.3 needs ^13); the same two entries as 12.x
+(DEV-3899). The justification is in the comment above `ignoreGhsas`, the declarations in
+`unusableFixConsumers`. `tests/unit/audit-suppression-scope.spec.ts` keeps deepmerge and glob out of the
+production tree and allows minimatch there only under `@ts-morph/common` (ts-morph, the Permissions module's
+scanner, matching globs the developer writes) — its `prodVia` form.
+
+`GHSA-vfj7-8cjw-p6xm` (braces, via nodemon / npm-watch) was listed from 2026-10-11 until 11.43.4: a
+dev-tooling-only path of an advisory with no patched release at all, withdrawn by GitHub on 2026-10-23.
+**Before adding an entry, and before copying one into nest-server-starter:** since lt CLI 1.42.0 the
+starter's `auditConfig` is hoisted as a union into every generated project, so an entry there hides the
+advisory in every customer workspace — including production paths this repository does not have.
 
 **An entry whose package has left the declared range goes, even when the new version is no fix.**
 `GHSA-ch52-4w7c-c8xp` (http-cache-semantics `<= 4.2.0`) was listed from 2026-10-03 to 2026-10-11.

package/.claude/rules/testing.md

@@ -268,7 +268,7 @@ pnpm run check:mutations -- --id=<id>       # one mutation
 pnpm run check:mutations -- --list          # the registry, without running anything
 pnpm run check:mutations -- --allow-dirty   # when the fix and its evidence share a working tree
 pnpm run check:mutations -- --jobs=4        # N mutations at a time (default: 2, or 4 on >=12 cores)
-pnpm run check:mutations -- --no-infra      # only the 166 that need no MongoDB
+pnpm run check:mutations -- --no-infra      # only the 176 that need no MongoDB
 pnpm run check:mutations -- --since=<ref>   # only mutations touching files changed since <ref>
 ```
 
@@ -287,7 +287,7 @@ when the registry, a vitest config or a setup file changed, since those can move
 commit, and in CI alongside the publish without blocking it. The price of caching is a cache that
 has to model each spec's full dependency closure correctly, and getting that wrong produces a stale
 PASS for a test that has since gone vacuous — exactly what the gate is there to prevent. Bad trade
-at 252 mutations.
+at 262 mutations.
 
 **Decided 2026-10-03 (repo owner): keep the full run.** Measured at 128 mutations, the CI job for
 11.41.6 took **14 minutes**. The trigger to revisit is that wall time, not the mutation count —
@@ -334,7 +334,7 @@ exactly the environment where the answer matters.
 
 Worth knowing before optimising the wrong thing: the specs behind all 86 e2e mutations add up to
 **~40 seconds**. The step takes ~740s. The remaining ~700s is paying vitest's startup — process
-spawn, transform, module graph, mongod connect, DB create and drop — once per mutation, 252 times.
+spawn, transform, module graph, mongod connect, DB create and drop — once per mutation, 262 times.
 That work is largely single-threaded I/O and barely scales with cores: the full registry measures
 **744s on a 12-core laptop and 777s on a 4-vCPU CI runner**.
 

package/.claude/rules/versioning.md

@@ -25,6 +25,13 @@
 1. **Document breaking changes** clearly in commit messages when incrementing MINOR version
 2. **Update nest-server-starter** with migration instructions for breaking changes
 3. **Consider downstream impact** - this package is used by multiple projects
+4. **Every published version gets its nest-server-starter version** (repo owner, 2026-11-03). The
+   starter's `version` always equals the `@lenne.tech/nest-server` version it pins. Every version
+   published to npm is followed by the starter commit `Updated to nest-server version <X.Y.Z>`, tagged
+   `v<X.Y.Z>` by the starter's `tag.yml`, also when the bump is the only change. Starter changes
+   between two releases never change its version: the starter follows nest-server, never the other
+   way round. This covers the maintenance line too: a release from `release/11.x` is followed on the
+   starter's `release/11.x` branch.
 
 ## Release Process
 
@@ -36,8 +43,12 @@
    (You can also sync manually any time via `pnpm run spectaql:sync`.)
 3. Build the package (`pnpm run build`) — this also regenerates `FRAMEWORK-API.md` with the new version
 4. Publish to npm
-5. Update and test in [nest-server-starter](https://github.com/lenneTech/nest-server-starter)
-6. Commit changes to starter with migration notes
+5. **Release [nest-server-starter](https://github.com/lenneTech/nest-server-starter) with the same
+   version — a required step, not an optional "update and test".** Raise the framework and the
+   starter's own `version` to the new version (`pnpm run update`, migration guides applied), test, and
+   commit as `Updated to nest-server version <X.Y.Z>`; the starter's `tag.yml` tags it `v<X.Y.Z>` (rule 4).
+6. A release made with `/lt-dev:publish --skip-downstream` leaves a gap in the starter's tag series.
+   Close it before the next nest-server release.
 
 ### Version Consistency Check
 

package/FRAMEWORK-API.md

@@ -1,6 +1,6 @@
 # @lenne.tech/nest-server — Framework API Reference
 
-> Auto-generated from source code as of 2026-10-22 (v11.43.4)
+> Auto-generated from source code as of 2026-10-29 (v11.43.5)
 > File: `FRAMEWORK-API.md` — compact, machine-readable API surface for Claude Code
 
 ## CoreModule.forRoot()

package/docs/security-overrides.md

@@ -74,6 +74,21 @@ overrides:
   '@graphql-tools/utils@>=12.0.0 <12.1.0': '12.1.0'
 ```
 
+### Advisories no override can fix yet: `minimatch` and `glob` (11.43.5)
+
+[GHSA-g3hv-75wg-m249](https://github.com/advisories/GHSA-g3hv-75wg-m249) (minimatch `< 11.0.1`, moderate, DoS
+through globparts amplification) and [GHSA-3g3m-2fjr-6pw4](https://github.com/advisories/GHSA-3g3m-2fjr-6pw4)
+(glob `<= 14.0.1`, moderate) are fixed only in new majors that no consumer can take yet: `@nestjs/cli` 11.0.24, the
+newest 11.x, pins glob 13.0.6 and fork-ts-checker-webpack-plugin 9.1.0 (minimatch ^3) exactly, ts-morph 28
+(`@ts-morph/common` 0.29), nodemon, `@swc/cli` and glob 13 need the 9.x / 10.x lines, rimraf 6.1.3 needs glob 13 — all
+on their newest release. An override across the major is no way out (minimatch 11 removed `makeRe()` and
+`Minimatch#regexp`). nest-server suppresses both in its own repository with `auditConfig.unusableFixConsumers`, which
+`check:overrides` re-tests on every run. What it found for its own tree: the only production path is
+`@lenne.tech/nest-server > ts-morph > @ts-morph/common > minimatch`, used by the Permissions module's scanner with
+globs the developer writes; every other path is dev tooling. Your project's tree may have other paths, so check
+`pnpm why minimatch --prod` and `pnpm why glob --prod` before you suppress the same way, and remove the entries once
+your consumers move to minimatch 11 / glob 14.
+
 ### Retired: `@hono/node-server` (removed 2026-08-22, nest-server 11.36.1)
 
 This list used to carry a third entry. `@modelcontextprotocol/sdk` declared `@hono/node-server@^1.19.9`

package/migration-guides/11.43.4-to-11.43.5.md

@@ -0,0 +1,102 @@
+# Migration Guide: 11.43.4 → 11.43.5
+
+A security patch for projects that still run on 11.x. It is published under the npm dist-tag `latest-11`, not `latest`:
+12.x stays the version a plain install resolves to, and moving every project to 12.x remains the goal. This release
+carries only urgent security fixes; functional fixes from 12.x are not backported.
+
+## Overview
+
+| Category             | Details                                                                                                                                       |
+| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Bugfixes**         | None in the framework code                                                                                                                    |
+| **New Features**     | None                                                                                                                                          |
+| **Framework API**    | Unchanged                                                                                                                                     |
+| **Dependencies**     | `follow-redirects` 1.16.1 → 1.16.2, transitive (§1)                                                                                          |
+| **Breaking Changes** | None                                                                                                                                          |
+| **Migration Effort** | Raise the version, refresh one transitive package (§1); decide on two advisories that have no usable fix yet (§2)                          |
+
+## Quick Migration
+
+```bash
+# npm mode: the version is pinned exactly, and `latest` is 12.x, so name the version
+pnpm add @lenne.tech/nest-server@11.43.5
+pnpm update --depth Infinity follow-redirects
+pnpm audit --prod
+pnpm test
+```
+
+Vendor-mode projects update the core to the tag `11.43.5` with the core updater and refresh `follow-redirects` the same
+way.
+
+## 1. follow-redirects 1.16.2
+
+[GHSA-mrwp-f3q8-3g9p](https://github.com/advisories/GHSA-mrwp-f3q8-3g9p) (high, CVSS 5.9): `sensitiveHeaders` arrays
+from another realm are discarded, so custom credentials can follow a redirect to another host. It covers 1.16.0 and
+1.16.1, patched in 1.16.2.
+
+nest-server reaches it through `node-mailjet > axios > follow-redirects`. axios requests a caret range, so no override is
+needed, but an existing lockfile keeps 1.16.1 until it is refreshed (the command in Quick Migration). Projects that
+reach axios on another path are covered by the same refresh.
+
+## 2. minimatch and glob: fixed only in a new major
+
+[GHSA-g3hv-75wg-m249](https://github.com/advisories/GHSA-g3hv-75wg-m249) (minimatch `< 11.0.1`, moderate, DoS through
+globparts amplification) and [GHSA-3g3m-2fjr-6pw4](https://github.com/advisories/GHSA-3g3m-2fjr-6pw4) (glob `9.0.0` to
+`14.0.1`, moderate, AbortSignal cancellation bypass) were published on 2026-10-30. Both fixes exist only in new majors
+(minimatch 11.0.1, glob 14.0.2), and none of their consumers in the 11.x tree can take them: `@nestjs/cli` 11.0.24, the
+newest 11.x, pins glob 13.0.6 and fork-ts-checker-webpack-plugin 9.1.0 (minimatch ^3) exactly; ts-morph, nodemon,
+`@swc/cli`, glob 13 and rimraf 6 are on their newest releases and request the older majors. An override across the
+major is no way out: minimatch 11 removed `makeRe()` and `Minimatch#regexp`.
+
+`pnpm audit --prod` in a project reports minimatch: ts-morph is a dependency of nest-server (the Permissions module's
+scanner), so the path `@lenne.tech/nest-server > ts-morph > @ts-morph/common > minimatch` reaches every production
+tree. That scanner matches globs the developer writes, never request input. glob is dev tooling in nest-server's own
+tree.
+
+What a project does depends on its audit gate:
+
+- **No blocking `pnpm audit` gate:** nothing to do. Re-check when the consumers move to minimatch 11 / glob 14.
+- **A blocking gate:** check `pnpm why minimatch --prod` and `pnpm why glob --prod` first. Your tree may reach either
+  package on a path that does take request input; then that path is a finding of its own. If every path matches
+  patterns the developer writes, suppress both advisories with the reason next to them. A project that carries
+  `scripts/check-overrides.mjs` (starter-based projects do) declares them in `unusableFixConsumers`, so the guard
+  reports the day a consumer moves:
+
+```yaml
+# pnpm-workspace.yaml of the project — list the consumers YOUR lockfile shows, at their versions
+auditConfig:
+  ignoreGhsas:
+    - GHSA-g3hv-75wg-m249
+    - GHSA-3g3m-2fjr-6pw4
+  unusableFixConsumers:
+    GHSA-g3hv-75wg-m249: '@swc/cli@0.8.1 + @ts-morph/common@0.29.0 + fork-ts-checker-webpack-plugin@9.1.0 + glob@13.0.6 + nodemon@3.1.14 cannot use 11.0.1'
+    GHSA-3g3m-2fjr-6pw4: '@nestjs/cli@11.0.24 + rimraf@6.1.3 cannot use 14.0.2'
+```
+
+nest-server's own repository carries exactly these entries, with the reasoning in `pnpm-workspace.yaml` and a scope
+guard (`tests/unit/audit-suppression-scope.spec.ts`) that fails if glob reaches the production tree or minimatch reaches
+it through any parent other than `@ts-morph/common`.
+
+## 3. `check:overrides`: the guard of 12.x (projects that copied it)
+
+Only relevant for a project that carries a copy of `scripts/check-overrides.mjs`. The guard on `release/11.x` is now the
+one 12.x runs, which the declarations in §2 need:
+
+- `unusableFixConsumers` takes several consumers, joined with ` + `, each at its assessed version. A listed consumer
+  that no longer pulls an affected version fails the run.
+- Only edges to an AFFECTED version count as consumers; a parent that already pulls the fixed release does not. An edge
+  is matched by the package it pulls, not by its key (npm aliases).
+- An advisory that names no patched version is looked up in the registry: a release outside every vulnerable range
+  makes the suppression `FIX AVAILABLE`, a release younger than `minimumReleaseAge` is reported as `pending`.
+
+Copy the file from the tag `11.43.5` to take these over. Nothing changes for a project without the guard.
+
+## Not in this release
+
+Fixes from 12.x that are not urgent security fixes stay there. They arrive with the move to 12:
+`migration-guides/11.43.x-to-12.0.x.md`.
+
+## Module Documentation
+
+- [Security overrides](../docs/security-overrides.md)
+- [Package management rules](../.claude/rules/package-management.md)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.43.4",
+  "version": "11.43.5",
   "description": "Modern, fast, powerful Node.js web framework in TypeScript based on Nest with a GraphQL API and a connection to MongoDB (or other databases).",
   "keywords": [
     "node",