GHSA-vgx7-c78r-69w9 is a high-severity (CVSS 7.1) CWE-863 vulnerability in snipe/snipe-it. A fix is available for snipe/snipe-it — see the affected versions and patch details below.
Snipe-IT has an authorization bypass on bulk editing users
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-vgx7-c78r-69w9.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-vgx7-c78r-69w9 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
snipe/snipe-itReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
An authenticated non-admin user with users.view and users.edit, but without users.delete, can directly POST to /users/bulksave and soft-delete another non-admin user. The UI and confirmation route require users.delete, but the destructive sink only authorizes update.
Attacker Model
Authenticated non-admin user with:
{"users.view":"1","users.edit":"1"}
The attacker does not have users.delete, admin, or superuser.
Affected Component
-
routes/web/users.php -
app/Http/Controllers/Users/BulkUsersController.php -
Endpoint:
POST /users/bulksave
Root Cause
The UI only exposes bulk delete to users with delete permission:
@can('delete', \App\Models\User::class)
<option value="delete">...</option>
<option value="merge">...</option>
@endcan
The confirmation path also checks delete:
} elseif ($request->input('bulk_actions') == 'delete') {
$this->authorize('delete', User::class);
However, the destructive route is registered separately:
Route::post('bulksave', [Users\BulkUsersController::class, 'destroy'])
->name('users/bulksave');
and destroy() authorizes only update:
public function destroy(Request $request)
{
$this->authorize('update', User::class);
When delete_user=1 is present, the method reaches:
$user->delete();
Proof of Concept
-
Create a non-admin attacker account with
users.viewandusers.edit, but notusers.delete. -
Create a harmless non-admin target user.
-
Log in as the attacker and obtain a valid CSRF token.
-
Send:
POST /users/bulksave HTTP/1.1
Host: <snipe-it-host>
Cookie: snipeit_session=<attacker-session>
Content-Type: application/x-www-form-urlencoded
_token=<csrf-token>
ids[]=<target-user-id>
delete_user=1
status_id=<valid-status-id>
Observed response:
HTTP/1.1 302 Found
Location: http://<snipe-it-host>/users
Patches
Patched in 374f426f0c
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | snipe/snipe-it | all versions | 8.6.2composer require snipe/snipe-it:^8.6.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for snipe/snipe-it, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update snipe/snipe-it to 8.6.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vgx7-c78r-69w9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-vgx7-c78r-69w9 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-vgx7-c78r-69w9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vgx7-c78r-69w9 in your dependencies?
O3 Security finds GHSA-vgx7-c78r-69w9 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.