CVE-2026-77426 in Unleash
Summary
by MITRE • 09/22/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The Unleash platform serves as a critical infrastructure component for many organizations by managing feature flags and toggles across complex software deployments. A significant security deficiency was identified within the administrative API of versions prior to 8.0.3, characterized by five distinct authorization vulnerabilities that stem from improper validation of resource ownership and asynchronous execution errors. These flaws collectively undermine the principle of least privilege and allow authenticated users to bypass intended access controls, leading to unauthorized modifications and disclosures across different project boundaries. The root cause lies in a failure to properly enforce context binding between user requests and the specific resources they are attempting to access or modify.
One critical vulnerability involves the POST endpoint for managing segment strategies, specifically /api/admin/segments/strategies. In this instance, the application logic assigns the Promise returned by the hasPermission function without awaiting its resolution before proceeding with the operation. This asynchronous handling error means that the authorization check may not have completed or may return an undefined value when the subsequent write action is executed. Consequently, authenticated users can modify segment assignments even if they lack the required UPDATE_FEATURE_STRATEGY permission for the target project and environment. This flaw effectively bypasses access control mechanisms by decoupling the verification step from the enforcement step, allowing actions to proceed based on stale or null authorization states rather than definitive permissions.
Several other vulnerabilities in this release involve cross-project data disclosure due to insufficient validation of resource identifiers against their contextual owners. The GET endpoint for retrieving feature variants does not bind the requested feature identifier to the project ID provided in the URL path. This oversight allows an attacker who knows a valid feature name and environment configuration from one project to retrieve variant configurations belonging to entirely different projects, assuming they can guess or enumerate these identifiers. Similarly, the strategy retrieval endpoint uses the supplied strategyId without validating that it belongs to the specified project context. This lack of cross-reference checking enables unauthorized access to strategic configurations across organizational boundaries within the same Unleash instance.
Further exacerbating the disclosure risks is a flaw in the getEnvironmentInfo function, which fails to validate whether the requested feature actually belongs to the supplied project identifier. This allows attackers to extract sensitive environment information for features outside their authorized scope. Additionally, the PUT endpoint for updating tags accepts feature identifiers without verifying that those features are associated with the project ID present in the URL path. This enables cross-project tag modification, where a user can alter metadata or categorization of resources they do not own. These issues collectively represent a systemic failure to enforce proper object-level access controls, allowing lateral movement and data exfiltration within the feature management system.
From an industry standard perspective, these vulnerabilities align closely with CWE-284 Improper Access Control and CWE-367 Time-of-check Time-of-use (TOCTOU) race condition related to asynchronous operations. The cross-project disclosure issues also reflect aspects of CWE-1052 Missing Authorization for Critical Data. In terms of the MITRE ATT&CK framework, these flaws facilitate unauthorized access to sensitive data and can be leveraged during the Initial Access or Lateral Movement phases by allowing attackers to gather intelligence on other projects' configurations and features, potentially aiding in further exploitation attempts against connected systems.
The operational impact of these vulnerabilities is severe for organizations relying on Unleash for controlled feature rollouts. Unauthorized modification of segment strategies could lead to incorrect user targeting, causing bugs or unintended behaviors in production environments. Disclosure of variant configurations and environment information exposes internal development logic and A/B testing parameters to unauthorized parties, potentially revealing competitive intelligence or architectural details. The ability to modify tags across projects can disrupt organizational workflows that rely on accurate metadata for reporting and governance.
To mitigate these risks, organizations must immediately upgrade the Unleash platform to version 8.0.3 or later, where these authorization checks have been corrected. For environments unable to patch instantly, implementing a reverse proxy with strict access control policies may provide some mitigation by validating request contexts before they reach the application layer. However, relying on external controls is not a substitute for fixing the underlying code logic. Developers should also review other API endpoints in their custom integrations to ensure that all resource identifiers are validated against user permissions and project context consistently, particularly when dealing with asynchronous operations where race conditions might otherwise occur.