Filtered by vendor Snipeitapp
Subscribe
Total
135 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-63498 | 1 Snipeitapp | 1 Snipe-it | 2026-09-29 | N/A | 8.7 HIGH |
| Snipe-IT is an IT asset/license management system. Prior to 8.7.0, the uploaded-files API endpoint GET /api/v1/{object_type}/{id}/files/{file_id} allows an authenticated user with file-management access to upload XML and XSLT attachments and request them with the inline=true parameter. The app/Http/Controllers/Api/UploadedFilesController.php show() path does not apply the safe-inline allowlist used by the equivalent web controller, so the browser can process an attacker-controlled xml-stylesheet reference and execute JavaScript generated by the stylesheet in the Snipe-IT origin. A victim who is authorized to view the object must open the attachment URL, after which the script can read same-origin data and perform authenticated actions with the victim's privileges. This issue is fixed in version 8.7.0. | |||||
| CVE-2026-62368 | 1 Snipeitapp | 1 Snipe-it | 2026-09-29 | N/A | 8.1 HIGH |
| Snipe-IT is an IT asset/license management system. Prior to 8.7.0, a user with the customfields.create permission can store markup in CustomField.name, and app/Presenters/AssetPresenter.php assigns that value as an unescaped bootstrap-table header title. When another user opens an asset-list page associated with the fieldset, the stored markup executes on page load in that user's Snipe-IT session. This can expose same-origin data and perform authenticated actions with the victim's privileges, including privilege escalation when a superuser views the affected list. This issue is fixed in version 8.7.0. | |||||
| CVE-2026-86774 | 1 Snipeitapp | 1 Snipe-it | 2026-09-20 | N/A | 6.3 MEDIUM |
| Snipe-IT versions before 8.7.0 contain a broken access control vulnerability in AssetModelPolicy where the files() method cascades from assets.files permission, allowing authenticated users to upload and delete file attachments on Asset Model records without the required models.files permission. Attackers with only assets.files permission can mutate shared model file attachments across company boundaries and bypass the dedicated models.files permission intended to restrict file management on the shared Asset Model catalog. | |||||
| CVE-2026-86769 | 1 Snipeitapp | 1 Snipe-it | 2026-09-20 | N/A | 4.3 MEDIUM |
| Snipe-IT versions before 8.7.0 contain an improper ownership management vulnerability in the consumables checkout API endpoint that records the checkout target user's id in the created_by column instead of the authenticated caller's id. Authenticated attackers with consumables.checkout permission can perform checkouts that result in misattributed audit trail entries in the consumables_users pivot table, obscuring which operator performed the action. | |||||
| CVE-2026-86764 | 1 Snipeitapp | 1 Snipe-it | 2026-09-20 | N/A | 6.5 MEDIUM |
| Snipe-IT through 8.6.4 (fixed in 8.7.0) does not enforce the components.view permission on the authenticated endpoint GET /api/v1/hardware/<asset-id>/assigned/components. The endpoint authorizes only assets.view on the parent asset before returning linked component details; the components.view check is applied only to the response's available_actions.view flag and not to the returned data. As a result, an authenticated user holding only assets.view can enumerate component IDs, names, assigned quantities, and notes that are otherwise protected — the direct GET /api/v1/components/<id> endpoint correctly returns 403 Forbidden for such users. | |||||
| CVE-2026-86759 | 1 Snipeitapp | 1 Snipe-it | 2026-09-20 | N/A | 7.1 HIGH |
| Snipe-IT versions before 8.7.0 fail to authorize the POST /hardware/history endpoint, allowing any authenticated user to reassign arbitrary assets and modify audit logs. Attackers can submit a CSV file to reassign assets across companies and inject fraudulent audit trail entries, compromising inventory integrity and accountability. | |||||
| CVE-2026-86754 | 1 Snipeitapp | 1 Snipe-it | 2026-09-20 | N/A | 7.3 HIGH |
| Snipe-IT before 8.7.0 fails to properly gate Laravel Passport's OAuth client management routes, allowing any authenticated user to register OAuth clients with attacker-controlled redirect URIs. Attackers can trick administrators into approving consent screens, then exchange authorization codes for bearer tokens inheriting full admin API permissions lasting up to 40 years. | |||||
| CVE-2026-86749 | 1 Snipeitapp | 1 Snipe-it | 2026-09-19 | N/A | 6.3 MEDIUM |
| Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not check the return value of storage write operations in ImageUploadRequest::handleImages(). Because Laravel's default disk mode does not throw on failure, a silently failed Storage::disk('public')->put(...) call still caused the application to delete the previous image via deleteExistingImage() and to reassign and persist the model's image reference to the new filename, destroying the existing image and leaving the database row pointing at a file that was never written. A mirror problem existed in deleteExistingImage(), where a failed Storage::delete() still nulled the model's image field, orphaning the file on disk. The condition is not directly attacker-controlled: it is triggered when any legitimate authenticated user submits an image upload while the storage backend transiently fails (for example an S3 network error, a local filesystem permission problem, or quota exhaustion). The result is unrecoverable loss of the prior image and a durable inconsistency between the database and disk that requires manual reconciliation. All models whose controllers route through ImageUploadRequest::handleImages (assets, asset models, users, companies, manufacturers, locations, categories, suppliers, departments, and other image-carrying models) are affected. | |||||
| CVE-2026-86736 | 1 Snipeitapp | 1 Snipe-it | 2026-09-19 | N/A | 4.3 MEDIUM |
| snipe-it before 8.7.0 contains an incorrect calculation vulnerability in checkout request handling that allows authenticated users to corrupt the assets.requests_counter through duplicate submissions and cancellations without active requests. Attackers can repeatedly call cancel endpoints without active requests to drive the counter negative, or submit duplicate checkout requests to inflate the counter, misrepresenting pending demand in the admin queue. | |||||
| CVE-2026-86744 | 1 Snipeitapp | 1 Snipe-it | 2026-09-18 | N/A | 2.2 LOW |
| Snipe-IT 8.6.3 and earlier (and develop pre-release commits prior to the fix) contain a race condition in the asset checkout paths. Api\AssetsController::checkout() and Assets\AssetCheckoutController::store() call Asset::availableForCheckout() outside the mutation path and then invoke Asset::checkOut() without taking a row lock or re-checking availability, so two concurrent checkout requests for the same available asset can both observe it as available and both commit. This produces duplicate checkout-history rows, a doubled checkout_counter, and two CheckoutableCheckedOut events for a single-assignment asset, corrupting the audit trail and utilization/reconciliation reporting; the asset's final assigned_to remains singular, so the visible assignment stays intact. Exploitation requires an authenticated session holding the assets.checkout permission (or superuser) and precise concurrent timing. Fixed in 8.7.0. | |||||
| CVE-2026-86739 | 1 Snipeitapp | 1 Snipe-it | 2026-09-18 | N/A | 3.1 LOW |
| Snipe-IT 8.6.3 and earlier do not check the return value of Storage::put() when writing the signature PNG and the generated acceptance PDF in Account\AcceptanceController::store(). On filesystem drivers that return false instead of throwing on a write failure (for example the local disk with restrictive permissions, S3 with expired credentials, or a storage backend that is out of quota), execution continues into $acceptance->accept(), which sets accepted_at and the signature_filename/eula_filename fields, creates the 'accepted' action-log entry, and dispatches completion notifications even though the evidence files were never stored. The result is an acceptance record marked complete whose supporting evidence files do not exist, yielding a materially incomplete compliance artifact for EULA acknowledgement or equipment-receipt workflows. The condition is triggered when an authenticated user completes an acceptance while the storage backend is silently failing writes; an attacker cannot directly force the storage backend into that state. Fixed in Snipe-IT 8.7.0. | |||||
| CVE-2026-85616 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 8.5 HIGH |
| Snipe-IT versions before 8.6.2 contain an authorization bypass vulnerability in checkout-acceptance report actions when Full Multiple Company Support is enabled. Authenticated users with reports.view permission can enumerate sequential acceptance IDs and soft-delete or trigger reminder emails for acceptances belonging to other companies by exploiting a null check on the legacy users.company_id column. | |||||
| CVE-2026-85617 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 8.8 HIGH |
| snipe-it versions before 8.6.3 contain an authorization bypass vulnerability in the bulk delete functionality that allows restricted users to soft-delete users outside their authorized scope. Attackers can include unauthorized user IDs in bulk delete requests to bypass instance-level restrictions and modify or disable accounts they should not access. | |||||
| CVE-2026-86772 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 5.4 MEDIUM |
| Snipe-IT versions before 8.7.0 contain a stored cross-site scripting vulnerability in DepartmentPresenter::formattedNameLink() where department names are rendered unescaped in the fallback branch for users without departments.view permission. Users with departments.edit permission can inject malicious scripts into department names that execute in the browsers of all department members when they load their My Assets page. | |||||
| CVE-2026-86771 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 7.6 HIGH |
| Snipe-IT versions before 8.7.0 fail to HTML-escape the employee_num field in the acceptance PDF generator, allowing attackers with users.edit permission to inject img tags into TCPDF's writeHTML() function. Attackers can craft a malicious employee_num value containing an img tag with an arbitrary HTTP(S) URL to trigger server-side requests to internal services, cloud metadata endpoints, or external targets when a victim signs an asset acceptance. | |||||
| CVE-2026-86770 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 8.1 HIGH |
| Snipe-IT before 8.7.0 fails to validate username case sensitivity during SAML authentication, allowing attackers to authenticate as different users by registering IdP accounts with accent or case variants of victim usernames. Attackers can exploit the default utf8mb4_unicode_ci database collation to bypass username matching and achieve account takeover through federated login paths including SAML, LDAP, and OAuth. | |||||
| CVE-2026-86768 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 5.4 MEDIUM |
| Snipe-IT before 8.7.0 fails to validate soft-deleted state in API checkout endpoints, allowing authenticated users with checkout permissions to bind live inventory to trashed targets. Attackers can submit POST requests to hardware, component, or consumable checkout endpoints with soft-deleted user, asset, or location IDs to create orphaned references that corrupt the asset ledger and audit trails. | |||||
| CVE-2026-86767 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 5.0 MEDIUM |
| Snipe-IT versions before 8.7.0 fail to apply company scope filtering to the GET /hardware/requested endpoint when Full Multiple Company Support is enabled, allowing authenticated users with assets.view permission to read pending asset requests from all companies. Attackers can retrieve cross-tenant data including requested asset names, requester display names and profile links, locations, and expected check-in dates without parameter manipulation. | |||||
| CVE-2026-86766 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 6.5 MEDIUM |
| Snipe-IT versions up to and including 8.6.3 contain a race condition (TOCTOU) in the consumable checkout API endpoint (POST /api/v1/consumables/{consumable_id}/checkout). The requested quantity is validated against the number of remaining units before the database transaction begins, and the transaction then creates the checkout records without locking the consumable row or re-checking availability. An authenticated user with permission to check out consumables can submit concurrent checkout requests for the same consumable so that both requests pass the availability check and succeed, over-allocating stock and driving the remaining inventory negative (e.g., a consumable with 1 remaining unit ends at -1 after two concurrent 1-unit checkouts). The issue is fixed in 8.7.0, which re-fetches the parent row under lockForUpdate inside the transaction and re-validates availability. | |||||
| CVE-2026-86765 | 1 Snipeitapp | 1 Snipe-it | 2026-09-16 | N/A | 6.5 MEDIUM |
| Snipe-IT versions before 8.7.0 fail to enforce checkout authorization when assignment fields are submitted to the asset update endpoint. Authenticated users with edit permission but explicitly denied checkout permission can reassign assets, bypass check-in procedures, and alter custody records by submitting assigned_user, assigned_asset, or assigned_location parameters to PATCH /api/v1/hardware/{id}. | |||||