CVE-2026-76910 in Unleash
Summary
by MITRE • 09/22/2026
Unleash is an open-source feature management platform. Prior to 8.0.3, cloneFeatureToggle and POST /api/admin/projects/:projectId/features/:featureName/clone authorize creation in the destination project but do not verify access to the source project. Because feature names are globally unique, a user with create or clone permission in one project who knows or guesses another project's feature name can copy that feature into the authorized project and inspect its strategy parameters, constraints, variants, and variant payloads. This issue is fixed in version 8.0.3.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified within Unleash versions prior to 8.0.3 represents a critical authorization flaw rooted in improper access control mechanisms during the feature toggle cloning process. As an open-source feature management platform, Unleass serves as a central hub for managing application features, often containing sensitive configuration data such as strategy parameters, constraints, and variant payloads that dictate how specific functionalities behave across different environments or user segments. The core technical flaw lies in the implementation of two distinct endpoints: the cloneFeatureToggle function and the POST /api/admin/projects/:projectId/features/:featureName/clone endpoint. While these mechanisms correctly verify whether the requesting user possesses create or clone permissions within the destination project, they fail to perform a corresponding verification check against the source project from which the feature is being copied. This asymmetry in authorization logic creates a significant security gap that undermines the intended isolation between different projects within the platform.
The operational impact of this vulnerability allows for unauthorized data disclosure and potential configuration manipulation through an insecure direct object reference pattern. Because Unleash enforces global uniqueness on feature names, it becomes feasible for an attacker to enumerate or guess valid feature identifiers belonging to other projects. A user with legitimate access rights in a lower-privilege project can exploit the cloning mechanism by specifying the name of a sensitive feature from a higher-privilege or restricted source project. Upon successful execution, the system copies the entire configuration profile of that target feature into the attacker's authorized destination project. This action effectively bypasses the security boundaries established for the source project, allowing the attacker to inspect detailed internal configurations including strategy parameters which may reveal backend service endpoints, constraint definitions that might expose user segmentation logic, and variant payloads containing sensitive business rules or A/B testing data.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in verifying access rights for resources accessed by the client. The attack vector is consistent with ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials to perform actions outside their intended scope due to flawed authorization checks on specific objects. Furthermore, it exhibits characteristics of CWE-639 Authorization Bypass Through User-Controlled Key, as the feature name serves as a user-controlled key that is not adequately validated against access policies for its origin location. The ability to clone configurations also poses indirect risks related to integrity violations if an attacker were to modify cloned features and propagate them back or use the extracted logic to reverse-engineer application behavior.
Mitigation strategies must prioritize immediate version upgrades alongside robust configuration reviews. Organizations running Unleash versions prior to 8.0.3 should upgrade to version 8.0.3 or later, where this authorization check has been corrected to verify access permissions for both the source and destination projects before allowing a clone operation. In environments where upgrading is not immediately feasible, administrators can implement network-level controls such as Web Application Firewalls to restrict cloning endpoints based on strict IP allow-listing if those operations are only required from specific administrative interfaces. Additionally, auditing logs for unusual patterns of feature creation or cloning requests originating from users who do not typically interact with high-value projects can help in detecting potential exploitation attempts. Ensuring that the principle of least privilege is strictly enforced across all project levels and regularly reviewing access control lists will further reduce the attack surface associated with this type of authorization bypass vulnerability.