@lenne.tech/nest-server 11.43.2 → 11.43.4

package/docs/REQUEST-LIFECYCLE.md

@@ -179,7 +179,7 @@ JWT-based authentication for existing projects:
 | **AI Module** | Prompt orchestrator (auto + plan mode), DB-backed LLM connections, tool registry |
 | **REST Endpoints** | `POST /ai/prompt`, `POST /ai/stream` (SSE); `GET/POST/PUT/DELETE /ai/connections*`, `/ai/connections/available`, `/ai/connections/select`, `/ai/connections/preferences*`, `/ai/conversations*`, `/ai/interactions*`, `/ai/budget-limits*`, `GET /ai/usage` |
 | **GraphQL Endpoints** | `aiPrompt`, `aiAvailableConnections`, `aiSetUserConnection`, connection/preference/conversation/interaction/budget queries + mutations, `aiUsage` |
-| **MCP Server** | Streamable HTTP at `POST/GET/DELETE /ai/mcp` (Bearer auth); with `ai.mcp.oauth` an OAuth 2.1 router (`/.well-known/*`, `/authorize`, `/token`, `/register`) that `CoreAiMcpOAuthInitializer` mounts during `app.init()` — an Express router behind the Nest middleware and routes, ahead of Nest's not-found handler, so guards and interceptors do not run for it; `/authorize` answers with a built-in consent page (the Better-Auth session from the middleware is the user; Allow is a CSRF-bound POST) |
+| **MCP Server** | Streamable HTTP at `POST/GET/DELETE /ai/mcp` (Bearer auth); a user the controller resolves itself (the OAuth access token, which only this controller accepts, after the guards ran without a user) gets `req.user` and the tenant the header names from an active membership only, through `CoreTenantGuard.resolveMembershipContext()` (11.43.3); with `ai.mcp.oauth` an OAuth 2.1 router (`/.well-known/*`, `/authorize`, `/token`, `/register`) that `CoreAiMcpOAuthInitializer` mounts during `app.init()` — an Express router behind the Nest middleware and routes, ahead of Nest's not-found handler, so guards and interceptors do not run for it; `/authorize` answers with a built-in consent page (the Better-Auth session from the middleware is the user; Allow is a CSRF-bound POST) |
 | **Permission Model** | `S_USER` for prompt/conversations/available/usage; `ADMIN` for connections/preferences/interactions/budgets; encrypted API keys never leave the server (`securityCheck` + `secretFields`) |
 
 ### Email & Templates

package/docs/security-overrides.md

@@ -19,7 +19,7 @@ used to **exact-pin**, to a vulnerable version:
 | `ws` | [GHSA-96hv-2xvq-fx4p](https://github.com/advisories/GHSA-96hv-2xvq-fx4p) — high: memory-exhaustion DoS + uninitialized memory disclosure. Patched `>=8.21.0` | Older `@nestjs/graphql` releases declare `"ws": "8.20.1"` — an **exact pin**, not a caret. 13.4.5, the version this framework declares, pins `8.21.3` |
 | `js-yaml` | [GHSA-pm4m-ph32-ghv5](https://github.com/advisories/GHSA-pm4m-ph32-ghv5) — high: exponential parsing time in flow collections (DoS), patched `>=5.2.2`; [GHSA-r3ph-w7gj-g6xm](https://github.com/advisories/GHSA-r3ph-w7gj-g6xm) — moderate: `maxTotalMergeKeys` does not bound CPU use for empty merge sources, covers `<=5.4.0`, patched `>=5.4.1` (published 2026-09-29) | `@nestjs/swagger` declares js-yaml as an **exact pin**, the same shape as the `ws` case: older releases `5.2.1`, 11.4.7 — the version this framework declares, and the newest 11.x — `5.3.0`. No swagger update reaches the fix, so **this entry is load-bearing again** |
 | `@graphql-tools/utils` | [GHSA-7mx3-vvmw-hjmv](https://github.com/advisories/GHSA-7mx3-vvmw-hjmv) — high: prototype pollution in `mergeDeep`, which runs while the GraphQL schema is assembled. Covers `<=12.0.0`, patched `>=12.0.1` (added 2026-10-06) | `@nestjs/graphql` 13.4.5 — the version this framework declares, and the newest 13.x — declares `"@graphql-tools/utils": "12.0.0"`, an **exact pin**. Only `@nestjs/graphql` 14.x moves it, so **this entry is load-bearing**. `@apollo/server` reaches it too, through `@graphql-tools/schema` / `merge` — and in a lockfile that still holds schema 10.0.x (resolved before 2026-08-12), as **utils 11.x**: vulnerable too, with no 11.x fix, and outside the override key. Lift it with `pnpm update --depth Infinity @graphql-tools/schema @graphql-tools/merge`; the current releases request utils `^12.0.3`, which needs Node >=22.15 — the framework's own floor since 11.42.10, which is why the snippet below targets 12.0.3 |
-| `multer` | [GHSA-wc9g-mqfw-jrwm](https://github.com/advisories/GHSA-wc9g-mqfw-jrwm), [GHSA-535w-7cp7-47q4](https://github.com/advisories/GHSA-535w-7cp7-47q4), [GHSA-qfvm-cv95-jqjf](https://github.com/advisories/GHSA-qfvm-cv95-jqjf) — high: DoS via crafted multipart input; [GHSA-qvfw-j98x-7q72](https://github.com/advisories/GHSA-qvfw-j98x-7q72) — low: file size limit bypass. Patched `>=2.3.0` | `@nestjs/platform-express` up to 11.2.5 declares `"multer": "2.2.0"` — an **exact pin**. A direct `multer` dependency does not move it: you get both copies, and FileInterceptor uses the vulnerable one. 11.2.6, which this framework declared from 11.41.4, pins `2.4.0`, and so does 11.2.7, declared since 11.41.7 |
+| `multer` | [GHSA-wc9g-mqfw-jrwm](https://github.com/advisories/GHSA-wc9g-mqfw-jrwm), [GHSA-535w-7cp7-47q4](https://github.com/advisories/GHSA-535w-7cp7-47q4), [GHSA-qfvm-cv95-jqjf](https://github.com/advisories/GHSA-qfvm-cv95-jqjf) — high: DoS via crafted multipart input; [GHSA-qvfw-j98x-7q72](https://github.com/advisories/GHSA-qvfw-j98x-7q72) — low: file size limit bypass. Patched `>=2.3.0`. [GHSA-q7qp-rjg7-q26m](https://github.com/advisories/GHSA-q7qp-rjg7-q26m) — high: DoS via a pending asynchronous `fileFilter` after request teardown, covers 2.4.0, patched `>=2.5.0` (published 2026-10-23) | `@nestjs/platform-express` up to 11.2.5 declares `"multer": "2.2.0"` — an **exact pin**. A direct `multer` dependency does not move it: you get both copies, and FileInterceptor uses the vulnerable one. 11.2.6 to 11.2.8, the newest 11.x, pin `2.4.0`, which GHSA-q7qp-rjg7-q26m covers. No 11.x update reaches the fix, so **this entry is load-bearing again since 11.43.4** |
 
 **Status since 11.42.4:** `@graphql-tools/utils` joins `js-yaml` as load-bearing — no `@nestjs/graphql`
 13.x resolves past the exact pin. The 11.42.4 release also covers `proxy-addr` (GHSA-jqcg-44mw-7w3h,
@@ -58,10 +58,10 @@ overrides:
   # Remove once @nestjs/swagger pins >=5.4.1 itself.
   'js-yaml@>=5.0.0 <5.4.2': '5.4.2'
 
-  # @nestjs/platform-express <=11.2.5 exact-pins multer@2.2.0 (GHSA-wc9g-mqfw-jrwm and three more, patched >=2.3.0).
-  # Keep the target in LOCKSTEP with the multer version @lenne.tech/nest-server declares (2.4.0 since 11.41.4).
-  # Inert on @nestjs/platform-express 11.2.6+, which pins 2.4.0 itself.
-  'multer@>=2.0.0 <2.4.0': '2.4.0'
+  # @nestjs/platform-express 11.x exact-pins multer (<=11.2.5: 2.2.0, 11.2.6 to 11.2.8: 2.4.0).
+  # GHSA-q7qp-rjg7-q26m (high, DoS) covers 2.4.0, patched >=2.5.0. LOAD-BEARING again since 11.43.4.
+  # Keep the target in LOCKSTEP with the multer version @lenne.tech/nest-server declares (2.5.0 since 11.43.4).
+  'multer@>=2.0.0 <2.5.0': '2.5.0'
 
   # @nestjs/graphql 13.4.5 exact-pins @graphql-tools/utils@12.0.0 — GHSA-7mx3-vvmw-hjmv (high, patched >=12.0.1).
   # Target the newest 12.x, so the caret requesters (@graphql-tools/schema / merge) are not held back —

package/migration-guides/11.43.2-to-11.43.3.md

@@ -0,0 +1,80 @@
+# Migration Guide: 11.43.2 → 11.43.3
+
+## Overview
+
+| Category             | Details                                                                                                                                                                                                                                                                              |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Bugfixes**         | An MCP OAuth access token reaches the tenant context: tenant-scoped AI tools answered "Tenant context required" to every OAuth client, members included (§1). The OAuth user is the current user of the request, so audit fields and the role guard plugin apply to tool writes (§2) |
+| **New Features**     | None                                                                                                                                                                                                                                                                                 |
+| **Framework API**    | `CoreTenantGuard.resolveMembershipContext()` (new, public), the optional `resolveMembership()` on the exported `TenantContextResolver` interface, `CoreAiMcpController.resolveScopedUser()` / `scopeLateResolvedUser()` (new, protected)                                             |
+| **Dependencies**     | Unchanged                                                                                                                                                                                                                                                                            |
+| **Breaking Changes** | None                                                                                                                                                                                                                                                                                 |
+| **Migration Effort** | None. Check §2 if MCP tools of your project write data                                                                                                                                                                                                                               |
+
+## Quick Migration
+
+```bash
+pnpm update @lenne.tech/nest-server
+```
+
+Vendor-mode projects pick it up with the core update. No code or configuration change is required.
+
+## 1. MCP OAuth clients got no tenant context
+
+`CoreTenantGuard` turns the tenant header (`X-Tenant-Id`) into a tenant context only for a user it sees on the
+request. A session cookie and a Better-Auth JWT are resolved by the middleware before the guards. An MCP OAuth
+access token is not: nothing but `CoreAiMcpController` accepts it, so it is resolved after the guards. The request
+therefore never got a tenant, and `mongooseTenantPlugin` refused every tenant-scoped read — a generic MCP client
+could discover, register, pass the consent page, open a session and list its tools, and then every tenant-scoped
+tool answered `Tenant context required`, even with a header naming a tenant the user is an active member of.
+
+The controller now asks the guard's own membership check (`CoreTenantGuard.resolveMembershipContext()`, the same
+decision as its `@Roles(S_EVERYONE)` branch) for a user it resolved itself. The result does not depend on the
+credential:
+
+| Request                                               | Session cookie / JWT | MCP OAuth token (11.43.2) | MCP OAuth token (11.43.3) |
+| ----------------------------------------------------- | -------------------- | ------------------------- | ------------------------- |
+| Header names a tenant the user is an active member of | that tenant          | none — refused            | that tenant               |
+| Header names a tenant the user is not a member of     | none — refused       | none — refused            | none — refused            |
+| No header                                             | none — refused       | none — refused            | none — refused            |
+
+The header alone never establishes a tenant, which is what keeps a freely chosen `X-Tenant-Id` harmless.
+
+## 2. The OAuth user is the current user of the request
+
+For the same reason `req.user` stayed unset for an OAuth request, and `RequestContext.currentUser` is read from
+it. The Mongoose plugins read an empty current user as work the server does on its own:
+
+- `createdBy` / `updatedBy` were not written for data an MCP tool created or changed,
+- `mongooseRoleGuardPlugin` let a tool's write change `roles` without checking the caller,
+- `assertTenantRole()` refused the call as anonymous.
+
+Since 11.43.3 the controller sets `req.user` for a user it resolved itself, so all three behave as for a cookie or
+JWT request.
+
+**What to check:**
+
+- **An MCP tool of your project writes `roles` and relied on the role guard plugin letting it through:** under an
+  OAuth token that write is now checked against the user, as it always was under a cookie or a JWT. Run such a
+  write inside `RequestContext.runWithBypassRoleGuard()` when the tool is meant to assign roles.
+- **A test in your project pins the old refusal** ("Tenant context required" for an OAuth member): flip it to
+  assert the data, and keep the cases for a non-member and for a missing header refused.
+- **You override `CoreAiMcpController.handlePost()` or `handleGet()` / `handleDelete()`** without calling
+  `super`: resolve the user through `resolveScopedUser(req)` instead of `resolveUser(req)`, or the fix does not
+  reach your controller.
+
+## Compatibility Notes
+
+| Pattern                                                                      | Status                                                                                                        |
+| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
+| MCP over a session cookie or a Better-Auth JWT                               | Unchanged — the guards saw the user before                                                                    |
+| MCP OAuth without `multiTenancy`                                             | Unchanged apart from §2                                                                                       |
+| Your own `TenantContextResolver` registered via `setTenantContextResolver()` | Compiles unchanged — `resolveMembership()` is optional; without it an OAuth request gets no tenant, as before |
+| An override of `resolveUser()`                                               | Still used — `resolveScopedUser()` calls it                                                                   |
+
+## Module Documentation
+
+- [AI module → Tool access is the user's access](../src/core/modules/ai/README.md#tool-access-is-the-users-access)
+- [Tenant module](../src/core/modules/tenant/README.md)
+- Implementation: `src/core/modules/ai/core-ai-mcp.controller.ts` → `scopeLateResolvedUser()`,
+  `src/core/modules/tenant/core-tenant.guard.ts` → `resolveMembershipContext()`

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

@@ -0,0 +1,119 @@
+# Migration Guide: 11.43.3 → 11.43.4
+
+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**         | A legacy logout ends the device's refresh token; with `allDevices` it ends every device (§1). The legacy REST rate limit can no longer be bypassed with a query string (§1b)                                                   |
+| **New Features**     | None                                                                                                                                                                                                                          |
+| **Framework API**    | Unchanged                                                                                                                                                                                                                     |
+| **Dependencies**     | `nodemailer` 10.1.2 → 10.1.4 (§2), `multer` 2.4.0 → 2.5.0 (§3)                                                                                                                                                                |
+| **Breaking Changes** | None                                                                                                                                                                                                                          |
+| **Migration Effort** | Raise the version, add or raise the `multer` override (§3), refresh four transitive packages (§4)                                                                                                                             |
+
+## 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.4
+```
+
+Then add the `multer` override from §3 to `pnpm-workspace.yaml` (or raise the one you already have), raise the
+`body-parser` and `fast-uri` entries from §4 if your project carries them, and refresh:
+
+```bash
+pnpm install
+pnpm update --depth Infinity body-parser zod fast-uri @hono/node-server
+pnpm audit --prod
+pnpm test
+```
+
+Vendor-mode projects update the core to the tag `11.43.4` with the core updater and apply §3 and §4 the same way.
+
+## 1. A legacy logout did not end the refresh token
+
+`CoreAuthService.logout()` removed the device from `refreshTokens` and wrote the map back through `update()`. `update()`
+merges its input into the stored record, so a key that is merely missing from the input survives: the logged-out
+device's refresh token kept working, and `logout(allDevices)`, which wrote an empty map, left every device signed in.
+A user who signed out, or signed out everywhere after losing a device, stayed reachable for whoever held the refresh
+token.
+
+The logout now writes `null` for every device it ends, in `refreshTokens` and `tempTokens`; `validateUser()` reads a
+`null` device as signed out. No action is needed. A project that overrides `logout()` and writes the token maps itself
+must do the same: write `null` for an ended device, never delete its key.
+
+This affects every project that keeps the legacy endpoints open (`auth.legacyEndpoints`, or the three-argument
+`CoreModule.forRoot()` from before 11.38.0). IAM (Better-Auth) sessions are not affected.
+
+## 1b. The legacy REST rate limit counted every spelling of a route separately
+
+`LegacyAuthRateLimitGuard` keyed the REST counter on the last segment of `request.url`, query string included. Express
+routes `/auth/signin?n=1`, `/auth/signin?n=2` and `/auth/SignIn/` to the same handler, but each got a fresh bucket, so
+`auth.rateLimit` never stopped password guessing against `/auth/signin` (or sign-up spam against `/auth/signup`). The
+counter is now keyed on the route handler. No action is needed; projects with `auth.rateLimit` configured and the legacy
+REST endpoints open are the ones that were exposed.
+
+## 2. nodemailer 10.1.4
+
+Three advisories in nodemailer's address parser, all moderate (CVSS 6.5), all patched in 10.1.4: a nested comment
+([GHSA-8c8m-p3m8-cjg8](https://github.com/advisories/GHSA-8c8m-p3m8-cjg8)), a `;` inside a quoted string
+([GHSA-m943-m63m-w62w](https://github.com/advisories/GHSA-m943-m63m-w62w)) and a `>` inside a quoted local part
+([GHSA-85x2-q946-cp5h](https://github.com/advisories/GHSA-85x2-q946-cp5h)) each turn text of an address into an
+additional recipient. nest-server pins nodemailer itself, so raising the framework is enough. A project that declares
+its own `nodemailer`, or carries an override for it, raises that to 10.1.4 as well.
+
+## 3. multer 2.5.0 — the override is needed again
+
+[GHSA-q7qp-rjg7-q26m](https://github.com/advisories/GHSA-q7qp-rjg7-q26m) (high, CVSS 7.5): a pending asynchronous
+`fileFilter` after the request was torn down leads to a denial of service. It covers 2.4.0, patched in 2.5.0.
+
+nest-server now declares 2.5.0, but every `@nestjs/platform-express` 11.x up to 11.2.8, the newest, pins multer
+**exactly** (2.4.0), and `FileInterceptor` uses that copy. No 11.x update reaches the fix, so the project needs an
+override:
+
+```yaml
+# pnpm-workspace.yaml of the project
+overrides:
+  # @nestjs/platform-express 11.x exact-pins multer 2.4.0 (GHSA-q7qp-rjg7-q26m, fixed 2.5.0)
+  'multer@>=2.0.0 <2.5.0': '2.5.0'
+```
+
+A project that already mirrors the older entry (`'multer@>=2.0.0 <2.4.0': '2.4.0'`) must raise both key and target:
+the old target is the vulnerable version.
+
+## 4. Transitive packages: refresh the lockfile
+
+Four advisories of the same week sit in packages nest-server does not pin; they are fixed by a lockfile refresh in the
+project (the command in Quick Migration):
+
+| Package | Advisory | Patched |
+| ------- | -------- | ------- |
+| `body-parser` (via `@apollo/server`, express) | [GHSA-27r3-jxmh-p828](https://github.com/advisories/GHSA-27r3-jxmh-p828), high | 2.4.0 |
+| `zod` (via `@modelcontextprotocol/sdk`) | [GHSA-mrhx-c7xc-m3w5](https://github.com/advisories/GHSA-mrhx-c7xc-m3w5), high | 4.6.6 |
+| `fast-uri` (via ajv) | four advisories up to moderate | 3.1.9 |
+| `@hono/node-server` (via `@modelcontextprotocol/sdk`) | [GHSA-rmxm-3fg6-px4f](https://github.com/advisories/GHSA-rmxm-3fg6-px4f), moderate | 2.1.3 |
+
+**A project that carries an override for `body-parser` or `fast-uri`** (starter-based projects do) must raise it, or
+the old target keeps the vulnerable version in place:
+
+```yaml
+  'body-parser@>=2.0.0 <2.4.0': '2.4.0'   # was '<2.3.0': '2.3.0'
+  'fast-uri@<3.1.9': '3.1.9'              # was '<3.1.8': '3.1.8'
+```
+
+`pnpm run check:overrides`, where a project has it, reports each of these as `TOO LOW`.
+
+## Not in this release
+
+Fixes from 12.x that are not urgent security fixes stay there, among them the configuration dump of a second
+`new ConfigService()` (12.0.0) and the fixes for `distinct()` over ObjectId fields and for names lost at an IAM sign-in
+(12.1.0). They arrive with the move to 12: `migration-guides/11.43.x-to-12.0.x.md`.
+
+## Module Documentation
+
+- [Auth (Legacy)](../src/core/modules/auth/)
+- [Security overrides](../docs/security-overrides.md)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.43.2",
+  "version": "11.43.4",
   "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",
@@ -127,9 +127,9 @@
     "lodash": "4.18.1",
     "mongodb": "7.7.0",
     "mongoose": "9.11.2",
-    "multer": "2.4.0",
+    "multer": "2.5.0",
     "node-mailjet": "6.0.11",
-    "nodemailer": "10.1.2",
+    "nodemailer": "10.1.4",
     "passport": "0.7.0",
     "passport-jwt": "4.0.1",
     "reflect-metadata": "0.2.2",
@@ -213,7 +213,7 @@
     "oxfmt": "0.73.0",
     "oxlint": "1.88.0",
     "rimraf": "6.1.3",
-    "smtp-server": "3.19.23",
+    "smtp-server": "3.21.1",
     "ts-node": "10.9.2",
     "tsconfig-paths": "4.2.0",
     "tsx": "4.23.15",

package/src/core/common/services/core-tenant-context.registry.ts

@@ -28,6 +28,18 @@ export interface TenantContextResolver {
    *   validated against an active membership before it is returned
    */
   resolve(user: { id: string; roles?: string[] } | undefined, headerTenantId?: string): Promise<ResolvedTenantContext>;
+
+  /**
+   * The narrower answer `CoreTenantGuard` gives an `@Roles(S_EVERYONE)` route: a tenant only from an
+   * ACTIVE membership in the tenant the header names (in an active tenant) — no admin bypass, and no
+   * fallback to every membership when no tenant is named. For an HTTP route that authenticates its
+   * caller itself, after the guards ran without a user (the MCP endpoint and its OAuth access token),
+   * so that route scopes the request exactly as the guard would have.
+   *
+   * Optional because the interface is public. A caller finding it absent establishes no tenant, which
+   * leaves the plugin's safety net to refuse tenant-scoped reads.
+   */
+  resolveMembership?(user: { id: string; roles?: string[] }, headerTenantId?: string): Promise<ResolvedTenantContext>;
 }
 
 let resolver: TenantContextResolver | undefined;

package/src/core/modules/ai/README.md

@@ -619,6 +619,12 @@ them:
   so `mongooseTenantPlugin` filters by the tenant the guard validated. Without a tenant header there
   is no tenant scope on these routes and tenant-scoped reads are refused (403) — an AI client is
   never broader than its user, at worst narrower.
+  An **MCP OAuth access token** is accepted only by the MCP controller, after the guards ran without a
+  user. Since 11.43.3 the controller gives such a request what the guard gives a user it saw: the user
+  on the request (so `RequestContext.currentUser`, the audit fields and `mongooseRoleGuardPlugin` see
+  it), and the tenant the header names — only when the user is an ACTIVE member of it, through the
+  guard's own check (`CoreTenantGuard.resolveMembershipContext()`). Before, every tenant-scoped tool
+  answered "Tenant context required" to an OAuth client, even for a member.
 - **Service-level rules** apply on every entry point when the service enforces them itself —
   `assertTenantRole()` (see the tenant module README) — instead of relying on a controller's
   `@Roles()`, which a tool calling the service never passes through.

package/src/core/modules/ai/core-ai-mcp.controller.ts

@@ -7,6 +7,7 @@ import { Roles } from '../../common/decorators/roles.decorator';
 import { RoleEnum } from '../../common/enums/role.enum';
 import { ConfigService } from '../../common/services/config.service';
 import { CoreRedisService } from '../../common/services/core-redis.service';
+import { getTenantContextResolver } from '../../common/services/core-tenant-context.registry';
 import { CoreBetterAuthModule } from '../better-auth/core-better-auth.module';
 import { ErrorCode } from '../error-code/error-codes';
 import { getMountedMcpOAuth } from './helpers/ai-mcp-oauth.registry';
@@ -36,7 +37,9 @@ import { AiToolUser } from './tools/ai-tool.registry';
  *
  * When `ai.mcp.oauth` is enabled, the handler additionally accepts OAuth 2.1 access
  * tokens (endpoints mounted by `CoreAiMcpOAuthInitializer`); otherwise it authenticates via
- * Bearer/session token.
+ * Bearer/session token. A user resolved here rather than by the guards — the OAuth token always —
+ * gets the request scope the guards would have given it (`req.user`, and a tenant from an active
+ * membership in the tenant the header names): see {@link CoreAiMcpController.scopeLateResolvedUser}.
  *
  * ## Multi-replica
  *
@@ -121,7 +124,7 @@ export class CoreAiMcpController implements OnModuleDestroy {
   })
   @Post()
   async handlePost(@Req() req: Request, @Res() res: Response): Promise<void> {
-    const user = await this.resolveUser(req);
+    const user = await this.resolveScopedUser(req);
     if (!user?.id) {
       this.unauthorized(res);
       return;
@@ -274,6 +277,59 @@ export class CoreAiMcpController implements OnModuleDestroy {
     return null;
   }
 
+  /**
+   * {@link resolveUser}, plus — for a user resolved HERE rather than seen by the guards — the request
+   * scope the guards give a user they saw (see {@link scopeLateResolvedUser}).
+   *
+   * Whether the guards saw the user is read BEFORE `resolveUser()` runs, so an override of it that sets
+   * `req.user` itself still counts as resolved late.
+   */
+  protected async resolveScopedUser(req: Request): Promise<any | null> {
+    const seenByGuards = !!(req as any).user?.id;
+    const user = await this.resolveUser(req);
+    if (user?.id && !seenByGuards) {
+      await this.scopeLateResolvedUser(req, user);
+    }
+    return user;
+  }
+
+  /**
+   * Give a request whose user this controller resolved itself what the guards give a request whose
+   * user they saw: the user on the request, and a tenant from an active membership only.
+   *
+   * The guards run before this controller, and an MCP OAuth access token is accepted by nothing else
+   * — so `CoreTenantGuard` found no `request.user` and never turned the tenant header into a context.
+   * In 11.43.2 and earlier that left two things behind:
+   * - **No tenant scope.** Every tenant-scoped tool answered "Tenant context required", even with a
+   *   tenant header naming a tenant the user is an active member of. Fail-closed, but unusable.
+   * - **No current user in `RequestContext`**, which reads `req.user` lazily. The Mongoose plugins read
+   *   that as SYSTEM work: no `createdBy` / `updatedBy`, `mongooseRoleGuardPlugin` let a tool's write
+   *   change roles, and `assertTenantRole()` refused the call as anonymous.
+   *
+   * The tenant comes from `CoreTenantGuard.resolveMembershipContext()`, the same decision its
+   * `@Roles(S_EVERYONE)` branch makes for a user it saw — so an OAuth token, a session cookie and a
+   * Better-Auth JWT reach the same scope. The header alone never establishes one: a tenant the user is
+   * not an active member of yields none, and the plugin's safety net refuses the read.
+   */
+  protected async scopeLateResolvedUser(req: Request, user: { id: string; roles?: string[] }): Promise<void> {
+    (req as any).user = user;
+
+    const config = ConfigService.configFastButReadOnly?.multiTenancy;
+    if (!config || config.enabled === false || (req as any).tenantId) {
+      return;
+    }
+    const headerName = (config.headerName ?? 'x-tenant-id').toLowerCase();
+    const header = req.headers?.[headerName];
+    const resolved = await getTenantContextResolver()?.resolveMembership?.(
+      user,
+      typeof header === 'string' ? header : undefined,
+    );
+    if (resolved?.tenantId) {
+      (req as any).tenantId = resolved.tenantId;
+      (req as any).tenantRole = resolved.tenantRole;
+    }
+  }
+
   /**
    * Whether the body is an `initialize` — the one request that legitimately starts a session.
    *
@@ -298,7 +354,7 @@ export class CoreAiMcpController implements OnModuleDestroy {
    * Forward a GET (SSE stream) or DELETE (close) to the session's transport.
    */
   private async handleSessionRequest(req: Request, res: Response): Promise<void> {
-    const user = await this.resolveUser(req);
+    const user = await this.resolveScopedUser(req);
     if (!user?.id) {
       this.unauthorized(res);
       return;

package/src/core/modules/auth/guards/legacy-auth-rate-limit.guard.ts

@@ -76,9 +76,10 @@ export class LegacyAuthRateLimitGuard implements CanActivate {
     const request = context.switchToHttp().getRequest();
     const ip = this.getClientIp(request);
 
-    // Get endpoint from URL path
-    const url = request.url || request.path || '';
-    const endpoint = url.split('/').pop() || 'unknown';
+    // The handler, never the URL: the URL carries the query string and the client's spelling of the path
+    // (Express routes case-insensitively and ignores a trailing slash), so every variant was a fresh bucket and
+    // `/auth/signin?n=1`, `?n=2`, … guessed passwords without ever reaching the limit.
+    const endpoint = context.getHandler()?.name || 'unknown';
 
     return { endpoint, ip };
   }

package/src/core/modules/auth/services/core-auth.service.ts

@@ -130,16 +130,30 @@ export class CoreAuthService {
       throw new UnauthorizedException(ErrorCode.INVALID_TOKEN);
     }
 
+    // A device is ended by writing `null` for it, not by deleting its key: update() MERGES the input into the stored
+    // record, so a key that is merely missing from the input survives — and with it the refresh token this logout
+    // must end. `validateUser()` reads a `null` device as "not signed in".
+    const ended = (deviceIds: string[]) => Object.fromEntries(deviceIds.map((id) => [id, null]));
+
     // Logout from all devices
     if (serviceOptions.allDevices) {
+      const deviceIds = Object.keys(user.refreshTokens);
       user.refreshTokens = {};
-      await this.userService.update(user.id, { refreshTokens: {} }, serviceOptions);
+      await this.userService.update(
+        user.id,
+        { refreshTokens: ended(deviceIds), tempTokens: ended(Object.keys(user.tempTokens ?? {})) },
+        serviceOptions,
+      );
       return true;
     }
 
     // Logout from specific devices
     delete user.refreshTokens[deviceId];
-    await this.userService.update(user.id, { refreshTokens: user.refreshTokens }, serviceOptions);
+    await this.userService.update(
+      user.id,
+      { refreshTokens: ended([deviceId]), tempTokens: ended([deviceId]) },
+      serviceOptions,
+    );
     return true;
   }
 

package/src/core/modules/tenant/core-tenant.guard.ts

@@ -181,6 +181,7 @@ export class CoreTenantGuard implements CanActivate, OnApplicationBootstrap, OnM
     // GraphQL WebSocket. See core-tenant-context.registry.ts for why this is a registry and not DI.
     setTenantContextResolver({
       resolve: (user, headerTenantId) => this.resolveTenantContext(user, headerTenantId),
+      resolveMembership: (user, headerTenantId) => this.resolveMembershipContext(user, headerTenantId),
     });
 
     // Lets the role guards delegate non-system roles to this guard — only while it exists.
@@ -248,6 +249,39 @@ export class CoreTenantGuard implements CanActivate, OnApplicationBootstrap, OnM
     return { tenantIds: carrier.tenantIds ?? [] };
   }
 
+  /**
+   * The tenant context `canActivate()` gives an `@Roles(S_EVERYONE)` route, for a caller it could not
+   * see: a route that authenticates its caller ITSELF, after the guards ran without a user.
+   *
+   * That is the MCP endpoint with an MCP OAuth access token — a credential nothing but its controller
+   * accepts, so the guard found no `request.user`, never checked the tenant header against a
+   * membership, and every tenant-scoped tool answered "Tenant context required" to a member of that
+   * very tenant. Answering through the same {@link memberTenantContext} as the guard's own branch is
+   * what keeps the result independent of which credential the caller used.
+   *
+   * Narrower than {@link resolveTenantContext} on purpose: that one answers for a transport whose every
+   * operation needs a scope (no admin bypass here, no list of all memberships without a header).
+   */
+  async resolveMembershipContext(
+    user: { id: string; roles?: string[] } | undefined,
+    headerTenantId?: string,
+  ): Promise<ResolvedTenantContext> {
+    const config = ConfigService.configFastButReadOnly?.multiTenancy;
+    if (!config || config.enabled === false) {
+      return {};
+    }
+    this.syncConfig(config);
+
+    const tenantId =
+      headerTenantId && typeof headerTenantId === 'string' && headerTenantId.length <= 128
+        ? headerTenantId.trim()
+        : undefined;
+    if (!tenantId || !user?.id) {
+      return {};
+    }
+    return (await this.memberTenantContext(user, tenantId)) ?? {};
+  }
+
   /**
    * Subscribe to the cross-replica cache invalidation channel.
    *
@@ -414,10 +448,10 @@ export class CoreTenantGuard implements CanActivate, OnApplicationBootstrap, OnM
       // Optionally enrich with tenant context when header is present and user is an active member.
       // Never block access — S_EVERYONE endpoints are always public.
       if (headerTenantId && request.user?.id) {
-        const membership = await this.findMembershipCached(request.user.id, headerTenantId);
-        if (membership && (await this.isTenantActive(headerTenantId))) {
-          request.tenantId = headerTenantId;
-          request.tenantRole = capApiTokenTenantRole(request.user, membership.role as string) ?? undefined;
+        const member = await this.memberTenantContext(request.user, headerTenantId);
+        if (member) {
+          request.tenantId = member.tenantId;
+          request.tenantRole = member.tenantRole;
         }
       }
       return true;
@@ -901,6 +935,22 @@ export class CoreTenantGuard implements CanActivate, OnApplicationBootstrap, OnM
     return active;
   }
 
+  /**
+   * The context an ACTIVE membership in an active tenant establishes, or undefined. Never the header
+   * alone: a freely chosen tenant id only becomes a scope once it names one of the caller's own tenants.
+   * Shared by the `S_EVERYONE` branch of `canActivate()` and {@link resolveMembershipContext}.
+   */
+  private async memberTenantContext(
+    user: { id: string; roles?: string[] },
+    tenantId: string,
+  ): Promise<{ tenantId: string; tenantRole?: string } | undefined> {
+    const membership = await this.findMembershipCached(user.id, tenantId);
+    if (!membership || !(await this.isTenantActive(tenantId))) {
+      return undefined;
+    }
+    return { tenantId, tenantRole: capApiTokenTenantRole(user, membership.role as string) ?? undefined };
+  }
+
   /** 403 for a deactivated tenant. */
   private async assertTenantActive(tenantId: string): Promise<void> {
     if (!(await this.isTenantActive(tenantId))) {