CVE-2026-76910 Overview
Unleash, an open-source feature management platform, contains an authorization flaw in its feature cloning functionality prior to version 8.0.3. The cloneFeatureToggle function and the POST /api/admin/projects/:projectId/features/:featureName/clone endpoint verify write access to the destination project but fail to check read access on the source project. Because feature names are globally unique across an Unleash instance, an authenticated user with clone or create permission in any project can copy a feature from another project they cannot access. The cloned feature exposes strategy parameters, constraints, variants, and variant payloads from the source project. This issue is tracked as [CWE-639: Authorization Bypass Through User-Controlled Key].
Critical Impact
Authenticated users can enumerate and disclose confidential feature flag configurations across project boundaries, breaking multi-tenant isolation in shared Unleash deployments.
Affected Products
- Unleash feature management platform, all versions prior to 8.0.3
- Self-hosted Unleash deployments with multiple projects and delegated permissions
- Unleash instances where users hold create or clone permissions in at least one project
Discovery Timeline
- 2026-09-22 - CVE-2026-76910 published to NVD
- 2026-09-23 - Last updated in NVD database
Technical Details for CVE-2026-76910
Vulnerability Analysis
Unleash organizes feature flags into projects that support per-project role-based access control. The clone endpoint accepts a source featureName and a destination projectId in the request path. The controller previously validated only that the caller could create features in the destination project. It did not validate that the caller had access to the project owning the source feature.
Feature names in Unleash are globally unique, which means a user aware of or able to guess a target feature name can request a clone regardless of project boundaries. The resulting duplicate carries the full strategy configuration of the original, including targeting constraints, variant weights, and JSON payloads that often contain business logic or environment identifiers.
Root Cause
The root cause is a missing cross-object authorization check in the validateFeatureBelongsToProject helper of the feature-toggle service. The pre-patch implementation only returned a NotFoundError when the project mismatch occurred, and the clone controller never invoked it before performing the copy. The service also disclosed the true owning project name in the error message, enabling reconnaissance of feature-to-project mappings.
Attack Vector
An authenticated user with clone or create permission in project A issues a POST to /api/admin/projects/A/features/target-feature/clone, where target-feature belongs to project B. The server clones the feature into project A and returns its strategies, constraints, variants, and payloads. Because the attack uses legitimate API paths and credentials, it produces no obvious authentication failure signals.
// Patch: enforce source-project ownership before cloning
// src/lib/features/feature-toggle/feature-toggle-controller.ts
): Promise<void> {
const { projectId, featureName } = req.params;
const { name, replaceGroupId } = req.body;
await this.featureService.validateFeatureBelongsToProject(
{ featureName, projectId },
false,
);
const created =
await this.transactionalFeatureToggleService.transactional(
(service) =>
// Source: https://github.com/Unleash/unleash/commit/2dc6ac0e8ba524ec7a2e9bc96a0e01d9d6f5a35a
// Patch: suppress cross-project disclosure in error messages
// src/lib/features/feature-toggle/feature-toggle-service.ts
async validateFeatureBelongsToProject(
{ featureName, projectId }: IFeatureContext,
exposeExistingFeature: boolean = true,
): Promise<void> {
const id = await this.featureToggleStore.getProjectId(featureName);
if (id !== projectId) {
throw new NotFoundError(
`There's no feature named "${featureName}" in project "${projectId}"${
id !== undefined && exposeExistingFeature
? `, but there's a feature with that name in project "${id}"`
: '.'
}`,
);
}
// Source: https://github.com/Unleash/unleash/commit/2dc6ac0e8ba524ec7a2e9bc96a0e01d9d6f5a35a
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-76910
Indicators of Compromise
- Successful POST requests to /api/admin/projects/:projectId/features/:featureName/clone where the acting user has no role in the source project
- Sudden appearance of duplicate features in a project whose names match features owned by other projects
- Audit-log feature-created events with clone metadata immediately following permission grants to low-privilege users
Detection Strategies
- Correlate Unleash audit-log entries for feature clone operations against the project membership table to flag cross-project source features
- Query the feature-toggle history for records where the created-in project differs from a same-named feature that existed earlier in a different project
- Baseline normal cloning volume per user and alert on spikes or clones performed by service accounts that do not typically use the endpoint
Monitoring Recommendations
- Forward Unleash admin API access logs and audit events into a centralized SIEM for retention and correlation
- Enable alerting on NotFoundError responses from validateFeatureBelongsToProject, which after patching indicate probing attempts
- Review role assignments periodically and monitor for users granted CREATE_FEATURE across many projects
How to Mitigate CVE-2026-76910
Immediate Actions Required
- Upgrade all Unleash instances to version 8.0.3 or later, which adds the missing validateFeatureBelongsToProject call in the clone controller
- Audit existing features for duplicates that may have been created through unauthorized cloning and remove or reassign them
- Rotate any secrets, environment identifiers, or tokens embedded in variant payloads that may have been disclosed
Patch Information
The fix is included in Unleash release v8.0.3 and the commit 2dc6ac0e8ba524ec7a2e9bc96a0e01d9d6f5a35a. The patch adds a source-project ownership check before cloning and suppresses cross-project disclosure in error messages. See the GitHub Security Advisory GHSA-8xcj-9hfr-fh9j for coordinated disclosure details.
Workarounds
- Restrict CREATE_FEATURE and clone permissions to trusted project administrators until the upgrade is deployed
- Place the Unleash admin API behind a reverse proxy that denies the /clone sub-path for non-administrative principals
- Avoid storing sensitive data such as API keys or PII in feature variant payloads to limit exposure from any future authorization gap
# Upgrade Unleash to the patched release
npm install unleash-server@8.0.3
# Or pin the container image
docker pull unleashorg/unleash-server:8.0.3
# Temporary reverse-proxy block for the vulnerable endpoint (nginx)
location ~ ^/api/admin/projects/[^/]+/features/[^/]+/clone$ {
deny all;
return 403;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

