Snipe-IT's import created_by can be overwritten
The created_by of an import file can be arbitrarily overwritten via the Importer API endpoint by a user with CSV import capabilities who also has a valid API key.
The created_by of an import file can be arbitrarily overwritten via the Importer API endpoint by a user with CSV import capabilities who also has a valid API key.
When Full Multiple Companies Support and scope_locations_fmcs are both enabled, the API endpoint for creating locations can still create a child location under a parent location from a different company. The code detects the invalid parent/child company mismatch, but it appears not to return immediately, so the request continues and the record is still saved. The equivalent Web flow correctly rejects the same relationship. This breaks the expected company-boundary enforcement …
A user with the reports.view permission can delete pending checkout acceptance records by global ID, even when the acceptance belongs to an asset in another company. The report listing page appears to scope visible unaccepted assets, but the delete endpoint directly looks up CheckoutAcceptance::pending()->find($acceptanceId) and deletes it without checking whether the current user has access to the related checkoutable asset.
The route POST /account/request/{itemType}/{itemId}/{cancel_by_admin?}/{requestingUser?} accepts cancel_by_admin as a plain URL path segment with no authorization check. Any authenticated user regardless of permissions can set this parameter to a truthy value and supply a victim's user ID to silently cancel that user's pending asset requests. The attacker only needs an active session; no elevated privilege is required.
CommonMark is configured with html_input => 'escape', which blocks raw HTML injection. However, javascript: URIs in Markdown hyperlinks are not sanitized. A user with assets.edit permission can inject a malicious link into any markdown-textarea custom field. Any user who opens the asset detail page and clicks the link executes arbitrary JavaScript in their browser session.
A low-privilege user can store an active-content payload as an asset attachment and have it served inline, same-origin, with an active Content-Type, achieving stored XSS. The application sanitizes uploads only when PHP finfo detects image/svg+xml. By submitting an XHTML document whose finfo MIME is text/xml (an allowed extension), the svg-sanitize branch is skipped, the is stored raw, and the inline-serve path returns it as text/xml; charset=utf-8 with Content-Disposition: inline — …
The displaySig action in ActionlogController serves signature image files from a private upload directory. The filename parameter from the HTTP route is concatenated directly into a filesystem path with no sanitization, allowing an authenticated attacker to traverse outside the intended directory and read arbitrary files accessible to the web server process. Reported by https://github.com/securin-public
The API endpoint for updating asset maintenance records allows an authorized user to change the asset_id of an existing maintenance record to an asset outside their company scope. In a Full Multiple Company Support / multi-company deployment, this allows a user from Company A to attach or move a maintenance record onto an asset belonging to Company B. The endpoint appears to authorize access to the existing maintenance record’s asset, …
The API endpoint for adding a license to a predefined kit (POST /api/v1/kits/{kit_id}/licenses) only checks whether the caller can edit kits, but does not perform object-level authorization on the referenced license itself. Because of this, a low-privilege user with only predefined-kit permissions can still bind a license that they should not be allowed to access or manage into a kit.
The legacy single-seat license checkin flow authorizes the action with the checkout permission instead of the checkin permission. Because of this, a user who is allowed to assign licenses but not unassign them can still directly access the old checkin endpoint and reclaim a license seat that is currently assigned to another user or asset.
In Snipe-IT v8.6.1 and lower, Actionlog::logaction() stores the request User-Agent header in user_agent. That value is later included in the Activity Report CSV export by ReportsController::postActivityReport() and written with plain fputcsv(). A low-privileged authenticated user can set a formula-like User-Agent, perform a logged action, and have that value stored in the activity log. If an admin or report viewer later exports the Activity Report and opens it in spreadsheet software, …
Because default.blade.php is the base layout loaded on every authenticated page, all active user sessions are affected immediately upon the next page load after the payload is saved. An attacker who has compromised an admin account (or who is a malicious insider) can use this to silently exfiltrate session tokens from all other users, including other administrators. Additionally, the Content Security Policy is disabled by default in Snipe-IT installations, which …
The user edit flow stores url()->previous() into Laravel's intended URL session value and later redirects with redirect()->intended(…) when redirect_option=back is submitted. Because the previous URL is derived from the attacker-controlled Referer header, an authenticated user performing a normal user-edit action can be redirected to an external attacker-controlled site. An attacker who can cause a logged-in user with permission to edit a user record to open the edit page with an …
The update() method in UsersController passes the permission request field unconditionally to NormalizePermissionsPayloadAction, which returns an empty array when the field is absent. The result is passed to PreserveUnauthorizedPrivilegedPermissionsAction, which selectively restores only the superuser key (when the editor is not a superuser) and the admin key (when the editor is neither admin nor superuser). All other permissions — including the admin flag itself when the editing user is an …
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. Organizations may use separate permissions to allow HR/helpdesk-style users to view people records without exposing …
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.
An authenticated user holding the import and assets.update permissions can delete arbitrary files on the server filesystem by injecting a path traversal string into an asset's image field via CSV import, then triggering the image deletion feature.
Due to inconsistent authorization checks, a company-scoped user can bypass tenant boundaries to read, mutate, and soft-delete users who do not belong to any company (company_id = null). While direct instance authorization (isCurrentUserHasAccess) correctly denies access to these out-of-scope users, multiple API endpoints and bulk action web routes fail to enforce this restriction, relying instead on class-level permissions or broad scoped queries. Impact: A malicious user scoped to a specific …
The table component derives data-selected-count-id from the component $name value. On manufacturer and supplier detail pages, stored manufacturer or supplier names are passed into affected table components as that name value. The client-side JavaScript later reads the browser-decoded data-selected-count-id, uses it as a selector, and concatenates countId.substring(1) directly into an HTML string passed to jQuery .after(). Affected commit: b224cc636c6780386e3f73f03d1171f52ab4c37a Example payload for a manufacturer or supplier name: x[foo="><svg/onload=alert(1)>"]> The issue …
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.
An attacker can completely bypass file-name randomization security and without authorization download confidential, signed EULA files belonging to any other user across the application.
POST /two-factor had no rate limiting, lockout, or attempt counter. An attacker with valid credentials can submit unlimited TOTP guesses. The TOTP implementation accepts the current code plus one step on either side (config/google2fa.php window=1), so at any instant 3 of 1,000,000 codes are accepted. After a correct guess the attacker holds a fully authenticated session. If the instance is configured with 2FA in optional mode (two_factor_enabled='1'), the attacker can …
The GET /api/v1/{object}/selectlist API endpoint is missing an authorization check. Any user who can log into Snipe-IT - regardless of permissions - can retrieve a paginated list of all user accounts using only their web session cookie. No API token or elevated permissions are required. This exposes usernames, display names, employee numbers, and user IDs for every active account in the system if FMCS is not enabled, and within the …
Snipe-IT S3 signature image retrieval lacks authorization before temporary URL. On S3-backed deployments, authenticated users who know a signature filename can obtain a 5-minute signed S3 URL because the S3 branch returns before the authorize() call used by the local-file branch.
The vulnerability allows a non-admin user holding only the granular users.edit permission to lock every admin out of the instance by editing the activated flag (which determines whether or not a user can login) and the ldap_import flag, which determines whether or not the user can request a password reset.
The CSV user import in update mode bypasses user-edit authorization. A user with only the import permission can overwrite any non-admin user's email by uploading a CSV, then trigger a password reset to take over the account. UserImporter.php checks the canEditAuthFields gate and tries to strip auth fields from the model: // app/Importer/UserImporter.php:107-114 if (Auth::check() && (! Gate::allows('canEditAuthFields', $user))) { unset($user->username); unset($user->email); unset($user->password); unset($user->activated); } $user->update($this->sanitizeItemForUpdating($user)); The unset()s operate on …
The store() method in both the web and API UsersController only strips the superuser permission when a non-superuser creates a user. It does not strip the admin permission. This allows any authenticated user with the users.create permission to create a new user with full admin privileges. The users.create permission may commonly be delegated to HR staff, department leads, or similar roles.
A user with only users.edit AND api permissions can send a PATCH to /api/v1/users/{their_own_id} and grant themselves any permission except admin and superuser — for example assets.view, assets.create, reports.view, import, etc.
The BulkAssetsController::update() method accepts company_id directly from user input without calling Company::getIdForCurrentUser(), the standard company-scoping function used by every other controller in the codebase. A non-superadmin user can move assets across company boundaries, breaking multi-tenancy isolation.
A vulnerability was identified in Snipe-IT v8.4.0 (build 21280-g91a95dbc6) that allows any authenticated user with generic asset edit permissions to delete files attached to any asset in the system, regardless of ownership or company assignment. This constitutes an Insecure Direct Object Reference (IDOR) vulnerability caused by a class-level authorization check in the file deletion endpoint, where an instance-level check is required. The vulnerability exists in both the web and API …
A user who can edit other users could reset a superadmin's 2FA.
A cross-tenant data injection vulnerability was identified in the Snipe-IT Accessories API when Full Multiple Companies Support (FMCS) is enabled. A low-privileged authenticated user belonging to one company can create an accessory record under another company by supplying a foreign company_id value in the API request body. The issue occurs because the API create path mass-assigns request parameters directly to the Accessory model, and the Accessory model allows company_id to …
Users with component view access could be impacted by an unescaped notes column.
An authenticated user with only users.edit permission can escalate their own privileges to admin by sending a PATCH request to /api/v1/users/{id} with permissions[admin]=1. The API controller only strips the superuser key from the permissions array, allowing admin and all other permission keys to be set by any user who can update users.
Insecure Permissions vulnerability in grokability snipe-it versions through 8.4.0, fixed after 2026-03-10 commit 676a9958, allow a remote attacker to execute arbitrary code via the app/Http/Controllers/Api/UploadedFilesController.php component
Open redirect vulnerability in Snipe-IT allows attackers to redirect users to malicious sites via unvalidated HTTP Referer header stored in session variable.
Snipe-IT versions prior to 8.3.7 contain sensitive user attributes related to account privileges that are insufficiently protected against mass assignment. An authenticated, low-privileged user can craft a malicious API request to modify restricted fields of another user account, including the Super Admin account. By changing the email address of the Super Admin and triggering a password reset, an attacker can fully take over the Super Admin account, resulting in complete …
Snipe-IT before 8.3.4 allows stored XSS via the Locations "Country" field, enabling a low-privileged authenticated user to inject JavaScript that executes in another user's session.
Snipe-IT before 8.3.4 allows stored XSS, allowing a low-privileged authenticated user to inject JavaScript that executes in an administrator's session, enabling privilege escalation.
Snipe-IT v8.3.4 (build 20218) contains a reflected cross-site scripting (XSS) vulnerability in the CSV Import workflow. When an invalid CSV file is uploaded, the application returns a progress_message value that is rendered as raw HTML in the admin interface. An attacker can intercept and modify the POST /livewire/update request to inject arbitrary HTML or JavaScript into the progress_message. Because the server accepts the modified input without sanitization and reflects it …
Snipe-IT before 8.1.18 allows XSS.
Snipe-IT before 8.1.18 allows unsafe deserialization.
Grokability Snipe-IT before 8.1.0 has incorrect authorization for accessing asset information.
Cross Site Scripting vulnerability in Snipe-IT v.7.0.13 allows a remote attacker to escalate privileges via an unknown part of the file /users/{{user-id}}/#files.
Snipe-IT before 7.0.10 allows remote code execution (associated with cookie serialization) when an attacker knows the APP_KEY. This is exacerbated by .env files, available from the product's repository, that have default APP_KEY values.
Users with "User:edit" and "Self:api" permissions can promote or demote themselves or other users by performing changes to the group's memberships via API call.This issue affects snipe-it: from v4.6.17 through v6.4.1.
Cross-Site Request Forgery (CSRF) in GitHub repository snipe/snipe-it prior to v.6.2.3.
Cross-site Scripting (XSS) - Stored in GitHub repository snipe/snipe-it prior to v6.2.2.
Snipe-IT before 6.0.14 is vulnerable to Cross Site Scripting (XSS) for View Assigned Assets.
Snipe-IT through 6.0.14 allows attackers to check whether a user account exists because of response variations in a /password/reset request.
Improper Authentication in GitHub repository snipe/snipe-it prior to 6.0.10.
Cross-site Scripting (XSS) - Stored in GitHub repository snipe/snipe-it prior to v6.0.11.
Session Fixation in GitHub repository snipe/snipe-it prior to 6.0.10.
An arbitrary file upload vulnerability in the Update Branding Settings component of Snipe-IT v6.0.2 allows attackers to execute arbitrary code via a crafted file.
An arbitrary file upload vulnerability in the Select User function under the People Menu component of Snipe-IT v6.0.2 allows attackers to execute arbitrary code via a crafted file.
Snipe-IT before 4.6.14 has XSS, as demonstrated by log_meta values and the user's last name in the API.
In Snipe-IT, versions v3.0-alpha to v5.3.7 is vulnerable to Host Header Injection. By sending a specially crafted host header in the reset password request, it is possible to send password reset links to users which once clicked lead to an attacker controlled server and thus leading to password reset token leak. This leads to account take over.
Improper Access Control in GitHub repository snipe/snipe-it prior to 5.4.4.
Stored Cross Site Scripting vulnerability in the checked_out_to parameter in GitHub repository snipe/snipe-it prior to 5.4.3. The vulnerability is capable of stolen the user Cookie.
Stored Cross Site Scripting vulnerability in Item name parameter in GitHub repository snipe/snipe-it prior to v5.4.3. Exploiting the vulnerability may allow malicious users to steal victim's Cookie data.
Old sessions are not blocked by the login enable function in GitHub repository snipe/snipe-it prior to 5.3.10.
Generation of Error Message Containing Sensitive Information in Packagist snipe/snipe-it prior to 5.3.11.
Improper Privilege Management in Packagist snipe/snipe-it prior to 5.3.11.
Observable Discrepancy in Packagist snipe/snipe-it prior to v5.3.10.
Improper Privilege Management in Packagist snipe/snipe-it prior to 5.3.9.
snipe-it is vulnerable to Improper Access Control
snipe-it is vulnerable to Improper Access Control
snipe-it is vulnerable to Cross-Site Request Forgery (CSRF)
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
snipe-it is vulnerable to Improper Access Control
snipe-it is vulnerable to Server-Side Request Forgery (SSRF)
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
snipe-it is vulnerable to Cross-Site Request Forgery (CSRF)
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
snipe-it is vulnerable to Cross-Site Request Forgery (CSRF)