Unleash CVE-2026-76910

Requires an authenticated Unleash account holding create or clone permission in at least one project (PR:L, so not remote-unauthenticated), plus knowledge or a successful guess of a target feature's globally-unique name in a project the attacker cannot otherwise read. Exploitation targets the clone endpoint POST /api/admin/projects/:projectId/features/:featureName/clone (the cloneFeatureToggle operation) in versions prior to 8.0.3. Limiting factors: the attacker must already have a foothold with project-level clone/create rights, must know or enumerate the source feature name (feature names may leak via shared SDK access across projects), and impact is confined to disclosure of feature configuration (strategies, constraints, variants, payloads) with no write or availability effect.

This is a genuine but modest-severity broken-authorization (IDOR, CWE-639) issue, not a high-CVSS-but-low-real-risk misfire nor a critical priority. The vendor CVSS 4.0 base score is 5.3 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N - meaning network-reachable, low complexity, but requiring an authenticated low-privilege account (PR:L) and yielding only limited confidentiality impact (VC:L) with no integrity or availability impact. There is no EPSS score, no CISA KEV listing, and no evidence of active exploitation in the provided data, so exploitation status is best characterized by the fact that a proof-of-concept exists in the GHSA advisory but the flaw is not confirmed exploited in the wild. Notably, the vendor's own advisory states the vulnerability 'cannot be confirmed without Enterprise access' and is based on circumstantial evidence in the open-source repository, which is a conflicting/uncertainty signal worth flagging: the patch (commit 2dc6ac0e adding validateFeatureBelongsToProject) confirms the code path was fixed, but real-world confirmation of the disclosure was limited. Overall this is a data-confidentiality issue requiring an existing foothold, appropriate for routine patching rather than emergency response.

An authenticated Unleash user who has clone or create permission in one project (P2) but no access to a restricted project (P1) sends POST /api/admin/projects/P2/features/secret-feature/clone, referencing a globally-unique feature name they know or guessed from P1. The clone succeeds because only destination-project authorization is checked, and the attacker then opens the copied feature in P2 to read its strategy parameters, constraints, variants, and variant payloads. A working proof-of-concept with the exact HTTP request is published in the GHSA-8xcj-9hfr-fh9j advisory.