@frontmcp/skills 1.7.1 → 1.7.2

package/catalog/frontmcp-config/references/configure-auth-modes.md

@@ -67,7 +67,7 @@ Local mode also accepts `allowDefaultPublic` (default `false` — set `true` to
 
 > **Public origin (security):** pin `FRONTMCP_PUBLIC_URL` in production. The issuer / resource / OAuth-discovery URLs and the transparent expected audience derive from it rather than from request headers; `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored unless `FRONTMCP_TRUST_PROXY=1` (a trusted proxy that strips client-supplied forwarded headers).
 
-**Progressive / incremental authorization** (opt-in via `incrementalAuth`): when enabled, the minted token carries an `authorized_apps` claim and a `tools/call` for an app NOT in that claim resolves to a `CallToolResult` with `isError: true` and `_meta.code === 'AUTHORIZATION_REQUIRED'` (fields: `authorization_required: true`, `app`, `tool`, `auth_url`, `required_scopes`, `session_mode`, `supports_incremental`). The client declares the initial grant on `/oauth/authorize?…&apps=crm` (omit `apps` to grant all apps) and expands it later via an incremental authorize `…&mode=incremental&app=slack&apps=crm` — the new token's claim is the **union** of the prior apps plus the target (the user identity and already-granted apps are preserved; upstream tokens stay server-side). Without an `incrementalAuth` block, no claim is minted and there is **no** app-level gating (allow-all preserved). `consent` (tool-level) and `incrementalAuth` (app-level) are independent.
+**Progressive / incremental authorization** (opt-in via `incrementalAuth`): when enabled, the minted token carries an `authorized_apps` claim and a `tools/call` for an app NOT in that claim resolves to a `CallToolResult` with `isError: true` and `_meta.code === 'AUTHORIZATION_REQUIRED'` (fields: `authorization_required: true`, `app`, `tool`, `auth_url`, `required_scopes`, `session_mode`, `supports_incremental`). The client declares the initial grant on `/oauth/authorize?…&apps=crm` (omit `apps` to grant all apps) and expands it later by **following the `auth_url` from the failed call** — that URL carries a framework-signed, single-use `ticket` naming the target app and the prior grant, and the new token's claim is the **union** of the prior apps plus the target (the user identity and already-granted apps are preserved; upstream tokens stay server-side). Do NOT hand-assemble `…&mode=incremental&app=slack`: since 1.7.2 (GHSA-2c4g-9c8x-6m8g) an authorize without a valid ticket is an ordinary login and runs the full credential gate, and `/oauth/callback` ignores an `incremental=true` parameter entirely. Without an `incrementalAuth` block, no claim is minted and there is **no** app-level gating (allow-all preserved). `consent` (tool-level) and `incrementalAuth` (app-level) are independent.
 
 To collect and verify your own credentials, add a declarative `login` (custom page fields / title / subject strategy) and an `authenticate(input, ctx)` verifier that returns `{ ok: true, sub?, claims? }` (custom claims are embedded in the token; reserved claims are stripped) or `{ ok: false, message }` (re-renders the login page; no code issued). Both are optional and default to the built-in email login. See `configure-auth.md` for a full example.
 

package/catalog/frontmcp-config/references/configure-http.md

@@ -116,6 +116,50 @@ ENV FRONTMCP_BIND_ADDRESS=all
 EXPOSE 3000
 ```
 
+## DNS Rebinding Protection
+
+**On by default since v1.7.2** (BC-035, GHSA-mc9g-v2cp-vfff). The server validates `Host`,
+`X-Forwarded-Host` and `Origin` before routing and before reading the body; a request naming a host
+this server does not answer to gets `403`. This covers the MCP endpoint, the OAuth routes, the SSE
+transport and any custom route.
+
+Binding loopback does **not** protect against this: a DNS rebinding attack points an
+attacker-controlled domain at `127.0.0.1`, so loopback is the destination. CORS does not either —
+after the rebind the browser genuinely considers the request same-origin. Validating `Host` is the
+server-side defence.
+
+With no `allowedHosts` configured, the list is derived from what the process listens on: `localhost`,
+`127.0.0.1` and `[::1]`, each with and without the bound port, plus a specific bound NIC address.
+Matching is case-insensitive and treats `host` and `host:80`/`host:443` as equal.
+
+**Deployments behind a proxy need one line of config.** A routable bind (`0.0.0.0`, `::`, a specific
+NIC) is reached under a hostname the process cannot know, so a derived list is not enforced there —
+FrontMCP logs a warning and leaves host checking off rather than 403-ing a proxied deployment on a
+patch upgrade. Name the public host to turn it on:
+
+```typescript
+http: {
+  security: {
+    dnsRebindingProtection: {
+      allowedHosts: ['api.example.com', 'api.example.com:8443'],
+      allowedOrigins: ['https://app.example.com'],
+    },
+  },
+}
+```
+
+Or via the environment, which pairs with `FRONTMCP_BIND_ADDRESS` in a container:
+
+```dockerfile
+ENV FRONTMCP_BIND_ADDRESS=all
+ENV FRONTMCP_ALLOWED_HOSTS=api.example.com,api.example.com:8443
+```
+
+To turn it off entirely: `dnsRebindingProtection: { enabled: false }`.
+
+A request with **no** `Origin` header is allowed through — non-browser clients never send one, and a
+rebound page always does. Rejecting the absent case breaks every CLI client and adds nothing.
+
 ## CORS Configuration
 
 ### No CORS Headers (Default)

package/catalog/frontmcp-config/references/configure-transport.md

@@ -45,7 +45,7 @@ Configure how clients connect to your FrontMCP server — SSE, Streamable HTTP,
     distributedMode: 'auto', // boolean | 'auto'
     eventStore: {
       enabled: true,
-      provider: 'redis', // 'memory' | 'redis'
+      provider: 'redis', // 'memory' | 'redis' | 'sqlite'
       maxEvents: 10000,
       ttlMs: 300000,
     },
@@ -115,7 +115,7 @@ Enable event store so clients can resume SSE connections after disconnects:
 transport: {
   eventStore: {
     enabled: true,
-    provider: 'redis',       // 'memory' for single instance, 'redis' for distributed
+    provider: 'redis',       // 'memory' | 'redis' | 'sqlite'
     maxEvents: 10000,        // max events to store
     ttlMs: 300000,           // 5 minute TTL
     redis: { provider: 'redis', host: 'localhost' },
@@ -123,6 +123,12 @@ transport: {
 }
 ```
 
+**Auto-enabled in distributed mode.** A distributed deployment with Redis configured turns the event store on without an explicit `eventStore` block, so the notes below apply there too.
+
+**Requires 1.7.2 or later.** Before 1.7.2 (GHSA-84j6-jc92-77jm) one store instance was shared by every session with no ownership check on replay, and the upstream transport writes every session's standalone SSE stream under the constant id `_GET_stream` with sequential event numbers — so a client sending `Last-Event-ID: _GET_stream:1` was replayed other sessions' server-to-client messages (tool results, resource contents, notifications). On 1.7.1 or earlier, do not enable the event store on a multi-tenant deployment.
+
+From 1.7.2 each session gets a view over the shared store scoped to its own session id: an event id belonging to another session replays nothing.
+
 ## Target-Specific Recommendations
 
 | Target                   | Recommended Preset | Persistence | Event Store |

package/catalog/frontmcp-development/examples/create-job/job-with-permissions.md

@@ -112,6 +112,8 @@ class DataServer {}
 ## What This Demonstrates
 
 - Declarative `permissions` as an array of `{ action, roles, scopes, custom }` rules
+  (**enforced from 1.7.2 onward** — see GHSA-58v2-gpcc-jmqv; earlier versions
+  stored the rules without evaluating them)
 - Using `tags` and `labels` for categorization and filtering
 - The `job()` function builder for simple jobs that need no class
 - Full server registration with `jobs.enabled: true` and a Redis store

package/catalog/frontmcp-development/references/create-job.md

@@ -35,17 +35,17 @@ Create a class extending `JobContext<In, Out>` and implement the `execute(input:
 
 ### JobMetadata Fields
 
-| Field          | Type                     | Required | Default          | Description                                |
-| -------------- | ------------------------ | -------- | ---------------- | ------------------------------------------ |
-| `name`         | `string`                 | Yes      | --               | Unique job name                            |
-| `inputSchema`  | `ZodRawShape`            | Yes      | --               | Zod raw shape for input validation         |
-| `outputSchema` | `ZodRawShape \| ZodType` | Yes      | --               | Zod schema for output validation           |
-| `description`  | `string`                 | No       | --               | Human-readable description                 |
-| `timeout`      | `number`                 | No       | `300000` (5 min) | Maximum execution time in milliseconds     |
-| `retry`        | `RetryPolicy`            | No       | --               | Retry configuration (see below)            |
-| `tags`         | `string[]`               | No       | --               | Categorization tags                        |
-| `labels`       | `Record<string, string>` | No       | --               | Key-value labels for filtering             |
-| `permissions`  | `JobPermission[]`        | No       | --               | Array of permission rules (one per action) |
+| Field          | Type                     | Required | Default          | Description                                                                                        |
+| -------------- | ------------------------ | -------- | ---------------- | -------------------------------------------------------------------------------------------------- |
+| `name`         | `string`                 | Yes      | --               | Unique job name                                                                                    |
+| `inputSchema`  | `ZodRawShape`            | Yes      | --               | Zod raw shape for input validation                                                                 |
+| `outputSchema` | `ZodRawShape \| ZodType` | Yes      | --               | Zod schema for output validation                                                                   |
+| `description`  | `string`                 | No       | --               | Human-readable description                                                                         |
+| `timeout`      | `number`                 | No       | `300000` (5 min) | Maximum execution time in milliseconds                                                             |
+| `retry`        | `RetryPolicy`            | No       | --               | Retry configuration (see below)                                                                    |
+| `tags`         | `string[]`               | No       | --               | Categorization tags                                                                                |
+| `labels`       | `Record<string, string>` | No       | --               | Key-value labels for filtering                                                                     |
+| `permissions`  | `JobPermission[]`        | No       | --               | Array of permission rules. Multiple rules may target the same action; all matching rules must pass |
 
 ### Basic Example
 
@@ -266,13 +266,17 @@ class ImportCsvJob extends JobContext {
 
 Control who can interact with jobs using the `permissions` field. **`permissions` is an array** of rules; each rule grants access to a single `action` and lists the roles, scopes, and/or custom predicate required for that action.
 
+**Requires 1.7.2 or later.** Before 1.7.2 (GHSA-58v2-gpcc-jmqv) the `permissions` array was validated and stored but never evaluated — every job was reachable by every caller who could reach `execute_job`. On older versions do not rely on this field for access control.
+
+Semantics: no rules for an action means allow (the documented default); once any rule targets an action, **all** rules for that action must pass, and `roles`/`scopes` within a single rule are **any-of**. Enforcement happens in `JobExecutionManager`, so background runs and workflow steps are covered, and `list_jobs` hides entries the caller could not run. A denial is indistinguishable from "not found" so restricted job names cannot be enumerated.
+
 ### Permission Rule Shape
 
 ```typescript
 interface JobPermission {
   action: 'create' | 'read' | 'update' | 'delete' | 'execute' | 'list'; // singular!
-  roles?: string[]; // user must have one of these roles
-  scopes?: string[]; // token must include all of these scopes
+  roles?: string[]; // caller must have one of these roles
+  scopes?: string[]; // token must include one of these scopes
   custom?: (authInfo: Partial<Record<string, unknown>>) => boolean | Promise<boolean>;
 }
 ```
@@ -418,7 +422,7 @@ class DataApp {}
 
 ### Enabling the Jobs System
 
-**Auto-enable (issue #408):** declaring any `@App({ jobs: [...] })` (or `workflows: [...]`) is enough — the jobs subsystem comes up with in-memory stores by default and the management tools (`execute_job`, `list_jobs`, `get_job_status`, `register_job`, `remove_job`) are registered automatically so agents can invoke them. No `@FrontMcp({ jobs: { enabled: true } })` is required for the happy path.
+**Auto-enable (issue #408):** declaring any `@App({ jobs: [...] })` (or `workflows: [...]`) is enough — the jobs subsystem comes up with in-memory stores by default and the management tools (`execute_job`, `list_jobs`, `get_job_status`, `remove_job`) are registered automatically so agents can invoke them. `register_job` is added only when `jobs.allowDynamicRegistration` is `true`. No `@FrontMcp({ jobs: { enabled: true } })` is required for the happy path.
 
 **When to configure `@FrontMcp({ jobs })` explicitly:** override the in-memory default with persistent storage (Redis recommended for multi-replica HA) so job state, progress, logs, and outputs survive retries and server restarts.
 
@@ -450,17 +454,27 @@ Setting `jobs: { enabled: false }` is an explicit opt-out — declared jobs will
 
 Once jobs are registered, the SDK exposes five MCP tools (snake_case per ecosystem convention; hyphen aliases like `execute-job` keep working with a deprecation log line for one release):
 
-| Tool             | Purpose                                                                  |
-| ---------------- | ------------------------------------------------------------------------ |
-| `list_jobs`      | List registered jobs with optional `tags` / `labels` / `query` filters   |
-| `execute_job`    | Execute a registered job by name (`{ name, input?, background? }`)       |
-| `get_job_status` | Get the run state for a `runId` returned by `execute_job`                |
-| `register_job`   | Register a dynamic job at runtime (sandboxed; `hideFromDiscovery: true`) |
-| `remove_job`     | Remove a dynamic job by name (`hideFromDiscovery: true`)                 |
+| Tool             | Purpose                                                                |
+| ---------------- | ---------------------------------------------------------------------- |
+| `list_jobs`      | List registered jobs with optional `tags` / `labels` / `query` filters |
+| `execute_job`    | Execute a registered job by name (`{ name, input?, background? }`)     |
+| `get_job_status` | Get the run state for a `runId` returned by `execute_job`              |
+| `register_job`   | Register a dynamic job at runtime — **opt-in**, see below              |
+| `remove_job`     | Remove a dynamic job by name (`hideFromDiscovery: true`)               |
 
 Workflows expose a parallel set: `list_workflows`, `execute_workflow`, `get_workflow_status`, `register_workflow`, `remove_workflow`.
 
-For finer-grained control (e.g. omit `register_job` / `remove_job` in production), opt out of auto-registration by importing the tool classes manually:
+`register_job` / `register_workflow` take a **raw script string** and register it as an executable job. Since 1.7.2 they are not registered unless you opt in:
+
+```typescript
+@FrontMcp({ jobs: { enabled: true, allowDynamicRegistration: true } })
+```
+
+Leave it off unless an agent is genuinely meant to author jobs — with it on, any caller who reaches the tool list can author and run code on the server.
+
+`get_job_status` / `get_workflow_status` return only runs started by the calling subject; a run record carries the job's inputs and results, so a foreign `runId` reads as "not found".
+
+For finer-grained control, opt out of auto-registration by importing the tool classes manually:
 
 ```typescript
 import { App, ExecuteJobTool, GetJobStatusTool, ListJobsTool } from '@frontmcp/sdk';

package/catalog/frontmcp-development/references/create-workflow.md

@@ -35,16 +35,16 @@ Create a class decorated with `@Workflow`. The decorator requires `name` and `st
 
 ### WorkflowMetadata Fields
 
-| Field            | Type                               | Required    | Default           | Description                                           |
-| ---------------- | ---------------------------------- | ----------- | ----------------- | ----------------------------------------------------- |
-| `name`           | `string`                           | Yes         | --                | Unique workflow name                                  |
-| `steps`          | `WorkflowStep[]`                   | Yes (min 1) | --                | Array of step definitions                             |
-| `description`    | `string`                           | No          | --                | Human-readable description                            |
-| `trigger`        | `'manual' \| 'webhook' \| 'event'` | No          | `'manual'`        | How the workflow is initiated                         |
-| `webhook`        | `WebhookConfig`                    | No          | --                | Webhook configuration (when trigger is `'webhook'`)   |
-| `timeout`        | `number`                           | No          | `600000` (10 min) | Maximum total workflow execution time in milliseconds |
-| `maxConcurrency` | `number`                           | No          | `5`               | Maximum number of steps running in parallel           |
-| `permissions`    | `WorkflowPermission[]`             | No          | --                | Array of permission rules (one per action)            |
+| Field            | Type                               | Required    | Default           | Description                                                                                                                                                                                    |
+| ---------------- | ---------------------------------- | ----------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `name`           | `string`                           | Yes         | --                | Unique workflow name                                                                                                                                                                           |
+| `steps`          | `WorkflowStep[]`                   | Yes (min 1) | --                | Array of step definitions                                                                                                                                                                      |
+| `description`    | `string`                           | No          | --                | Human-readable description                                                                                                                                                                     |
+| `trigger`        | `'manual' \| 'webhook' \| 'event'` | No          | `'manual'`        | How the workflow is initiated                                                                                                                                                                  |
+| `webhook`        | `WebhookConfig`                    | No          | --                | Webhook configuration (when trigger is `'webhook'`)                                                                                                                                            |
+| `timeout`        | `number`                           | No          | `600000` (10 min) | Maximum total workflow execution time in milliseconds                                                                                                                                          |
+| `maxConcurrency` | `number`                           | No          | `5`               | Maximum number of steps running in parallel                                                                                                                                                    |
+| `permissions`    | `JobPermission[]`                  | No          | --                | Array of permission rules. Multiple rules may target the same action; all matching rules must pass. Same shape and semantics as job permissions; **enforced from 1.7.2** (GHSA-58v2-gpcc-jmqv) |
 
 ### WorkflowStep Fields
 

package/catalog/frontmcp-development/references/official-plugins.md

@@ -662,9 +662,23 @@ interface DashboardPluginOptionsInput {
 
 - `enabled` -- When omitted, the dashboard is automatically enabled in development (`NODE_ENV !== 'production'`) and disabled in production.
 - `basePath` -- URL path where the dashboard is served. Default: `'/dashboard'`.
-- `auth.token` -- When set, the dashboard requires `?token=<value>` as a query parameter.
+- `auth.enabled` / `auth.token` -- Gate the dashboard page on a shared secret. Present it as `Authorization: Bearer <token>` (preferred) or `?token=<value>`. `enabled: true` without a `token` is a **startup error** — the server refuses to boot rather than serve an "authenticated" dashboard with nothing to check. The token is compared in constant time and is never embedded in the served page.
 - `cdn` -- Override default CDN URLs for the dashboard UI bundle and its dependencies. Useful for air-gapped environments.
 
+### Security
+
+**Requires 1.7.2 or later.** Before 1.7.2 (GHSA-rgxj-434m-vxh3) `auth.token` was documented and validated but never checked, the operator's options never reached the middleware at all, and the dashboard's MCP scope declared `auth: { mode: 'public' }` unconditionally — so a dashboard configured with a secret still served its page, and `dashboard:graph` still returned the entire server's inventory, to anyone. On 1.7.1 or earlier, treat any server running `DashboardApp` as publicly introspectable.
+
+The dashboard's MCP scope **inherits the server's authentication**. Its introspection tools (`dashboard:graph`, `dashboard:list-tools`, `dashboard:list-resources`) reach the root scope and enumerate every app, tool, resource and prompt on the server — including names, descriptions and (on request) schemas. Two consequences:
+
+- On an authenticated server (`local`, `remote`, `transparent`, `orchestrated`), the dashboard requires the same credential as everything else.
+- On a **public** server the dashboard is public too, because the server is. `auth.token` gates the dashboard _page_, not the MCP scope or the SSE stream. If the inventory is sensitive, authenticate the server — do not rely on the dashboard token alone.
+
+Two further limitations worth knowing:
+
+- The token is accepted as `Authorization: Bearer <token>` or `?token=`. Prefer the header: a URL token lands in browser history, `Referer` headers and access logs. There is no cookie/session option yet.
+- Dashboard options are **process-wide**. Two `@FrontMcp` servers built in one process that configure the dashboard differently share the last configuration registered, including its token; the plugin logs a warning when that happens. Run one dashboard per process.
+
 ---
 
 ## Registration Pattern

package/catalog/frontmcp-production-readiness/references/common-checklist.md

@@ -29,6 +29,15 @@ These checks apply to ALL deployment targets. Run them first, then proceed to yo
 - [ ] Credentials mode is only enabled if cookies/sessions are needed
 - [ ] Preflight cache (`maxAge`) is set to reduce OPTIONS requests
 
+### DNS Rebinding Protection
+
+- [ ] `security.dnsRebindingProtection.allowedHosts` (or `FRONTMCP_ALLOWED_HOSTS`) names the public
+      hostname(s) — on a routable bind the derived default is **not** enforced, and FrontMCP logs a
+      warning saying so
+- [ ] Startup logs show no `DNS-rebinding protection is not enforcing a Host allow-list` warning
+- [ ] Include the port when the public URL uses a non-default one (`api.example.com:8443`)
+- [ ] `allowedOrigins` is set when a browser client connects, so a foreign `Origin` is refused
+
 ### Input Validation
 
 - [ ] All tool inputs use Zod schemas (never trust raw input)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frontmcp/skills",
-  "version": "1.7.1",
+  "version": "1.7.2",
   "description": "Curated skills catalog for FrontMCP projects",
   "author": "AgentFront <info@agentfront.dev>",
   "homepage": "https://docs.agentfront.dev",