CVE-2026-77425 in Unleash
Summary
by MITRE • 09/23/2026
Unleash is an open-source feature management platform. Prior to 8.0.3, POST /api/admin/projects/:projectId/features/:featureName/environments/:environment/strategies/set-sort-order passes attacker-controlled strategy IDs to unprotectedUpdateStrategiesSortOrder and updateSortOrder without verifying that the IDs belong to the project, feature, and environment authorized by the URL. In a multi-project Pro or Enterprise deployment, an authenticated user with UPDATE_FEATURE_STRATEGY in one project who knows another project's strategy IDs can reorder those strategies, changing feature evaluation precedence while the operation is attributed to the attacker's URL context rather than the affected project. The single-project OSS edition lacks the cross-project dimension, although the missing context binding still permits unauthorized reordering across features or environments in the default project. The endpoint changes only sort_order and does not modify strategy parameters, constraints, or segments. This issue is fixed in version 8.0.3.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in Unleash prior to version 8.0.3 represents a critical failure in object-level access control within the application's API layer. Specifically, the endpoint POST /api/admin/projects/:projectId/features/:featureName/environments/:environment/strategies/set-sort-order fails to validate that the strategy identifiers provided by the client actually belong to the specific project, feature, and environment defined in the URL path parameters. This architectural flaw allows an authenticated user with UPDATE_FEATURE_STRATEGY permissions for one resource context to manipulate resources belonging to a different context if they can guess or obtain the corresponding internal database identifiers. In multi-project deployments using Pro or Enterprise editions, this enables cross-project manipulation where an attacker operating within Project A can reorder strategies in Project B by supplying the target project's strategy IDs while maintaining their authentication token from Project A. The system attributes these changes to the attacker's URL context rather than the affected project, creating a significant audit trail discrepancy that complicates forensic analysis and accountability.
From a technical perspective, this is a classic example of an Insecure Direct Object Reference (IDOR) vulnerability, formally categorized under CWE-639 in industry standards. The root cause lies in the unprotectedUpdateStrategiesSortOrder and updateSortOrder functions which accept user-supplied strategy IDs without performing secondary authorization checks against the database to ensure ownership or permission alignment with the URL parameters. While the application correctly verifies that the requester has general permissions for features, it neglects to verify resource-level ownership during bulk operations like sorting. This oversight is particularly dangerous in multi-tenant environments where strict isolation between projects is a fundamental security requirement. Even in single-project Open Source editions, although cross-project attacks are not possible due to the lack of multiple project contexts, the vulnerability still permits unauthorized reordering across different features or environments within that default project if an attacker can enumerate valid identifiers for those resources.
The operational impact of this vulnerability centers on the manipulation of feature flag evaluation precedence. By altering the sort order of strategies, an attacker can change which strategy takes priority when evaluating a specific feature flag in a given environment. This does not involve modifying the actual parameters, constraints, or segments associated with the strategies, but rather changes their execution hierarchy. In complex deployment scenarios where multiple strategies are chained or prioritized to determine user experience outcomes, such unauthorized reordering can lead to unintended behavior, potentially exposing features to users who should be excluded or hiding them from intended audiences. This undermines the reliability of feature management systems and can cause service disruptions or security policy violations depending on how critical flags are configured. Furthermore, because the action is attributed to the attacker's context rather than the victim project, it obscures the true scope of the breach during incident response activities.
To mitigate this vulnerability, organizations must upgrade Unleash to version 8.0.3 or later where these authorization checks have been implemented and validated against resource ownership. For environments that cannot immediately patch due to operational constraints, network-level controls such as Web Application Firewalls can be configured to monitor for anomalous patterns in API requests involving strategy ID manipulation, although this is a less effective long-term solution than fixing the code logic. Security teams should also review audit logs to identify any past instances of unauthorized sort order changes by correlating user activity with unexpected shifts in feature flag behavior. Additionally, implementing stricter input validation that cross-references submitted IDs against the authorized resource tree for each request would prevent similar IDOR vulnerabilities from being exploited in other parts of the application. Regular security assessments focusing on object-level access controls are recommended to ensure that all API endpoints properly enforce context binding between URL parameters and user permissions.