@lenne.tech/nest-server 11.35.0 → 11.36.0

package/migration-guides/11.34.x-to-11.35.x.md

@@ -49,11 +49,12 @@ Then run the one-time audit in §3.
 them is half-wired if you take one side and not the other, and a half-wired enforcement layer is worse
 than none because it reads as protection.
 
-**Seven new files:**
+**Nine new files** (eight rows — the two file-module files ship as one pair):
 
 | File | Belongs with |
 |------|--------------|
 | `common/plugins/mongoose-system-role.plugin.ts` | `common/enums/role.enum.ts` — the plugin is the unconditional layer, the enum holds the predicates (§1) |
+| `modules/tenant/core-role-scope.registry.ts` | `modules/tenant/core-tenant.helpers.ts` + `modules/tenant/core-tenant.module.ts` + `common/enums/role.enum.ts` — the registry holds the global-vs-tenant split the guards resolve against, `core-tenant.helpers.ts` feeds it from configuration, and `core-tenant.module.ts` is where `forRoot()` registers that source and runs `assertRoleVocabularyIsCoherent()`. Without the module wiring the registry stays empty, every role resolves to `RoleScope.UNKNOWN`, and the boot check that refuses an incoherent vocabulary never runs (§5) |
 | `common/decorators/nested-type.registry.ts` | `decorators/restricted.decorator.ts` + `decorators/unified-field.decorator.ts` — the registry is written by one and read by the other (§8) |
 | `common/decorators/restrictions-checked.marker.ts` | `decorators/restricted.decorator.ts` + both interceptors — all four read the marker; an old truthy check anywhere reopens the bypass (§13) |
 | `common/helpers/graphql-ws-context.helper.ts` | `common/services/core-tenant-context.registry.ts` + `core.module.ts` + `modules/tenant/core-tenant.guard.ts` — the context is useless without the resolver, and unreached without the `core.module.ts` wiring (§7) |
@@ -66,8 +67,21 @@ than none because it reads as protection.
 `common/plugins/mongoose-tenant.plugin.ts`, `common/services/core-s3.service.ts`,
 `modules/file/{core-file.service,file-metadata.helper,file-roles.helper}.ts`,
 `modules/tus/{core-tus.service,tus.constants,index}.ts`, `modules/user/inputs/core-user.input.ts`,
-`modules/user/core-user.service.ts`, `modules/tenant/core-tenant.helpers.ts`, and the three module
-READMEs (`file`, `tenant`, `tus`) plus `modules/file/INTEGRATION-CHECKLIST.md`.
+`modules/user/core-user.service.ts`,
+`modules/tenant/{core-tenant.helpers,core-tenant.module,core-tenant.service}.ts`, and the three
+module READMEs (`file`, `tenant`, `tus`) plus `modules/file/INTEGRATION-CHECKLIST.md`.
+
+`core-tenant.module.ts` and `core-tenant.service.ts` are easy to miss and both carry enforcement:
+`forRoot()` registers the role-scope source and asserts the vocabulary is coherent, and
+`core-tenant.service.ts` gains `assertAssignableMembershipRole()`, which refuses a membership role
+named after a system (`s_*`) or global-only role at assignment time (§5).
+
+The remaining changed files — `common/enums/role.enum.ts`,
+`common/decorators/{restricted,unified-field}.decorator.ts`, both interceptors
+(`check-security`, `response-model`), and all three guards
+(`modules/auth/guards/roles.guard.ts`, `modules/better-auth/better-auth-roles.guard.ts`,
+`modules/tenant/core-tenant.guard.ts`) — are the counterparts already named in the "Belongs with"
+column above. Take them with the new file they pair with.
 
 **Also worth taking:** `src/test/test.helper.ts` (subscription `connectionParams`, and a refused
 subscription now rejects instead of delivering an indistinguishable `null` — without it you cannot test

package/migration-guides/11.35.0-to-11.35.1.md

@@ -0,0 +1,152 @@
+# Migration Guide: 11.35.0 → 11.35.1
+
+## Overview
+
+| Category | Details |
+|----------|---------|
+| **Breaking Changes** | None in signatures. One **client-visible** change: a refused upload now answers **400** instead of **500**, with Nest's standard error envelope instead of an internal-error one (§1) |
+| **Bugfixes** | `multerFileFilter` rejections finally map to a 4xx (§1). Seven documented helper names are reachable from the package root for the first time (§2). The file-access boot warning can no longer be fooled by a subclassed controller (§3) |
+| **Migration Effort** | Nothing to configure. Read §1 if a frontend, a test, or an alerting rule branches on the status or body of a rejected upload. **Read §3 if you subclass `CoreFileController` / `CoreFileResolver` and re-declare a member** — you may see a new warning at startup, and it is probably telling you something true |
+
+---
+
+## Quick Migration
+
+```bash
+pnpm update @lenne.tech/nest-server@11.35.1
+pnpm run build
+pnpm test
+```
+
+No configuration change is required, and no source change is required in a typical project.
+
+**Vendor-mode projects:** §1 and §2 are single-file and independent —
+`src/core/common/helpers/file.helper.ts` and `src/index.ts`. §3 is **not**: it adds
+`src/core/modules/file/core-file-access-audit.initializer.ts` and changes
+`file-roles.config.ts`, `file-roles.helper.ts` and `core.module.ts` together. Taking the initializer
+without the `core.module.ts` provider registration gives you a file that is never constructed — a
+security check that silently does not run, which is worse than not having it. Sync those four
+together.
+
+---
+
+## 1. A refused upload answers 400, not 500
+
+11.32.4 §8 changed `multerFileFilter`'s rejection from a bare string to `new Error(...)`, intending a
+clean 400. It never produced one.
+
+`transformException` in `@nestjs/platform-express` returns any **non-`HttpException`** unchanged. Its
+switch matches only multer's own message constants (`LIMIT_FILE_SIZE`, `LIMIT_UNEXPECTED_FILE`, …),
+and a message this helper writes matches none of them — so the rejection fell off the end of the
+switch, reached Nest's exception layer as a plain error, and the client was told the **server** had
+failed for a file the **client** sent wrong.
+
+Both rejection paths are affected and both are fixed: the allow-list refusal, and the
+scriptable-type refusal (`text/html`, `image/svg+xml`) added by 11.32.4 §6.
+
+| | Before | After |
+|---|---|---|
+| Status | `500 Internal Server Error` | `400 Bad Request` |
+| Body | internal-error envelope | Nest's standard 400 shape |
+| Message text | unchanged | unchanged — same text, still built from the accept list |
+
+**What to check:**
+
+- **Frontends** that branch on the status of an upload response. A rejected file was previously
+  indistinguishable from a storage outage; it now identifies itself, and the message is worth showing
+  to the user.
+- **Tests** pinned to the broken output. A test asserting `500` on a refused upload fails and should
+  be updated to `400`.
+- **Alerting.** Refused uploads no longer raise 5xx. If a dashboard counted them, its numbers drop —
+  that is the fix, not a regression. Conversely, an alert that was tuned to tolerate that noise can
+  be tightened again.
+
+A consumer catching the rejection in code is unaffected: `BadRequestException extends HttpException
+extends Error`, so an `instanceof Error` check keeps working.
+
+---
+
+## 2. Seven documented helpers are now exported from the package root
+
+The 11.34.x → 11.35.x guide's *New Exports* block lists names that `src/index.ts` never exported, so
+importing them from `@lenne.tech/nest-server` failed to compile:
+
+| Name | Module |
+|---|---|
+| `resolveGuardRequest` | `common/helpers/execution-context-request.helper` |
+| `buildRequestContextAwareExecute` | `common/helpers/graphql-ws-context.helper` |
+| `buildRequestContextAwareSubscribe` | same |
+| `createRequestContextAwareExecute` | same |
+| `createRequestContextAwareSubscribe` | same |
+| `getTenantContextResolver` | `common/services/core-tenant-context.registry` |
+| `setTenantContextResolver` | same |
+
+Purely additive — three `export * from` lines. Nothing was renamed or removed, and no existing import
+changes meaning.
+
+**Who this affected:** npm-mode consumers only, and only those who followed the guide. In-tree and
+vendor-mode consumers import over relative paths and never touched the barrel, which is also why
+nothing in this repo noticed: no framework module, test or e2e spec imports from `src/index.ts`, so a
+helper could be written, wired, documented and shipped with the full suite green.
+`tests/unit/public-api-barrel.spec.ts` now reads the expected names out of the migration guides
+themselves and walks the re-export graph, so a documented-but-unexported name fails at test time
+rather than at a consumer's `import`.
+
+---
+
+## 3. The file-access warning now sees a subclassed controller
+
+The boot warning that reports "the file gate is open and nothing declares a per-file policy" read
+**configuration** — `file.downloadRoles` and friends. That is the correct source for a member you
+inherit, and the wrong one for a member you re-declare.
+
+```typescript
+@Controller('files')
+export class FileController extends CoreFileController {
+  @Get('id/:id')
+  @Roles(RoleEnum.S_EVERYONE)      // anonymous downloads
+  override async getFileById(...) { return super.getFileById(...); }
+}
+```
+
+`applyFileRoles()` writes the configured roles onto `CoreFileController.prototype.getFileById`, but
+decorator metadata lives on the **function object** — your override is a different function, it keeps
+its own `@Roles()`, and that is the function Nest registers. The configuration never reaches the
+route. The old warning asked `resolveRoles('downloadRoles', config)`, got `[ADMIN]`, and stayed quiet
+while the route served everyone. Two consumer projects shipped exactly that.
+
+`CoreFileAccessAuditInitializer` now reads the roles off the class you actually registered, at
+`onApplicationBootstrap` (the earliest point at which the route table exists), and names the member:
+
+```
+A registered file endpoint is open beyond platform admins through roles declared in your own class,
+not through configuration (FileController.getFileById → ["s_everyone"]), and no per-file policy is
+declared: file.access is unset and CoreFileService.checkRights() is not overridden. …
+```
+
+**Nothing changes about who may reach what.** Your `@Roles()` still wins; the audit reports and does
+not correct. That is deliberate: rewriting an override's metadata would silently relax a route a
+project pinned on purpose — which is why the TUS module's approach, where configuration wins over the
+override, was not adopted here.
+
+**What to do if the warning appears:**
+
+| If the open access is | Then |
+|---|---|
+| intended, with a per-file rule | declare it: `file.access: 'owner' \| 'tenant' \| …`, or override `CoreFileService.checkRights()`. Either silences the warning, for both halves of the check |
+| intended, genuinely public files | nothing is broken — but the warning is the reminder that ids are enumerable and the routes are not rate-limited |
+| **not** intended | inherit the member instead of re-declaring it, so `file.downloadRoles` governs it again |
+
+**No new warning if you do not subclass**, and none if you subclass without re-declaring a governed
+member — the audit only reports roles the configuration cannot account for, so it never duplicates
+the existing configuration-side warning.
+
+Governed members: `getFileById`, `getFile` (controller); `getFileInfo`, `uploadFile`, `uploadFiles`,
+`deleteFile` (resolver).
+
+---
+
+## Module Documentation
+
+- File module, upload filters and access rules: [`src/core/modules/file/README.md`](../src/core/modules/file/README.md)
+- Request lifecycle and exception handling: [`docs/REQUEST-LIFECYCLE.md`](../docs/REQUEST-LIFECYCLE.md)

package/migration-guides/11.35.1-to-11.36.0.md

@@ -0,0 +1,168 @@
+# Migration Guide: 11.35.1 → 11.36.0
+
+## Overview
+
+| Category | Details |
+|----------|---------|
+| **Breaking Changes** | Sign-in and sign-up now **validate their input**. An address that does not satisfy `IsEmail` is refused with a 400 before Better-Auth sees it — which can lock out an existing account created outside `CoreUserInput` (§2) |
+| **New Features** | `betterAuth.emailAndPassword.revokeSessionsOnPasswordReset` — opt-in, ends the sessions that already existed when the user resets their password (§1) |
+| **Bugfixes** | `brevo.exclude` stopped excluding every second recipient (§3). Malformed or absent sign-in input answers 400 instead of 500 (§2) |
+| **Migration Effort** | **Read §2 before upgrading** and run the account audit there. §1 is opt-in and off by default; §3 needs nothing |
+
+---
+
+## Quick Migration
+
+```bash
+pnpm update @lenne.tech/nest-server@11.36.0
+pnpm run build
+pnpm test
+```
+
+Then run the audit in §2 — it is the only step that can surprise you.
+
+**Vendor-mode projects:** all three changes are independent and single-file —
+`modules/better-auth/better-auth.config.ts` (§1),
+`modules/better-auth/core-better-auth.controller.ts` (§2),
+`common/services/brevo.service.ts` (§3). §1 also adds the option to
+`common/interfaces/server-options.interface.ts`; taking the config field without the
+`better-auth.config.ts` half gives you a setting that type-checks and does nothing, so sync those two
+together.
+
+---
+
+## 1. End existing sessions on a password reset (opt-in)
+
+A password reset is what somebody reaches for when they suspect their account was taken over.
+Leaving the older sessions alive defeats the point: the attacker keeps theirs, and the new password
+changes nothing for them.
+
+```typescript
+// config.env.ts
+betterAuth: {
+  emailAndPassword: {
+    revokeSessionsOnPasswordReset: true,
+  },
+},
+```
+
+Forwarded to Better-Auth's native flag, which honours it on **all three** reset routes — password
+reset, email-OTP and phone-number.
+
+**Off by default, and staying that way.** It is a behaviour change for an existing deployment: after
+a reset the user is signed out everywhere, including on the devices they still hold. That is worth
+choosing, not worth inflicting on upgrade.
+
+The value is matched with `=== true`, so a truthy-but-not-`true` value arriving as JSON through
+`NSC__*` or `NEST_SERVER_CONFIG` (a hand-written `"true"`, say) does **not** silently enable a
+sign-out-everywhere behaviour.
+
+> **Do not route this through `betterAuth.options` instead.** That object is spread *shallowly* over
+> the resolved config — only `advanced` is deep-merged — so an `options.emailAndPassword` does not
+> add a key, it **replaces the whole block**, including the scrypt `password.hash` / `password.verify`
+> pair the framework installs. Every credential in your database would stop verifying, at runtime,
+> with no boot error. This is why the flag is a first-class config field.
+
+---
+
+## 2. Sign-in and sign-up validate their input — read this before upgrading
+
+### What changed
+
+`CoreBetterAuthSignInInput` and `CoreBetterAuthSignUpInput` carried `@ApiProperty()` only:
+documentation, no validation. Every line of the handler then reads `input.email`, so a body that was
+malformed or absent produced a `TypeError` and reached the client as a **500**.
+
+| Request | Before | After |
+|---|---|---|
+| `{"email": "not-an-email", "password": "x"}` | `500` | `400`, naming the field |
+| `{}` | `500` | `400`, naming both fields |
+| no body at all | `500` | `400` `Missing input` |
+| valid credentials | unchanged | unchanged |
+
+On the most-probed endpoint any deployment has, a 500 tells the caller to retry something that can
+never succeed and files their mistake in the same bucket as a real outage. The legacy sign-in
+answered these cases with a 400; that contract is restored.
+
+### The part that can lock someone out
+
+`@IsEmail()` is now enforced on **sign-in**, not just on sign-up. An account whose stored address
+does not satisfy it can no longer authenticate — the request is refused before Better-Auth is
+reached.
+
+This is unlikely but not impossible. `CoreUserInput.email` has always carried the same `IsEmail()`
+validator, so an account created through the normal API cannot be affected. An account can still
+have been created another way:
+
+- a seed script or migration writing directly through Mongoose,
+- Better-Auth's own native sign-up route,
+- an import from another system.
+
+The addresses at risk are the ones that look fine to a human and fail `validator.js`: no TLD
+(`admin@localhost`), a dotless domain (`test@test`), or trailing whitespace.
+
+**Audit before upgrading.** Use the real validator rather than a hand-written pattern — `IsEmail`
+delegates to `validator.js`, whose rules are far more involved than any regex you would write for
+this, and a check that disagrees with the one actually enforced is worse than none:
+
+```js
+// node — run from your project root, where class-validator's `validator` resolves
+const isEmail = require('validator/lib/isEmail');
+const { MongoClient } = require('mongodb');
+
+const client = await MongoClient.connect(process.env.MONGODB_URI);
+const users = await client.db().collection('users').find({}, { projection: { email: 1 } }).toArray();
+const locked = users.filter(u => !u.email || !isEmail(u.email));
+
+console.log(`${locked.length} account(s) can no longer sign in:`);
+locked.forEach(u => console.log(' ', JSON.stringify(u.email), u._id.toString()));
+await client.close();
+```
+
+Anything this lists needs its address corrected before the upgrade, or those users are refused with a
+validation error rather than an authentication error — and the message will not point at the cause.
+
+### If you subclass the controller
+
+The validation lives on the DTOs, so an override that keeps the parameter types inherits it. A
+subclass that declares its **own** input class is responsible for its own validators —
+`MapAndValidatePipe` walks the prototype chain child-first and skips a property once a child class
+has validated it.
+
+`termsAndPrivacyAccepted` is deliberately the one sign-up field without a presence validator: whether
+consent is required is a policy question answered by `betterAuth.signUpValidation` through
+`CoreBetterAuthSignUpValidatorService`, not by the DTO. It does now carry `@IsBoolean()`.
+
+---
+
+## 3. `brevo.exclude` excluded only every second recipient
+
+`BrevoService` called `.test()` on the configured `RegExp`. Projects declare that pattern with the
+`g` flag:
+
+```typescript
+brevo: { exclude: /@(testuser\.com|test\.de)/gi }
+```
+
+`RegExp.prototype.test` advances `lastIndex` on a `g` or `y` pattern, and the config holds a single
+shared instance — so the same address answered `true`, `false`, `true`, … across calls. **Every
+second excluded recipient was sent a real, billable transactional mail.**
+
+Found in production: a CI end-to-end run delivered five mails to a `@testuser.com` address that the
+project's own exclude pattern lists, and the provider flagged the runner's IP before anyone noticed
+the guard was only half working.
+
+The check now matches against a flagless copy, so each call is independent and the configured
+pattern's `lastIndex` is left untouched — it is shared process-wide, and mutating it leaked into
+every later reader. Both send paths were affected; both are fixed.
+
+**Nothing to do.** If you kept the `g` flag off as a workaround, you can stop — it no longer matters
+either way.
+
+---
+
+## Module Documentation
+
+- BetterAuth integration: [`src/core/modules/better-auth/INTEGRATION-CHECKLIST.md`](../src/core/modules/better-auth/INTEGRATION-CHECKLIST.md)
+- BetterAuth customization: [`src/core/modules/better-auth/CUSTOMIZATION.md`](../src/core/modules/better-auth/CUSTOMIZATION.md)
+- Configuration patterns: [`.claude/rules/configurable-features.md`](../.claude/rules/configurable-features.md)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.35.0",
+  "version": "11.36.0",
   "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",
@@ -91,21 +91,21 @@
     "@apollo/server": "5.5.1",
     "@as-integrations/express5": "1.1.2",
     "@better-auth/passkey": "1.6.26",
-    "@getbrevo/brevo": "6.0.2",
+    "@getbrevo/brevo": "6.0.3",
     "@modelcontextprotocol/sdk": "1.30.0",
-    "@nestjs/apollo": "13.4.2",
-    "@nestjs/common": "11.1.29",
-    "@nestjs/core": "11.1.29",
-    "@nestjs/graphql": "13.4.2",
+    "@nestjs/apollo": "13.4.5",
+    "@nestjs/common": "11.2.1",
+    "@nestjs/core": "11.2.1",
+    "@nestjs/graphql": "13.4.5",
     "@nestjs/jwt": "11.0.2",
     "@nestjs/mongoose": "11.0.4",
     "@nestjs/passport": "11.0.5",
-    "@nestjs/platform-express": "11.1.29",
+    "@nestjs/platform-express": "11.2.1",
     "@nestjs/schedule": "6.1.3",
-    "@nestjs/swagger": "11.4.6",
+    "@nestjs/swagger": "11.4.7",
     "@nestjs/terminus": "11.1.1",
     "@tus/file-store": "2.1.1",
-    "@tus/server": "2.4.3",
+    "@tus/server": "2.4.4",
     "@types/supertest": "7.2.1",
     "bcrypt": "6.0.0",
     "better-auth": "1.6.26",
@@ -122,12 +122,12 @@
     "graphql-subscriptions": "3.0.0",
     "graphql-upload": "15.0.2",
     "graphql-ws": "6.2.1",
-    "jose": "6.2.8",
+    "jose": "6.2.9",
     "js-sha256": "1.0.0",
     "json-to-graphql-query": "2.3.0",
     "lodash": "4.18.1",
     "mongodb": "7.5.0",
-    "mongoose": "9.9.1",
+    "mongoose": "9.9.3",
     "multer": "2.2.0",
     "node-mailjet": "6.0.11",
     "nodemailer": "9.0.5",
@@ -166,15 +166,15 @@
     }
   },
   "devDependencies": {
-    "@aws-sdk/client-s3": "3.1106.0",
-    "@aws-sdk/s3-request-presigner": "3.1106.0",
+    "@aws-sdk/client-s3": "3.1112.0",
+    "@aws-sdk/s3-request-presigner": "3.1112.0",
     "@compodoc/compodoc": "2.0.0",
     "@nestjs/cli": "11.0.24",
     "@nestjs/schematics": "11.1.0",
-    "@nestjs/testing": "11.1.28",
+    "@nestjs/testing": "11.2.1",
     "@swc/cli": "0.8.1",
-    "@swc/core": "1.15.47",
-    "@tus/s3-store": "2.0.5",
+    "@swc/core": "1.16.0",
+    "@tus/s3-store": "2.0.6",
     "@types/compression": "1.8.1",
     "@types/cookie-parser": "1.4.10",
     "@types/ejs": "3.1.5",
@@ -187,22 +187,22 @@
     "@vitest/coverage-v8": "4.1.10",
     "@vitest/ui": "4.1.10",
     "ansi-colors": "4.1.3",
-    "bullmq": "6.0.9",
+    "bullmq": "6.1.2",
     "find-file-up": "2.0.1",
     "husky": "9.1.7",
     "ioredis": "6.0.0",
     "nodemon": "3.1.14",
     "npm-watch": "0.13.0",
     "otpauth": "9.5.1",
-    "oxfmt": "0.62.0",
-    "oxlint": "1.77.0",
+    "oxfmt": "0.63.0",
+    "oxlint": "1.78.0",
     "rimraf": "6.1.3",
     "ts-node": "10.9.2",
     "tsconfig-paths": "4.2.0",
-    "tsx": "4.23.11",
+    "tsx": "4.23.12",
     "tus-js-client": "4.3.1",
     "typescript": "5.9.3",
-    "unplugin-swc": "1.5.10",
+    "unplugin-swc": "1.5.11",
     "vite": "8.2.1",
     "vite-plugin-node": "8.0.0",
     "vitest": "4.1.10"

package/src/core/common/helpers/file.helper.ts

@@ -1,3 +1,4 @@
+import { BadRequestException } from '@nestjs/common';
 import { MulterOptions } from '@nestjs/platform-express/multer/interfaces/multer-options.interface';
 import { randomBytes } from 'crypto';
 import { diskStorage, memoryStorage } from 'multer';
@@ -147,9 +148,14 @@ function normalizeMimeType(value: string): string {
  * `options.allowScriptableTypes` is set — that is what closes the hole for
  * expressions that already exist in consumer projects.
  *
- * Rejections are reported as a real `Error`. Passing a bare string (as this
- * helper did before) leaves multer with an "error" that has no `message`, which
- * NestJS's `transformException` cannot map to a 4xx.
+ * Rejections are reported as a `BadRequestException`, so the caller gets a 400
+ * with a readable reason. An `HttpException` is required, not merely tidier:
+ * NestJS's `transformException` returns any NON-`HttpException` unchanged — its
+ * switch matches only multer's own message constants (`LIMIT_FILE_SIZE`,
+ * `LIMIT_UNEXPECTED_FILE`, …), and a message written here matches none of them.
+ * A bare `new Error()` therefore still surfaced to the client as a 500, which
+ * reads as "the server broke" for what is in fact a refused file. See
+ * `tests/unit/file-upload-rejection-status.spec.ts`.
  */
 export function multerFileFilter(
   accept: RegExp | UploadAllowList = IMAGE_UPLOAD_ALLOW_LIST,
@@ -163,7 +169,7 @@ export function multerFileFilter(
       !options?.allowScriptableTypes &&
       (SCRIPTABLE_UPLOAD_MIME_TYPES.includes(mimeType) || SCRIPTABLE_UPLOAD_EXTENSIONS.includes(extension))
     ) {
-      return cb(new Error(`File upload rejected: ${mimeType || 'unknown type'} may execute as script`));
+      return cb(new BadRequestException(`File upload rejected: ${mimeType || 'unknown type'} may execute as script`));
     }
 
     const accepted =
@@ -174,7 +180,7 @@ export function multerFileFilter(
     if (accepted) {
       return cb(null, true);
     }
-    cb(new Error(`File upload only supports the following filetypes - ${describeAccept(accept)}`));
+    cb(new BadRequestException(`File upload only supports the following filetypes - ${describeAccept(accept)}`));
   };
 }
 

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

@@ -3414,6 +3414,30 @@ interface IBetterAuthBase {
      * @default true
      */
     enabled?: boolean;
+
+    /**
+     * End every existing session when the user completes a password reset.
+     *
+     * A reset is what somebody reaches for when they suspect their account was
+     * taken over, so leaving the older sessions alive defeats the point: the
+     * attacker keeps theirs and the new password changes nothing for them.
+     *
+     * Left off by default because it is a behaviour change for existing
+     * deployments — a reset then signs the user out everywhere, including on
+     * the devices they still hold.
+     *
+     * Passed through to better-auth's native
+     * `emailAndPassword.revokeSessionsOnPasswordReset`. It cannot be set via
+     * `options` instead: that object is spread SHALLOWLY over the resolved
+     * config, so an `options.emailAndPassword` would replace the whole block
+     * — including the scrypt `password.hash` / `password.verify` pair this
+     * framework installs — and every credential in the database would stop
+     * verifying.
+     *
+     * @default false
+     * @since 11.36.0
+     */
+    revokeSessionsOnPasswordReset?: boolean;
   };
 
   /**

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

@@ -53,9 +53,8 @@ export class BrevoService {
         return false;
       }
 
-      // Exclude (test) users, must be done via config and not via configFastButReadOnly,
-      // otherwise the error TypeError: Cannot assign to read only property 'lastIndex' of object '[object RegExp]' occurs
-      if (this.configService.config?.brevo?.exclude?.test?.(to)) {
+      // Exclude (test) users
+      if (this.isExcluded(to)) {
         return 'TEST_USER!';
       }
 
@@ -98,9 +97,8 @@ export class BrevoService {
         return false;
       }
 
-      // Exclude (test) users, must be done via config and not via configFastButReadOnly,
-      // otherwise the error TypeError: Cannot assign to read only property 'lastIndex' of object '[object RegExp]' occurs
-      if (this.configService.config?.brevo?.exclude?.test?.(to)) {
+      // Exclude (test) users
+      if (this.isExcluded(to)) {
         return 'TEST_USER!';
       }
 
@@ -135,6 +133,36 @@ export class BrevoService {
     return { 'Idempotency-Key': randomUUID() };
   }
 
+  /**
+   * Checks a recipient against `brevo.exclude` without inheriting the pattern's match state.
+   *
+   * Two traps live in this one line, and both have bitten:
+   *
+   * 1. `RegExp.prototype.test` ADVANCES `lastIndex` on a pattern carrying `g` or `y`. The config
+   *    holds a single shared instance and projects declare it as `/…/gi`, so calling `.test()` on
+   *    it directly answers true, false, true, … for the very same address — every second excluded
+   *    recipient receives a real mail. Matching against a flagless copy keeps each call
+   *    independent and leaves the configured pattern untouched.
+   * 2. It must be read from `config`, never from `configFastButReadOnly`: assigning `lastIndex` on
+   *    the frozen copy throws `TypeError: Cannot assign to read only property 'lastIndex'`.
+   *    Point 1 removes the assignment, but the frozen object may still be a `deepFreeze`d clone
+   *    whose flags differ, so the mutable side stays the source of truth.
+   *
+   * @param to - Recipient email address
+   * @returns `true` when the recipient matches the configured exclude pattern
+   */
+  protected isExcluded(to: string): boolean {
+    const exclude = this.configService.config?.brevo?.exclude;
+    if (typeof exclude?.test !== 'function') {
+      return false;
+    }
+
+    const stateless =
+      exclude.global || exclude.sticky ? new RegExp(exclude.source, exclude.flags.replace(/[gy]/g, '')) : exclude;
+
+    return stateless.test(to);
+  }
+
   /**
    * Lazily constructs (and memoises) the Brevo SDK client.
    *

package/src/core/modules/better-auth/better-auth.config.ts

@@ -444,6 +444,10 @@ export function createBetterAuthInstance(options: CreateBetterAuthOptions): Crea
         hash: nativeScryptHash,
         verify: nativeScryptVerify,
       },
+      // Opt-in: a reset then also ends the sessions that already existed, which
+      // is the point of resetting after a suspected takeover. Off by default so
+      // the behaviour of existing deployments does not change under them.
+      revokeSessionsOnPasswordReset: config.emailAndPassword?.revokeSessionsOnPasswordReset === true,
     },
     plugins,
     secret: validation.resolvedSecret || config.secret,