@lenne.tech/nest-server 11.43.4 → 11.43.6

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/migration-guides/11.43.5-to-11.43.6.md

@@ -0,0 +1,53 @@
+# Migration Guide: 11.43.5 → 11.43.6
+
+## Overview
+
+| Category             | Details                                                                                                 |
+| -------------------- | ------------------------------------------------------------------------------------------------------- |
+| **New Features**     | Optional Reply-To for outgoing mail: `email.defaultReplyTo` and a per-call `replyTo` (§1)               |
+| **Breaking Changes** | None                                                                                                    |
+| **Migration Effort** | None. Set `email.defaultReplyTo` only if answers to your mail should go to another address (§1)         |
+
+## Quick Migration
+
+```bash
+pnpm add @lenne.tech/nest-server@11.43.6
+pnpm run update   # nest-server-starter based projects
+```
+
+Vendor-mode projects update the core to the tag `11.43.6`: `/lt-dev:backend:update-nest-server-core --target 11.43.6`.
+Without `--target` the updater syncs to the latest tag, which is on the 12.x line.
+
+## 1. Reply-To for outgoing mail
+
+`EmailService.sendMail()` can set a `Reply-To` header, so a recipient's answer goes to another address than the
+sender, e.g. a shared support mailbox while mail goes out from `noreply@…`. Nothing changes until you set it.
+
+```typescript
+// config.env.ts
+email: {
+  defaultSender: { email: 'noreply@example.com', name: 'Example' },
+  defaultReplyTo: 'support@example.com', // or '"Example Support" <support@example.com>'
+},
+```
+
+As an environment variable:
+
+```bash
+NSC__EMAIL__DEFAULT_REPLY_TO=support@example.com
+```
+
+A call can override it, or send one mail without it:
+
+```typescript
+await this.emailService.sendMail(to, subject, { replyTo: 'sales@example.com', htmlTemplate, templateData });
+await this.emailService.sendMail(to, subject, { replyTo: false, htmlTemplate, templateData });
+```
+
+The default applies to every mail the service sends over SMTP, Better-Auth's verification and password-reset mail
+included. Mail sent through Brevo (`brevo.apiKey`) or Mailjet is not affected: their templates carry their own
+reply-to. A value that is not a string is ignored with one warning rather than stopping the mail.
+
+## Module Documentation
+
+- Configuration reference: `email.defaultReplyTo` in `FRAMEWORK-API.md` (`IServerOptions.email`)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.43.4",
+  "version": "11.43.6",
   "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",

package/src/core/common/interfaces/server-options.interface.ts

@@ -2510,6 +2510,17 @@ export interface IServerOptions {
    * SMTP and template configuration for sending emails
    */
   email?: {
+    /**
+     * Default Reply-To of every mail `EmailService.sendMail()` sends (11.43.6+): where a recipient's answer goes when it
+     * should not reach the sender address, e.g. a shared support mailbox. An address, or `"Name" <address>`.
+     *
+     * Absent (the default) → no Reply-To header, exactly as before. A call overrides it with `replyTo`, and
+     * `replyTo: false` sends that one mail without it. Set it through `NSC__EMAIL__DEFAULT_REPLY_TO`. Applies to the
+     * SMTP path (nodemailer, `email.smtp`): Brevo and Mailjet templates carry their own reply-to.
+     * @default undefined
+     */
+    defaultReplyTo?: string;
+
     /**
      * Data for default sender
      */

package/src/core/common/services/email.service.ts

@@ -28,6 +28,9 @@ export class EmailService implements OnModuleDestroy {
   /** Once-per-process latch for the SMTP TLS warning — a per-send warning would be noise. */
   private smtpTlsWarningEmitted = false;
 
+  /** Once-per-process latch for a Reply-To that is not a string. */
+  private replyToWarningEmitted = false;
+
   /**
    * Inject services
    */
@@ -76,6 +79,31 @@ export class EmailService implements OnModuleDestroy {
     );
   }
 
+  /**
+   * The Reply-To of one mail (11.43.6+): the call's `replyTo`, else `email.defaultReplyTo`, else none. `false` (or an
+   * empty string) sends this mail without one. A value that is not a string is dropped with a warning instead of
+   * failing the mail: a misconfigured default must not stop password-reset or verification mail.
+   */
+  protected resolveReplyTo(replyTo: false | string | undefined): string | undefined {
+    if (replyTo === false) {
+      return undefined;
+    }
+    const value: unknown = replyTo ?? this.configService.getFastButReadOnly('email.defaultReplyTo');
+    if (value === undefined || value === null) {
+      return undefined;
+    }
+    if (typeof value === 'string') {
+      return value.trim() || undefined;
+    }
+    if (!this.replyToWarningEmitted) {
+      this.replyToWarningEmitted = true;
+      this.emailServiceLogger.warn(
+        `Reply-To ignored: expected an address string (email.defaultReplyTo / replyTo), got ${typeof value}.`,
+      );
+    }
+    return undefined;
+  }
+
   onModuleDestroy(): void {
     if (this.cachedTransporter) {
       this.cachedTransporter.close();
@@ -94,6 +122,8 @@ export class EmailService implements OnModuleDestroy {
       attachments?: Attachment[];
       html?: string;
       htmlTemplate?: string;
+      /** Reply-To of this mail; overrides `email.defaultReplyTo`, `false` sends it without one (11.43.6+) */
+      replyTo?: false | string;
       senderEmail?: string;
       senderName?: string;
       smtp?: MailTransportOptions;
@@ -189,11 +219,13 @@ export class EmailService implements OnModuleDestroy {
       this.cachedSmtpConfig = smtpKey;
     }
 
-    // Send mail
+    // Send mail; without a Reply-To the header is left out entirely
+    const replyTo = this.resolveReplyTo(config.replyTo);
     return this.cachedTransporter.sendMail({
       attachments,
       from: `"${senderName}" <${senderEmail}>`,
       html,
+      ...(replyTo ? { replyTo } : {}),
       subject,
       text,
       to: recipients,