Unleash: Missing await on permission check + cross-project IDOR in admin API

Unleash is an open-source feature management platform. Prior to 8.0.3, the Unleash admin API contains five authorization vulnerabilities. POST /api/admin/segments/strategies assigns the Promise returned by hasPermission without awaiting it, allowing authenticated users to modify segment assignments without UPDATE_FEATURE_STRATEGY permission for the target project and environment. GET /api/admin/projects/:projectId/features/:featureName/environments/:environment/variants does not bind the requested feature to projectId, allowing cross-project variant configuration disclosure. GET .../strategies/:strategyId uses strategyId without validating the project and feature context, allowing cross-project strategy configuration disclosure. getEnvironmentInfo does not validate that the requested feature belongs to the supplied project, allowing cross-project environment information disclosure. PUT /:projectId/tags accepts feature identifiers without verifying that they belong to the URL project, allowing cross-project tag modification. This issue is fixed in version 8.0.3.

Unleash is an open-source feature management platform. Prior to 8.0.3, the Unleash admin API contains five authorization vulnerabilities. POST /api/admin/segments/strategies assigns the Promise returned by hasPermission without awaiting it, allowing authenticated users to modify segment assignments without UPDATE_FEATURE_STRATEGY permission for the target project and environment. GET /api/admin/projects/:projectId/features/:featureName/environments/:environment/variants does not bind the requested feature to projectId, allowing cross-project variant configuration disclosure. GET .../strategies/:strategyId uses strategyId without validating the project and feature context, allowing cross-project strategy configuration disclosure. getEnvironmentInfo does not validate that the requested feature belongs to the supplied project, allowing cross-project environment information disclosure. PUT /:projectId/tags accepts feature identifiers without verifying that they belong to the URL project, allowing cross-project tag modification. This issue is fixed in version 8.0.3.

Unleash is an open-source feature management platform. Prior to 8.0.3, the Unleash admin API contains five authorization vulnerabilities. POST /api/admin/segments/strategies assigns the Promise returned by hasPermission without awaiting it, allowing authenticated users to modify segment assignments without UPDATE_FEATURE_STRATEGY permission for the target project and environment. GET /api/admin/projects/:projectId/features/:featureName/environments/:environment/variants does not bind the requested feature to projectId, allowing cross-project variant configuration disclosure. GET .../strategies/:strategyId uses strategyId without validating the project and feature context, allowing cross-project strategy configuration disclosure. getEnvironmentInfo does not validate that the requested feature belongs to the supplied project, allowing cross-project environment information disclosure. PUT /:projectId/tags accepts feature identifiers without verifying that they belong to the URL project, allowing cross-project tag modification. This issue is fixed in version 8.0.3.

## Summary 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. ```typescript // BUG: missing await - hasPermission() returns Promise<boolean> const hasFeatureStrategyPermission = this.accessService.hasPermission( req.user, UPDATE_FEATURE_STRATEGY, projectId, environmentId, ); if (!hasFeatureStrategyPermission) { // Always false - Promise is truthy! res.status(403).send(); return; } ``` **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 /api/admin/projects/:projectId/features/:featureName/environments/:environment/variants` completely ignores `projectId`. `getVariantsOnEnv()` only uses `featureName` and `environment`. **Impact:** Any authenticated user can read variant configs (names, weights, payloads) from any project. ## Vulnerability 3: Cross-Project Strategy Read (MEDIUM) **File:** `src/lib/features/feature-toggle/feature-toggle-controller.ts` (line 1107-1116) `GET .../strategies/:strategyId` ignores all params except `strategyId`. Any authenticated user can read any strategy's full configuration. ## Vulnerability 4: Cross-Project Environment Info Leak (MEDIUM) **File:** `src/lib/features/feature-toggle/feature-toggle-service.ts` (line 1611) `getEnvironmentInfo()` doesn't validate feature belongs to project. Compare with `getFeature()` which calls `validateFeatureBelongsToProject()`. ## Vulnerability 5: Cross-Project Tag Modification (LOW) **File:** `src/lib/features/feature-toggle/feature-toggle-controller.ts` (line 576-596) `PUT /:projectId/tags` accepts features array in body without validating they belong to projectId.