CVE-2026-77425: 
JavaScript vulnerability analysis and mitigation

CVE-2026-77425 is an incorrect authorization vulnerability in Unleash, the open-source feature management platform, that allows an authenticated low-privilege user to reorder activation strategies belonging to any other project or environment, bypassing project-scoped RBAC controls. The vulnerability affects all Unleash versions prior to 8.0.3 (npm package unleash-server). It was originally published on July 13, 2026, and added to the GitHub Advisory Database on September 22, 2026. The CVSS v3.1 base score is 4.3 (Medium) (GitHub Advisory).

The root cause is an asymmetric authorization enforcement in the POST /api/admin/projects/:projectId/features/:featureName/environments/:environment/strategies/set-sort-order endpoint, classified as CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-863 (Incorrect Authorization). The RBAC middleware correctly validates the request against the :projectId in the URL, but the unprotectedUpdateStrategiesSortOrder handler passes attacker-controlled strategy IDs from the request body directly to featureStrategiesStore.updateSortOrder(id, sortOrder) — which issues an unscoped UPDATE ... WHERE id = ? with no project/feature/environment predicate. Sibling mutators (updateStrategy, patchStrategy, deleteStrategy) all call validateUpdatedProperties() to bind the strategy to the URL context; the set-sort-order handler is the sole sibling that omits this check. An attacker places their own project in the URL to satisfy RBAC, then supplies victim strategy UUIDs in the request body to reorder strategies in a project they have no role on (GitHub Advisory, Fix Commit).

A successful exploit allows an authenticated project member to silently alter the activation-strategy evaluation order of feature flags in any other project and environment without authorization. Because Unleash evaluates strategies in order and the first matching strategy determines a flag's rollout value or variant, reordering can effectively enable a feature flag for users the owning team intended to exclude — for example, promoting a permissive flexibleRollout strategy ahead of a restrictive userWithId/constraint-gated one. As a secondary impact, the mutation is attributed to the attacker's own project context in the audit log, meaning the tampering produces no feature-strategy-update event for the victim feature, undermining detection and forensic accountability (GitHub Advisory).

A detailed proof-of-concept is publicly available in the GitHub Security Advisory, demonstrating the full attack using Docker and curl commands against a local Unleash v8.0.0 instance. Exploitation requires only a valid authenticated session with the UPDATE_FEATURE_STRATEGY permission on any one project, and knowledge of the target project's strategy UUIDs (which are obtainable via admin read endpoints). There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the EPSS score is 0.0. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory).

1. Reconnaissance: As an authenticated Unleash user with UPDATE_FEATURE_STRATEGY on at least one project ("attacker project"), enumerate available projects and features using admin read endpoints (e.g., GET /api/admin/projects) to identify a target project and feature flag.
2. Obtain victim strategy UUIDs: Query the victim project's feature strategies via GET /api/admin/projects/victim/features/victimFlag/environments/production/strategies (read access may be available depending on instance configuration) to retrieve the strategy UUIDs (S1, S2).
3. Craft the malicious request: Construct a POST request to the attacker's own project URL — POST /api/admin/projects/attacker/features/attackerFlag/environments/production/strategies/set-sort-order — with the victim's strategy IDs in the body: [{"id": "<S1_UUID>", "sortOrder": 42}, {"id": "<S2_UUID>", "sortOrder": 7}].
4. Bypass RBAC and reorder: Submit the request with the attacker's session cookie or token. The RBAC middleware validates against the attacker's project URL (passes), while the handler writes the victim's strategy sort orders directly to the database by primary key with no project/feature/environment binding — returning HTTP 200.
5. Verify impact: Confirm the victim feature's strategy evaluation order has been flipped (e.g., a permissive strategy now precedes a restrictive one), and verify that no audit event was recorded for the victim feature, leaving no trace in the victim project's event history (GitHub Advisory).

• Network: Unexpected POST requests to /api/admin/projects/<attacker_project>/features/<attacker_feature>/environments/<env>/strategies/set-sort-order where the request body contains strategy UUIDs that do not belong to the URL-specified project/feature/environment.
• Logs: Unleash application logs showing HTTP 200 responses to set-sort-order endpoints where the strategy IDs in the request body differ from those associated with the URL context; absence of feature-strategy-update events for a feature whose strategy order has changed.
• Database: Changes to the sort_order column in the feature_strategies table for strategies belonging to a project/feature/environment not matching the audit event's recorded context; audit events attributed to one project while strategy mutations occurred in another.
• Behavioral: Feature flag rollout behavior changes (e.g., unexpected user segments receiving a flag) without corresponding change request or audit trail entries in the affected project (GitHub Advisory).

Upgrade to Unleash version 8.0.3 or later, which includes the fix that validates all body-supplied strategy IDs against the URL context before writing — rejecting any sortOrders entry whose ID is not present in the set of strategies genuinely belonging to the specified project/feature/environment. The fix was implemented in commit 43e8db3 by checking allSortOrdersAreAlreadyKnown and throwing a BadDataError on mismatch. No configuration-based workaround is available; upgrading is the only remediation (GitHub Release v8.0.3, Fix Commit).

The vulnerability was discovered and reported by researcher 5ud0 of Tarmo Technologies, who provided a complete proof-of-concept in the advisory. The Unleash maintainer chriswk published the advisory and released the fix. No significant broader media coverage or notable community discussion beyond the GitHub advisory has been identified.