Unleash CVE-2026-77425

Requires an authenticated Unleash user who already holds the UPDATE_FEATURE_STRATEGY permission in at least one project, plus knowledge of the target's strategy IDs (primary keys). Full cross-project impact requires a multi-project Pro or Enterprise deployment running a version prior to 8.0.3; the single-project OSS edition is still affected but limited to unauthorized reordering across features/environments within the default project. Limiting factors: valid credentials and an existing project role (PR:L, so not exploitable by fully unauthenticated attackers), the need to enumerate/know victim strategy IDs, and an impact ceiling of only sort_order changes - strategy parameters, constraints, and segments cannot be altered. No user interaction is required.

This is a genuine but low-severity authorization (IDOR/BOLA, CWE-639) flaw, not a high-CVSS crisis. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N = 4.3) is consistent with the description: exploitation is network-reachable and low-complexity but requires an authenticated user holding UPDATE_FEATURE_STRATEGY in at least one project, and the impact is limited to integrity (I:L) with no confidentiality or availability effect. No EPSS score, no CISA KEV listing, and no public exploit were provided, so the correct exploitation status is 'no public exploit identified at time of analysis' - do not treat this as actively exploited. Signals are internally consistent (no CVSS-vs-description conflict): the missing object-level check is confirmed by the GHSA advisory and the fix commit 43e8db37, which adds an allSortOrdersAreAlreadyKnown validation that rejects strategy IDs not already belonging to the URL-scoped environment. The realistic priority is moderate-to-low: it matters most in multi-project Pro/Enterprise deployments where cross-tenant integrity and audit-trail integrity are concerns, and it is bounded because only sort_order (evaluation precedence) can be changed - not strategy parameters, constraints, or segments.

An authenticated low-privilege member of Project A in a multi-project Unleash Pro/Enterprise instance obtains the strategy IDs of a feature in Project B (which they have no role on), then sends POST /api/admin/projects/A/features/.../strategies/set-sort-order with Project B's strategy IDs in the body. RBAC passes because it only checks the URL's project, and the handler reorders the victim project's activation strategies - flipping which strategy 'wins' in production - while the audit event is attributed to the attacker's project context. No public proof-of-concept was provided, but the fix commit and its e2e test effectively demonstrate the mutation path.