GHSA-8xcj-9hfr-fh9j: Npm/unleash-server vulnerability
Summary
The clone-feature endpoint supports copying features across projects, but it does not verify that the caller can access the source project. A user with create permissions in one project can clone a feature from another project they cannot read and then inspect the copied configuration.
This vulnerability cannot be confirmed without Enterprise access. Report is based on a circumstantial evidence in the open-source repository.
Details src/lib/features/feature-toggle/feature-toggle-service.ts implements cloneFeatureToggle. This operation needs authorization for both sides: permission to read/copy the source feature and permission to create the destination feature.
The clone path validates permissions against the destination project, but not against the source project that owns featureName. Because feature names are globally unique, a caller can reference a feature outside projects they can access.
PoC 1. Create or identify two projects: P1 with a private or restricted feature named secret-feature, and P2 where the attacker has clone/create permissions. 2. Authenticate as the attacker. 3. Send:
http POST /api/admin/projects/P2/features/secret-feature/clone Content-Type: application/json
{ "name": "secret-feature-copy" }
4. Open P2 and inspect secret-feature-copy. Verify if strategy parameters, constraints, variants, and variant payloads from the source feature have been copied.
Impact Users with permissions on one project can disclose feature configuration from another project if they know or guess the source feature name. Feature names could be available in more public applications that have a common SDK access to multiple projects.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/unleash-serverto a version that resolves this vulnerability.Fixed in 8.0.3 - Compensating control
Require authorization for both sides of cross-project feature cloning: verify the caller has permission to read/copy the source feature and permission to create the destination feature.
Event History
Frequently Asked Questions
Which deployments are most exposed?
Deployments that use private or restricted projects are exposed when a user can create or clone features in a different project. The report notes that confirmation requires Enterprise access.
What access does an attacker need?
The attacker needs authentication and create or clone permissions in a destination project. They do not need read access to the source project if they can reference its globally unique feature name.
What information can be obtained through the issue?
An attacker can clone a feature from an inaccessible source project into a project they can access, then inspect the copied feature configuration. This can expose configuration associated with features in restricted projects.
What can be done while remediation is pending?
Limit feature create or clone permissions to trusted users, particularly in projects that could be used as clone destinations. Restricting those permissions reduces the ability to copy features from projects the caller should not be able to read.