GHSA-3hgv-jr5j-cg9x: Composer/snipe/snipe-it vulnerability
Impact An attacker can completely bypass file-name randomization security and without authorization download confidential, signed EULA files belonging to any other user across the application.
Steps to Reproduce: 1. Log in as a restricted user. 2. Send a GET request to /api/v1/users/{targetid}/eulas (where targetid belongs to a restricted/denied user). 3. Observe the response leaks the secret EULA filename (e.g., eula-xxx.pdf). 4. Attempt to access this file via the main route: GET /stored-eula-file/{filename} (This will correctly return 403 Forbidden). 5. Now, access the file via the vulnerable profile route: GET /account/stored-eula-file/{filename}. 6. Observe that the server returns a 200 OK and successfully downloads the target user's secret EULA file.
Patches Fixed in https://github.com/grokability/snipe-it/commit/f15d78621b003be30ac114ba68626683894935ef
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/snipe/snipe-itto a version that resolves this vulnerability.Fixed in 8.6.3 - Upgrade
Upgrade
grokability/snipe-itto a version that resolves this vulnerability.Patch f15d78621b003be30ac114ba68626683894935ef
Event History
Frequently Asked Questions
Who can exploit this issue?
A restricted user who can log in can exploit it. The issue allows that user to retrieve confidential signed EULA files belonging to other users, including users whose access is restricted or denied.
What does an attacker need to access another user's EULA file?
The attacker needs a valid restricted-user session, the target user's ID to query the EULA API endpoint, and the leaked EULA filename returned by that endpoint. They can then request the filename through the /account/stored-eula-file/{filename} route.
Does a 403 response from the normal file route mean the EULA is protected?
No. Although /stored-eula-file/{filename} returns 403 Forbidden, the same file can be downloaded through /account/stored-eula-file/{filename}, which returns 200 OK in the vulnerable version.
How can I check whether an instance is affected?
Using a restricted account, request /api/v1/users/{target_id}/eulas for another restricted or denied user and check whether it exposes an EULA filename. Then test whether /account/stored-eula-file/{filename} returns the file despite the normal stored-file route returning 403.
What fix is available?
The issue is fixed by commit f15d78621b003be30ac114ba68626683894935ef. A release reference is provided for v8.6.3.