Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Multiple authorization vulnerabilities in Unleash admin API, including a critical missing await that completely bypasses a permission check. Vulnerability 1: Missing await on Permission Check (HIGH) File: src/lib/features/segment/segment-controller.ts (line 345) POST /api/admin/segments/strategies has permission: NONE at the route level. The handler performs its own check via this.accessService.hasPermission(), but omits the await keyword. Since hasPermission() is async (returns Promise<boolean), the variable always receives a truthy Promise object. The if (!hasFeatureStrategyPermission) check never triggers. Impact: Any authenticated user can modify segment assignments on ANY strategy across ALL projects. Fix: Add await: const hasFeatureStrategyPermission = await this.accessService.hasPermission(...) Vulnerability 2: Cross-Project Variant Read (MEDIUM) File: src/lib/routes/admin-api/project/variants.ts (line 213-223) GET…
Recommended action: Upgrade to 8.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unleash scopes write permissions per project and per environment: a user with the UPDATEFEATURESTRATEGY permission on project A is supposed to be able to mutate activation strategies only within project A. The endpoint POST /api/admin/projects/:projectId/features/:featureName/environments/:environment/strategies/set-sort-order violates this. The RBAC middleware authorizes the request against the :projectId taken from the URL, but the handler then writes the strategy IDs supplied in the request body directly to the database by primary key, without ever verifying that those strategy IDs actually belong to the URL's project / feature / environment. A low-privilege member of any one project can therefore reorder the activation strategies of features in any other project and environment — including projects they have no role on at all — by putting their own project in the URL (to satisfy RBAC) and the victim project's strategy IDs in the body. The sibling write paths in the same…
Recommended action: Upgrade to 8.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The clone-feature endpoint supports copying features across projects, but it does not verify that the caller can access the source project. A user with create permissions in one project can clone a feature from another project they cannot read and then inspect the copied configuration. This vulnerability cannot be confirmed without Enterprise access. Report is based on a circumstantial evidence in the open-source repository. Details src/lib/features/feature-toggle/feature-toggle-service.ts implements cloneFeatureToggle. This operation needs authorization for both sides: permission to read/copy the source feature and permission to create the destination feature. The clone path validates permissions against the destination project, but not against the source project that owns featureName. Because feature names are globally unique, a caller can reference a feature outside projects they can access. PoC 1. Create or identify two projects: P1 with a private or restricted feature…
Recommended action: Upgrade to 8.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The change-request approval HTML email template renders fields as raw HTML. User who can create a change request can inject HTML into approval notification emails. I was not able to confirm Enterprise platform is using vulnerable code nor that it doesn't sanitize input. Details src/mailtemplates/requested-cr-approval/requested-cr-approval.html.mustache uses Mustache triple-stash syntax for fields that can originate from users: Triple-stash disables HTML escaping even when Mustache's global escape function is safe. The related renderer is sendRequestedCRApprovalEmail in src/lib/services/email-service.ts, which renders the template with Mustache.render. PoC 1. Use an Enterprise deployment with change requests and approval emails enabled. 2. As a project member who can create change requests, set a display name or change-request title to HTML such as: 3. Create a change request that requires approval. 4. Observe that the approval email contains attacker-controlled raw HTML…
Recommended action: Upgrade to 8.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Details File: src/lib/addons/feature-event-formatter-md.ts Line: 355 (in v8.0.1; format() method) Root Cause FeatureEventFormatterMd.format() does: mustache (pinned ^4.2.0, confirmed installed 4.2.0) keeps escape as a module-level singleton (mustache.js: mustache.escape = escapeHtml;), read by every Mustache.render() call in the process unless a per-call config.escape override is passed (var escape = this.getConfigEscape(config) || mustache.escape;). Node's module cache guarantees every import Mustache from 'mustache' in the process — feature-event-formatter-md.ts, email-service.ts, webhook.ts, datadog.ts, new-relic.ts — shares the same object instance. This assignment therefore permanently disables HTML escaping for every other Mustache.render() call in the same Node process (including email-service.ts templates) from the moment any single notification addon (Webhook, Slack legacy, Microsoft Teams, Datadog, New Relic) first formats any event, for the remaining lifetime…
Recommended action: Upgrade to 8.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unleash's addon/integration subsystem lets an operator configure a webhook (and the Slack, Microsoft Teams, Datadog, and New Relic integrations) with a target url parameter. Whenever a subscribed feature-flag event fires, the Unleash server itself issues an HTTP request to that configured URL. The URL is taken verbatim from the addon's parameters.url and passed straight to the HTTP client (ky) with no validation of the host: there is no allow-list, no deny-list, and no blocking of loopback, link-local, RFC1918, or cloud-metadata addresses anywhere in the addon code path. A principal able to create or update an addon can therefore point the server at an internal-only URL — for example http://169.254.169.254/latest/meta-data/… (cloud IMDS), http://127.0.0.1:<port/… (a service bound to localhost), or any RFC1918 host — and cause the Unleash server to dial it from inside the trust boundary. The request is blind (the response body is not returned to the caller), but the addon…
Recommended action: Upgrade to 8.0.2, 7.6.5 or 7.5.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated POST to any OpenAPI-validated endpoint, including the anonymous POST /edge/validate and POST /edge/issue-token, crashes the entire Unleash server with one request body of deeply-nested JSON. When request-body validation fails, Unleash builds the error message by calling JSON.stringify on the raw offending value taken from the request body. A value nested a few thousand levels deep makes JSON.stringify recurse past the V8 call-stack limit and throw RangeError: Maximum call stack size exceeded. The throw is synchronous inside an Express error-handling middleware that has no try/catch, and the process registers no uncaughtException handler (only unhandledRejection). Node terminates the process with exit(1). The body parser sets no JSON nesting-depth limit, the payload (about 10 KB at depth 5000) stays far under the 100 KB body-size limit, and the same error formatter serves every API route, so the trigger is route-independent. Result: a remote attacker with no…
Recommended action: Upgrade to 8.0.2, 7.6.5 or 7.5.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.