GHSA-r9r3-g9fp-3q4q: Medium severity composer/snipe/snipe-it vulnerability

Published Aug 19, 2026
·
Updated

Impact Any activated account in a company can read every maintenance record for that company (asset tag, supplier, purchase cost, free-text notes, dates) without holding any asset or maintenance permission.

Summary

MaintenancesController::show() renders a maintenance record without any authorization check. Every other action in the controller authorizes against the asset; show() does not. Any user in the asset's company can read maintenance detail (asset tag, supplier, purchase cost, notes, dates) by visiting /maintenances/{id}, regardless of permissions.

Details

php public function show(Maintenance $maintenance): View|RedirectResponse { return view('maintenances.view')->with('maintenance', $maintenance); }

No authorize() call. The sibling actions all gate on the asset: index() calls authorize('view', Asset::class) (line 33), and edit()/update()/destroy() call authorize('update', $maintenance->asset) (lines 139, 166, 286). The route is registered with only the auth guard:

php Route::resource('maintenances', MaintenancesController::class, ['middleware' => ['auth']]);

(routes/web/hardware.php:185). Route-model binding still applies the company scope, so the read is bounded to the caller's company; the absent permission gate is the defect. Maintenance IDs are sequential and visible in the record URL.

Proof of concept

1. As an administrator, create an asset in a company (here, CompanyA). Open the asset, choose Maintenances > Create, and add a record: name MntA2, supplier SupA, a purchase cost, and notes. The saved record opens at /maintenances/{id}. 2. As the administrator, create a test user assigned to CompanyA, with every permission left unchecked. Activate the account. 3. In a separate browser session, log in as the test user. Confirm it is unprivileged: the Assets and Maintenances navigation items are absent, and browsing to /hardware returns 403. 4. In the address bar, browse to http://<host>/maintenances/{id}.

Observed: the maintenance view renders in full for the unprivileged account.

GET /maintenances/5 -> HTTP 200 OK Renders the "Maintenance" detail page for MntA2: Asset: AssetA Supplier: SupA Cost: <value> Notes: <text> Dates: <...>

GET /hardware -> HTTP 403 (same account, asset list is gated) GET /maintenances -> HTTP 403 (same account, maintenance list is gated) GET /maintenances/2 -> HTTP 302 (record in CompanyB; company scope still hides it)

- The test account holds zero permissions and still reads the record. - Only the unguarded show route leaks: the list view and the asset pages return 403 for the same account. - A maintenance in a different company (CompanyB) redirects away, confirming the FMCS company scope still holds.

Patches Patched in https://github.com/grokability/snipe-it/commit/69c50aa2aee25f837626556b4f4f3d05ec7ace96

Affected Software

1 affected componentFixes available
composer/snipe/snipe-it<8.6.3
8.6.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/snipe/snipe-it to a version that resolves this vulnerability.

    Fixed in 8.6.3
  2. Upgrade

    Upgrade grokability/snipe-it to a version that resolves this vulnerability.

    Patch 69c50aa2aee25f837626556b4f4f3d05ec7ace96

Event History

Aug 19, 2026
Advisory Published
via GitHub·07:32 PM
Data Sourced
via GitHub·07:32 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which users should be considered able to access maintenance details?

Any activated account associated with the same company as the asset can access maintenance records, even if it has no asset or maintenance permissions.

2

What does an attacker need to exploit this issue?

The attacker needs an authenticated, activated account in the affected company and must request the maintenance detail endpoint at /maintenances/{id}. No additional asset or maintenance permission is required.

3

Does the maintenance detail route have an authorization control beyond authentication?

The resource route is registered with only the auth middleware. MaintenancesController::show() renders the record without an authorize() call, unlike the controller's other actions.

4

How can I confirm that an installation contains the vulnerable behavior?

Inspect MaintenancesController::show() and verify whether it returns the maintenances.view view without an authorization check. Also verify that the maintenances resource route is protected only by the auth middleware.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203