GHSA-fc33-6w3q-538h: Medium severity composer/snipe/snipe-it vulnerability

Published Aug 28, 2026
·
Updated

Impact An authenticated user with only users.view can open another user's detail page and see assigned license, accessory, and consumable data even though the same account is denied direct access to the Licenses, Accessories, and Consumables modules. The leaked data includes software license names, purchase order/order values, accessory and consumable names, assignment notes, and purchase costs.

Attacker Model

Authenticated user with only:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ json {"users.view":"1"} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The attacker does not have:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ json { "licenses.view": "1", "accessories.view": "1", "consumables.view": "1", "assets.view": "1" } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Affected Component

- app/Http/Controllers/Users/UsersController.php

- resources/views/users/view.blade.php

- resources/views/users/print.blade.php

- Endpoints:

- GET /users/{user}

- GET /users/{user}/print

Root Cause

UsersController::show() authorizes only viewing the user, then loads inventory relationships:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ php $this->authorize('view', $user);

$user = User::with([ 'consumables', 'accessories', 'licenses', 'userloc', 'groups', ]) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

resources/views/users/view.blade.php renders those relationships without checking the corresponding module permissions. The license table renders name, purchase cost, purchase order, and order number. The accessory and consumable tables render item names, notes, and unit costs.

UsersController::printInventory() similarly authorizes only view on User::class and the target user, then renders resources/views/users/print.blade.php, which outputs assigned inventory names.

Proof of Concept

1. Create a user with only users.view.

2. Create a target user with assigned license/accessory/consumable records containing recognizable test values.

3. Log in as the users.view-only user.

4. Confirm direct module access is denied:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http GET /licenses GET /accessories GET /consumables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Observed for each:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http HTTP/1.1 403 Forbidden ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. Request the target user's page:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http GET /users/<target-user-id> HTTP/1.1 Host: <snipe-it-host> Cookie: snipeitsession=<attacker-session> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Observed:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http HTTP/1.1 200 OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The response contained assigned inventory data from modules the attacker could not directly access, including license name, purchase order/order values, accessory name/note/cost, and consumable name/note/cost.

1. Request the print view:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http GET /users/<target-user-id>/print HTTP/1.1 Host: <snipe-it-host> Cookie: snipeitsession=<attacker-session> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Observed:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http HTTP/1.1 200 OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The response contained assigned inventory names.

Evidence

The users.view-only test account was confirmed to lack direct inventory permissions:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ json { "hasusersview": true, "haslicensesview": false, "hasaccessoriesview": false, "hasconsumablesview": false, "hasassetsview": false } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Direct access to /licenses, /accessories, and /consumables returned 403 Forbidden.

The same account received 200 OK from /users/<target-user-id> and the response included assigned inventory data that should have been protected by the corresponding inventory module permissions.

Negative Controls

Denied direct module responses did not include the test inventory strings. The same data was only disclosed through the user detail and user print views.

Impact

Organizations may use separate permissions to allow HR/helpdesk-style users to view people records without exposing license, accessory, or consumable inventories and cost/order metadata. This issue bypasses those module-specific permissions and leaks assigned inventory information through the user view.

Patches Patched in 374f426f0c

Affected Software

1 affected componentFixes available
composer/snipe/snipe-it<=8.6.0
8.6.1

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.1
  2. Upgrade

    Upgrade users/view and users/print authorization and inventory rendering to a version that resolves this vulnerability.

    Patch 374f426f0c
  3. Configuration

    Update the user detail view template to check the corresponding inventory module permissions (Licenses/Accessories/Consumables) before rendering those assigned inventory relationships, rather than relying only on the user-level `users.view` authorization.

    resources/views/users/view.blade.php authorization checks for inventory relationships = require module-level permissions before rendering accessories/consumables/licenses
  4. Configuration

    Update the user print view template to check the corresponding inventory module permissions (Licenses/Accessories/Consumables) before rendering those assigned inventory relationships, rather than relying only on the user-level `users.view` authorization.

    resources/views/users/print.blade.php authorization checks for inventory relationships = require module-level permissions before rendering accessories/consumables/licenses

Event History

Aug 28, 2026
Advisory Published
via GitHub·05:57 PM
Data Sourced
via GitHub·05:57 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which accounts should be treated as able to access the exposed information?

Any authenticated account granted users.view is in scope, even if it lacks licenses.view, accessories.view, consumables.view, and assets.view.

2

Can denying access to the Licenses, Accessories, and Consumables modules prevent this disclosure?

No. The affected user-detail and print endpoints can expose assigned license, accessory, and consumable information despite those module permissions being denied.

3

Which paths should be reviewed when assessing exposure?

Review access to GET /users/{user} and GET /users/{user}/print. These endpoints are implemented by UsersController::show() and the associated user detail and print views.

4

What information could have been disclosed through another user's page?

Potentially exposed data includes software license names, purchase order or order values, accessory and consumable names, assignment notes, and purchase costs.

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