CVE-2026-55703 is a medium-severity (CVSS 4.3) CWE-862 vulnerability in snipe/snipe-it. A fix is available for snipe/snipe-it — see the affected versions and patch details below.
Snipe-IT: Maintenance Record Disclosure via Missing Authorization on GET
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 CVE-2026-55703.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-55703 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 382,574 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
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
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
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:
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
- As an administrator, create an asset in a company (here,
CompanyA). Open the asset, choose Maintenances > Create, and add a record: nameMntA2, supplierSupA, a purchase cost, and notes. The saved record opens at/maintenances/{id}. - As the administrator, create a test user assigned to CompanyA, with every permission left unchecked. Activate the account.
- 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
/hardwarereturns 403. - 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
testaccount holds zero permissions and still reads the record. - Only the unguarded
showroute 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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | snipe/snipe-it | all versions | 8.6.3composer require snipe/snipe-it:^8.6.3 |
Affected Products
snipe-itsnipeitappDetection & 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.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-55703 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is CVE-2026-55703 in your dependencies?
Find it across Packagist, including transitive dependencies.