Grokability
Monthly
Server-side request forgery in Snipe-IT before 8.7.0 allows an authenticated low-privileged attacker to pivot the application server against internal network resources, cloud metadata endpoints, or arbitrary external targets. The vulnerability stems from TCPDF's writeHTML() processing unsanitized img tag injection through the employee_num field in the asset acceptance PDF generator. Exploitation is deferred until a victim user signs an asset acceptance form, at which point the server makes an outbound HTTP(S) request to the attacker-controlled URL embedded in the rendered PDF. A proof-of-concept exists per SSVC data; no active exploitation has been confirmed in CISA KEV.
Account takeover in Snipe-IT before 8.7.0 allows low-privileged identity-provider users to hijack arbitrary Snipe-IT accounts by registering IdP usernames that are case or Unicode accent variants of existing victim usernames. The vulnerability exploits MySQL's default utf8mb4_unicode_ci collation, which conflates these variants during database lookups, enabling an attacker to be matched to a different user's record across all federated authentication paths - SAML, LDAP, and OAuth. Vendor-released patch 8.7.0 resolves the issue; no public exploit code or active exploitation has been identified at time of analysis.
Inventory integrity corruption in Snipe-IT ≤8.6.3 allows authenticated users holding consumable-checkout permission to over-allocate stock by exploiting a TOCTOU race condition in the API checkout endpoint. Concurrent POST requests to /api/v1/consumables/{consumable_id}/checkout each pass the pre-transaction availability check before either commits, enabling both to write checkout records and drive remaining inventory negative (e.g., a unit with 1 remaining ends at -1). Fixed in 8.7.0 via database row locking inside the transaction; no confirmed active exploitation at time of analysis, though proof-of-concept feasibility is noted by SSVC.
The asset update API endpoint in Snipe-IT before 8.7.0 allows authenticated users with only edit permission to bypass explicitly denied checkout authorization by submitting assignment parameters directly to PATCH /api/v1/hardware/{id}. This missing authorization check (CWE-862) permits affected users to reassign assets, skip mandatory check-in procedures, and tamper with custody audit trails without ever holding the assets.checkout permission. The patch commit (f71806b1e0efbd3bc2b6be61994ad2a5d5d6c206) adds an explicit Gate::allows('checkout') guard and an availableForCheckout() status check to the update path. No public exploit identified at time of analysis.
Snipe-IT through version 8.6.4 exposes protected component inventory data to any authenticated user holding only the assets.view permission via a missing authorization check on the GET /api/v1/hardware/<asset-id>/assigned/components REST API endpoint. The components.view permission is incorrectly applied only to the available_actions.view flag in the API response rather than to the underlying component data, allowing enumeration of component IDs, names, assigned quantities, and notes that the permission model is designed to restrict. Vendor-released patch 8.7.0 resolves the issue; no public exploit code or active exploitation has been identified at time of analysis.
Snipe-IT before 8.7.0 fails to apply the CheckUserIsActivated middleware to the API middleware group, allowing deactivated accounts to retain full REST API access through their existing Laravel Passport personal access tokens. Any deactivated user whose token has not been explicitly revoked can continue reading and writing assets, users, and licenses at their prior permission level, bypassing the offboarding control that correctly blocks web sessions. The most critical escalation path lets a deactivated account previously holding users.edit permission PATCH its own activation flag via /api/v1/users/{id} to permanently re-enable itself. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 8.7.0.
Missing authorization on the POST /hardware/history endpoint in Snipe-IT before 8.7.0 allows any authenticated user to reassign arbitrary assets and inject fabricated entries into audit logs. By submitting a crafted CSV payload, a low-privileged attacker can silently transfer assets across organizational boundaries and corrupt the audit trail, undermining inventory accountability and chain-of-custody integrity. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis, though exploitation is trivially automatable for any authenticated account.
License key exposure in Snipe-IT before 8.7.0 allows any authenticated low-privilege user to bypass the viewKeys authorization gate and retrieve all product license keys stored in the system. Two distinct exploitation paths exist: bulk extraction via the CSV export endpoint and a key-validation oracle via observable API response discrepancies, making CWE-204 an accurate root-cause classification for the latter. No public exploit code or CISA KEV listing exists at time of analysis; the patch is available in version 8.7.0.
Encrypted custom field values in Snipe-IT before 8.7.0 are exposed in plaintext to authenticated users who lack the assets.view.encrypted_custom_fields permission - a missing authorization gate (CWE-862) on asset form rendering for listbox, textarea, markdown-textarea, and date/datetime picker field types. Any authenticated user holding assets.edit, assets.checkin, assets.checkout, or assets.audit permissions can open an asset form and read values that should be restricted by a separate granular permission. No public exploit code exists and no CISA KEV listing has been identified; risk is confined to insider or low-privilege authenticated users in environments storing sensitive data in encrypted custom fields.
Privilege escalation in Snipe-IT before 8.7.0 allows any authenticated user to register OAuth clients with attacker-controlled redirect URIs by directly accessing Laravel Passport's client management routes, which are not properly gated to administrative users. An attacker with any valid account can then social-engineer an administrator into approving a crafted OAuth consent screen, capturing the resulting authorization code and exchanging it for a bearer token inheriting full admin API permissions. The compounding risk is a token lifetime of up to 40 years, meaning harvested tokens remain valid far beyond typical credential rotation cycles without explicit revocation. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Server-side request forgery and arbitrary file read in Snipe-IT before 8.7.0 allow any authenticated user to exfiltrate sensitive server files - including the Laravel `.env` file containing `APP_KEY` - by injecting markdown image syntax into checkout acceptance note fields. The injected syntax survives HTML escaping, is expanded by the CommonMark parser, and subsequently resolved by the laravel-mail-auto-embed library via `file_get_contents()` (local paths) or `curl` (remote URLs) when email notifications are generated. Vendor-released patch is available in version 8.7.0; no public exploit has been identified at time of analysis, but compromise of `APP_KEY` can facilitate escalation to remote code execution via Laravel cookie/session decryption.
Tenant boundary violation in Snipe-IT ≤ 8.6.3 allows an authenticated low-privileged API user to create or relocate user accounts into company scopes outside their authorization. The REST API handlers Api\UsersController::store() and ::update() commit the user record to the database before filtering submitted company_id and company_ids[] values against the actor's permitted companies via Company::getIdsForCurrentUser(), making the post-hoc authorization check unable to undo the database write. On instances with null_company_is_floater=1 configured, the resulting misaligned account is persisted as a cross-company 'floater,' gaining visibility across all tenant boundaries. No public exploit has been identified at time of analysis, but the exploitation mechanics are described in sufficient detail in the GHSA advisory to reproduce without additional tooling.
Permanent image data destruction in Snipe-IT ≤8.6.3 results from unchecked return values on Laravel storage operations in ImageUploadRequest::handleImages(). When any authenticated user submits an image upload while the configured storage backend (S3, local filesystem, NFS) experiences a transient failure, the silently-returned false from Storage::put() is ignored - the prior image is deleted, and the database record is updated to reference a file that was never written. A symmetric defect in deleteExistingImage() compounds the problem by nulling the model's image field even when Storage::delete() fails, orphaning files on disk. The condition affects all image-carrying models routed through this handler and produces unrecoverable data loss requiring manual reconciliation. No public exploit has been identified at time of analysis.
Privilege escalation in Snipe-IT before 8.7.0 allows any authenticated user to bypass authorization controls by replaying signed Livewire component snapshots directly against the /livewire/update endpoint. Because authorization is enforced only at the HTTP route layer and not within Livewire component lifecycle methods, a low-privilege session holder can invoke protected admin operations including creating OAuth clients, minting personal access tokens, and reading sensitive administrative data. No active exploitation has been confirmed (no CISA KEV listing), but the vendor-confirmed fix is available in version 8.7.0.
Arbitrary file read and SSRF in Snipe-IT before 8.7.0 allow low-privileged users to exfiltrate sensitive server files - including .env credential files - via unsanitized EULA text fields. An attacker with category-edit permissions injects markdown image syntax or raw HTML img tags referencing local file paths or remote URLs; the mail auto-embed library resolves these references server-side during checkout confirmation email generation and returns the resolved content as email attachments. No public exploit has been identified at time of analysis, and a vendor patch is available at 8.7.0.
Stored CSS injection in Snipe-IT before 8.7.0 lets a superuser plant malicious CSS in the Custom CSS branding setting that executes in every other superuser's browser, exfiltrating their CSRF tokens and enabling account takeover. The flawed sanitizer HTML-encoded input but then selectively reversed the encoding on '>' and '"' while never filtering @import or url(), permitting attribute-selector rules to leak tokens character-by-character. Publicly available exploit code exists via the VulnCheck advisory; no public exploit identified as actively exploited, and no EPSS/KEV signal was provided.
Denial of service in Snipe-IT before 8.7.1 allows authenticated users to exhaust PHP worker CPU by submitting arbitrarily large values in the note field of the POST /account/accept/{acceptance} endpoint. The unbounded input is passed directly to synchronous CommonMark markdown rendering during acceptance notification email generation, consuming worker CPU proportional to input size on every request. No public exploit code has been identified at time of analysis, but the attack is straightforward for any authenticated user and requires no special privileges beyond a valid account.
Remote code execution in Snipe-IT before 8.7.0 allows authenticated superadministrators to execute arbitrary OS commands on the server by uploading a crafted backup archive and triggering a restore. The vulnerability stems from Snipe-IT piping SQL backup content directly into the MySQL/MariaDB command-line client without the --binary-mode flag, causing the client to interpret backslash escape sequences (e.g., \!) as local shell commands rather than SQL. Successful exploitation exposes sensitive application secrets including database credentials and APP_KEY, and permits modification of any file writable by the web application process. No public exploit or KEV listing has been identified at time of analysis.
Authorization bypass in Snipe-IT's bulk delete endpoint (all versions before 8.6.3) allows restricted authenticated users to soft-delete user accounts outside their authorized management scope by supplying arbitrary user IDs in a bulk delete request. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR): the endpoint accepts attacker-controlled user IDs without validating them against the requesting user's permitted scope. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Cross-company authorization bypass in Snipe-IT before 8.6.2 allows authenticated users with the reports.view permission to manipulate checkout-acceptance records belonging to other companies in multi-tenant deployments. By enumerating sequential acceptance IDs and exploiting a null check defect on the legacy users.company_id column, an attacker can soft-delete acceptance records or trigger unsolicited reminder emails across company boundaries. Vendor-released patch v8.6.2 is available; no public exploit or active exploitation has been identified at time of analysis.
Insecure direct object reference in Snipe-IT prior to 8.6.3 allows any authenticated low-privilege user to read signed EULA documents belonging to other users by exploiting inconsistent authorization enforcement across two Laravel controllers. The attacker calls /api/v1/users/{target_id}/eulas to learn the target's randomized EULA filename, then retrieves the file via the /account/stored-eula-file/{filename} route, which bypasses the stricter checks enforced by the primary /stored-eula-file/{filename} endpoint. No public exploit has been identified at time of analysis, and the vendor has released a fix in version 8.6.3.
Incorrect authorization in Snipe-IT prior to 8.6.3 allows company-scoped authenticated users operating in FMCS floater mode to cross multi-tenancy boundaries and access, modify, or merge user records associated with no company (null company_id). Affected API endpoints expose cross-tenant personal data and license assignments while bulk edit and merge actions permit unauthorized profile modification and soft-deletion with asset transfer. No public exploit or KEV listing has been identified, but the CVSS 4.0 score of 7.6 reflects the high confidentiality and integrity impact for multi-tenant deployments with floater mode enabled.
Broken authorization in Snipe-IT before 8.6.2 lets an authenticated non-admin user who holds users.view and users.edit - but explicitly not users.delete - soft-delete other non-admin user accounts by POSTing delete_user=1 to /users/bulksave. The root cause is that BulkUsersController::destroy() checks only the 'update' authorization, so the delete permission gate is never enforced. No public exploit identified at time of analysis, and it is not listed in CISA KEV.
Improper permission handling in Snipe-IT before 8.6.0 lets a privileged user strip another user's administrative or granular permissions when editing their account. Because UsersController::update() treats a missing permissions field as a sparse payload rather than a no-op, an administrator editing another administrator — or any user holding users.edit editing a regular account — can silently wipe the target's privileges. No public exploit identified at time of analysis; this is an authenticated integrity/availability issue rather than a remote takeover.
Authorization bypass in Snipe-IT allows authenticated low-privileged users to move maintenance records to assets outside their company scope by manipulating the asset_id field during PATCH/PUT requests on /api/v1/maintenances/{id}. The vulnerability affects versions before 8.6.2 and is fixed in that release. EPSS remains low (0.22%) with no known active exploitation or public proof-of-concept.
Arbitrary file read in Snipe-IT before 8.5.0 lets an authenticated user abuse the ActionlogController::displaySig endpoint, which concatenates the route's filename parameter into a private upload-directory path without sanitization, enabling relative path traversal (CWE-23) to read any file the web server process can access. The CVSS 4.0 base score is 7.1 with high confidentiality impact only; there is no public exploit identified at time of analysis and no CISA KEV listing. Because Snipe-IT stores database credentials and application secrets in web-readable files, the practical impact can extend beyond simple information disclosure toward full application compromise.
Privilege escalation via authorization bypass in Snipe-IT versions prior to 8.6.0 allows any authenticated user holding only the granular `users.edit` permission to disable administrator and superuser accounts through the bulk-edit endpoint, effectively locking all admins out of the instance. By toggling the `activated` and `ldap_import` flags on admin targets, a low-privileged actor denies admins both interactive login and password-reset recovery. No public exploit identified at time of analysis, but the upstream fix and detailed advisory disclose the exact attack surface.
Tenant isolation bypass in Snipe-IT's predefined kit checkout path allows an authenticated low-privileged user to assign company-A assets - including licenses, consumables, and accessories - to users belonging only to company B, circumventing the Full Multiple Company Support (FMCS) isolation that all other checkout paths enforce. The vulnerable service (App\Services\PredefinedKitCheckoutService) has lacked the canCheckoutTo() company-mismatch guard since the feature was introduced in 2019, placing every FMCS-enabled Snipe-IT instance prior to 8.7.2 at risk. No public exploit or active exploitation has been identified at time of analysis; the flaw was runtime-verified on v8.6.3 and code-inspected on v8.7.1.
Broken access control in Snipe-IT before version 8.7.0 allows authenticated users holding only the assets.files permission to upload and delete file attachments on Asset Model records, which are shared catalog objects that normally require the separate models.files permission. The flaw in AssetModelPolicy causes the files() authorization method to cascade from the wrong permission scope, creating an unintended privilege boundary bypass. In multi-company Snipe-IT deployments, this enables cross-tenant mutation of shared Asset Model file attachments; no public exploit has been identified at time of analysis.
Object-level authorization failure in Snipe-IT through 8.6.3 permits an authenticated user holding only the low-privilege `kits.edit` permission to attach Licenses, Consumables, Accessories, or Asset Models - resources they are explicitly denied (HTTP 403) from reading directly - to Predefined Kits via the updateLicense, updateConsumable, updateAccessory, and storeModel endpoints. The kit relation index then discloses the attached objects' names back to the attacker, yielding both unauthorized writes and limited information disclosure. This is the update-path counterpart to CVE-2026-55478, which patched only the store methods in 8.6.2, revealing a pattern of incomplete authorization fixes in this code area. No public exploit or KEV listing identified at time of analysis.
Stored XSS in Snipe-IT before 8.7.0 allows authenticated users holding departments.edit permission to plant malicious JavaScript in department names that executes in every department member's browser when they load the My Assets page. The flaw exists because DepartmentPresenter::formattedNameLink() omits HTML encoding in the fallback branch triggered when the viewing user lacks departments.view permission. Vendor-released patch 8.7.0 is available; no public exploit code has been identified at time of analysis.
Snipe-IT's consumables checkout API endpoint writes the checkout target user's identifier into the `created_by` audit column rather than the authenticated caller's identifier, poisoning the audit trail. Authenticated attackers holding only the `consumables.checkout` permission can silently attribute their checkout actions to any target user in the `consumables_users` pivot table, effectively laundering their operational footprint from the system's records. The fix is available in version 8.7.0; no public exploit or active exploitation has been identified at time of analysis.
Integrity corruption in Snipe-IT before 8.7.0 allows any authenticated user holding checkout permissions to bind live inventory records to soft-deleted users, assets, or locations via the REST API. By submitting POST requests to the hardware, component, or consumable checkout endpoints with IDs of trashed entities, attackers create orphaned database references that corrupt the asset ledger and undermine audit trail integrity. No public exploit code has been identified and the flaw is not listed in CISA KEV, but the network-reachable API and low privilege bar make this straightforward to abuse internally.
Cross-tenant information disclosure in Snipe-IT before 8.7.0 allows authenticated users with standard assets.view permission to read pending asset request records belonging to other companies when the Full Multiple Company Support feature is enabled. The GET /hardware/requested endpoint omits company scope filtering entirely, returning cross-tenant data including asset names, requester display names and profile links, locations, and expected check-in dates without requiring any parameter manipulation. No public exploit has been identified and no active exploitation is listed in CISA KEV; impact is bounded by what the endpoint exposes - operational metadata rather than credentials or full asset inventories.
Insecure direct object reference in Snipe-IT 7.0.12 through 8.6.3 allows any authenticated user holding the import permission to enumerate all Import records on the instance and retrieve preview data from files uploaded by other users. The Livewire importer component (App\Livewire\Importer) enforces permission only at component mount time but leaves individual record queries unscoped, so calling the selectFile($id) action with an arbitrary auto-incrementing integer bypasses ownership checks. In Full Multiple Companies Support (FMCS) deployments this crosses tenant boundaries; impact is limited to metadata and CSV preview rows (headers and first data row) rather than the complete uploaded file, but those rows commonly contain personal data, asset serials, and license keys. No public exploit or CISA KEV listing has been identified at time of analysis.
Authorization bypass in Snipe-IT's location print endpoints allows authenticated users holding only location view permission to retrieve records they are not authorized to access. The printassigned and printallassigned endpoints in LocationsController enforced authorization only at the Location model level, then passed all related Eloquent collections - users, assets, accessories, consumables, and components - directly to the Blade view without per-model Gate checks, exposing data that would be blocked on any other Snipe-IT route. Versions before 8.7.0 are affected; a vendor patch is available and no public exploit code has been identified.
Incorrect authorization in Snipe-IT 8.2.0-8.6.x lets any authenticated user holding the users.edit permission toggle the activated flag on arbitrary accounts - including admin and superuser accounts - by submitting a complete PUT request to the single-user web UI edit route /users/{id}. Because UsersController::update() assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, the unauthorized write persisted through to save(); deactivating a targeted admin account locks it out of the application until re-enabled by another privileged user. No data is disclosed, and the API and bulk-edit paths are unaffected; the issue is fully remediated in 8.7.0.
Open redirect in Snipe-IT 8.5.0-8.6.3 allows an unauthenticated attacker to silently forward an authenticated user's browser to an arbitrary external URL immediately after a successful SAML login. The SAML assertion-consumer endpoint (SamlController::acs, POST /saml/acs) stored the raw RelayState POST parameter directly into Laravel's url.intended session key with only CR/LF stripping applied, and the subsequent redirect()->intended() call emitted that value verbatim in the HTTP Location header. An attacker who tricks a victim into following a crafted IdP-initiated SSO link can redirect the victim to a credential-harvesting phishing site post-login, requiring no account on the target instance and no compromise of the identity provider. No public exploit or CISA KEV listing has been identified at time of analysis; vendor-released patch is available in 8.7.0.
Snipe-IT versions 4.2.0 through 8.6.3 allow any authenticated user with a web session to mint long-lived Laravel Passport bearer tokens via the auto-registered /oauth/personal-access-tokens route, even when an administrator has explicitly denied that user the self.api permission. The root cause is that Laravel Passport's OAuth routes carry only generic 'web' and 'auth:web' middleware, bypassing Snipe-IT's own can:self.api permission gate that protects the application's native token management endpoints. Crucially, the issued tokens remain subject to all existing per-endpoint authorization checks, so this is an authorization-control bypass that defeats administrative intent - not a privilege escalation. No public exploit has been identified at time of analysis, and a fix is available in version 8.7.0.
Snipe-IT before version 8.7.0 allows authenticated users to circumvent administrative asset request controls by submitting checkout requests directly to the POST /account/request/asset_model/{modelId} endpoint, which fails to validate the server-side `requestable` flag on asset models. This business logic flaw enables any authenticated user to request assets that administrators have explicitly restricted, undermining allocation and compliance controls enforced through the requestable designation. No public exploit code or active exploitation has been identified at time of analysis; CVSS 4.0 rates this at 5.3 Medium.
Incorrect authorization in Snipe-IT before 8.7.0 allows authenticated users holding the assets.audit permission to write audit log entries against assets belonging to other companies in multi-tenant deployments. The flaw stems from the asset audit endpoints relying exclusively on query-layer filtering for FMCS (multi-company scoping) rather than enforcing policy-layer authorization checks, meaning the tenant boundary can be bypassed by targeting cross-company asset identifiers directly. No public exploit code has been identified, and a vendor patch is available in version 8.7.0.
Snipe-IT before version 8.7.0 permanently destroys its database when a superuser uploads a corrupted or invalid ZIP archive to the backup restore endpoint, because the wipe operation executes before input validation occurs. The root cause is a validate-after-act ordering flaw (CWE-460): the restore workflow irreversibly clears the database first, then attempts to parse the archive - leaving no rollback path on failure. Exploitation requires superuser privileges and deliberate file upload (CVSS 4.0 PR:H/UI:P), but the consequence is total, unrecoverable data loss for the affected Snipe-IT instance.
Authorization scope bypass in Snipe-IT versions up to 8.6.3 allows an authenticated low-privilege user to send acceptance-reminder emails to users in foreign companies and permanently delete asset acceptance audit records across all companies in a multi-tenant installation. The flaw exists in two report endpoints whose company-isolation guard either was absent (pre-8.6.3) or contains a logic error that grants unconditional access to 'pivot-only' users - those whose scalar `users.company_id` column is NULL. Sequential integer acceptance IDs make cross-company record enumeration trivial. No public exploit has been identified and the CVE is not in CISA KEV; the vendor fix is available in version 8.7.0.
CSV formula injection in Snipe-IT's location-scoping report export allows an authenticated low-privileged user to plant spreadsheet formulas in free-text asset fields that execute when a superuser downloads and opens the report in Excel, LibreOffice Calc, or Google Sheets. The vulnerable endpoint GET /admin/settings/location-scoping-report.csv uses a bare fputcsv() call without the League\Csv\EscapeFormula sanitization that all other CSV exports in the application apply, creating an inconsistency exploitable for data exfiltration via HYPERLINK or WEBSERVICE formulas, or command execution via legacy DDE on Windows Excel. The flaw exists only in master-branch builds after 8.6.3 - it was never included in a tagged release - and is fixed in version 8.7.0.
Race condition in Snipe-IT ≤8.6.3 allows two concurrent checkout requests for the same available asset to both pass the availability check and both commit, corrupting the audit trail with duplicate checkout-history rows, a doubled checkout_counter, and two spurious CheckoutableCheckedOut events. Authenticated users holding the assets.checkout permission can trigger this by issuing precisely timed concurrent HTTP requests. The visible asset assignment remains singular, so the primary tracking record is not altered, but reconciliation, utilization reporting, and ITSM integrations that rely on event counts or the checkout_counter are affected. No public exploit has been identified and CVSS 4.0 scores this 2.1 (Low).
Cross-company asset acceptance report exposure in Snipe-IT before 8.7.0 allows authenticated users holding the reports.view permission to read pending asset acceptances belonging to other companies within the same multi-tenant instance. The unaccepted_assets report page and its CSV export endpoint lack per-company scoping on their database queries, so any user with the reports.view role can enumerate inventory details and assignee names across organizational boundaries. No public exploit exists at time of analysis; a vendor-released patch is available in version 8.7.0.
CSV formula injection in Snipe-IT through 8.6.3 allows authenticated low-privilege users to plant spreadsheet formulas in the unaccepted assets acceptance report export, which execute in the spreadsheet client of any privileged user who downloads and opens the file. The ReportsController::postAssetAcceptanceReport method builds its CSV output by hand without applying the League\Csv\EscapeFormula sanitizer already wired into the six sibling exports in the same controller, permitting injection of =, +, -, @, tab, or CR-prefixed values into free-text fields such as asset name, company name, category, model, or assignee. When a reports.view-privileged user opens the resulting file in Excel, LibreOffice Calc, or Google Sheets, injected functions such as HYPERLINK or WEBSERVICE can exfiltrate spreadsheet context to an attacker-controlled server; on legacy Windows Excel configurations with DDE enabled, arbitrary command execution on the victim's workstation is also achievable. Fixed in version 8.7.0; no public exploit identified at time of analysis.
Silent deletion failure in Snipe-IT before 8.7.0 causes attachment files to persist on disk despite administrators receiving success responses from both the web UI and REST API controllers. The root cause is an unchecked return value from Storage::delete() in UploadedFilesController::destroy() and Api\UploadedFilesController::destroy(), meaning file records are marked deleted and hidden from listings while the physical files remain on the server filesystem. Anyone with direct filesystem or backup access - including system administrators, backup operators, or post-compromise threat actors - can retrieve files an authorized admin believed had been permanently removed. No public exploit or active exploitation has been identified at time of analysis.
Snipe-IT 8.6.3 and earlier silently produce false compliance artifacts when the configured storage backend fails to write acceptance evidence files. In Account\AcceptanceController::store(), the return value of Storage::put() is never checked; if the storage layer returns false rather than throwing an exception, execution proceeds unconditionally to $acceptance->accept(), which stamps the record as complete, records signature and PDF filenames, creates the audit-log entry, and dispatches notifications - all referencing evidence files that were never persisted. The practical result is a compliance record whose audit trail appears valid but whose supporting documentation does not exist, a material risk in regulated environments using Snipe-IT for EULA acknowledgement or equipment-receipt workflows. No public exploit code exists and no active exploitation has been identified; the CVSS 4.0 score of 2.3 reflects the low real-world risk.
Missing authorization on the GET /hardware/{asset}/barcode endpoint in Snipe-IT before 8.7.0 allows any authenticated user to enumerate asset IDs and retrieve barcodes for arbitrary assets, including those belonging to other tenants and soft-deleted records. Authenticated attackers can iterate predictable integer asset IDs to harvest cross-company asset tags and inventory data in multi-tenant deployments, violating tenant isolation and soft-delete access controls. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the fix is version 8.7.0, confirmed by the vendor GHSA advisory.
Counter integrity corruption in Snipe-IT before 8.7.0 allows authenticated users to manipulate the assets.requests_counter field through two distinct abuse patterns: repeatedly invoking the cancel checkout endpoint without an active request drives the counter negative, while submitting duplicate checkout requests inflates it with phantom demand. The impact is confined to the integrity of the admin asset-request queue - administrators see a falsified count of pending checkout requests, which can cause misallocation of assets. No active exploitation (CISA KEV) or public proof-of-concept has been identified at time of analysis.
Server-side request forgery in Snipe-IT before 8.7.0 allows a super-admin to bypass the ExternalUrl webhook SSRF guard by supplying IPv6 transition addresses (NAT64, 6to4, or Teredo) that encode private IPv4 targets. The validation logic only checks IPv4 address representations, so transition-encoded addresses such as 64:ff9b::169.254.169.254 pass unchallenged, enabling the server to reach internal services or cloud metadata endpoints like the AWS IMDSv1 API. No public exploit or CISA KEV listing exists at time of analysis; the vendor-released fix is version 8.7.0.
Broken access control in Snipe-IT before v8.7.0 allows authenticated users holding only the `assets.edit` permission to restore soft-deleted assets via the bulk restore endpoint, directly reversing administrator deletions they are not authorized to undo. The `POST /hardware/bulkrestore` handler in `BulkAssetsController` incorrectly gated on `authorize('update', Asset::class)` rather than `authorize('delete', Asset::class)`, the check used by every other restore path in the codebase. No active exploitation is confirmed (not in CISA KEV) and no public exploit has been identified, but the attack surface is any authenticated edit-permission holder in an affected deployment.
Horizontal privilege escalation in Snipe-IT prior to 8.6.3 allows any authenticated company user to read asset maintenance records - including purchase costs, supplier details, asset tags, and notes - without holding asset view or maintenance permissions. The root cause is a missing `authorize()` call in `MaintenancesController.php show()`, which the company-scoped route-model binding did not compensate for since it only blocks cross-company access, not intra-company unauthorized reads. No public exploit has been identified at time of analysis; vendor-released patch is available in version 8.6.3.
Stored cross-site scripting in Snipe-IT prior to 8.6.2 allows an authenticated low-privilege user to inject arbitrary JavaScript via a crafted manufacturer or supplier name, which executes in the browser of any authenticated user who views the affected detail page. The CVSS 4.0 vector assigns SC:H/SI:H on the subsequent system, reflecting that a successful payload delivered to an administrator can yield full session compromise - including data exfiltration and action execution - against the Snipe-IT instance. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the vulnerability mechanism is fully disclosed via the public GitHub security advisory and fix commit.
Authorization bypass in Snipe-IT before 8.6.0 allows any authenticated low-privileged user to cancel other users' pending asset checkout requests by supplying arbitrary values in URL path segments. The checkout-request cancellation endpoint reads `cancel_by_admin` and `requestingUser` directly from user-controlled URL segments without server-side ownership validation, enabling any logged-in user to bypass request-ownership checks. Because asset and user identifiers are sequential integers, a determined attacker can enumerate the full ID space and systematically cancel every pending checkout request platform-wide, disrupting the asset-management workflow. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog; a vendor patch is confirmed in v8.6.0, reported by Tenable (TRA-2026-54).
Stored cross-site scripting (XSS) in Snipe-IT before 8.6.2 allows a low-privileged user with the assets.edit permission to plant a malicious javascript: URI inside a Markdown hyperlink in a custom textarea field. When any other user opens the affected asset detail page and clicks the crafted link, arbitrary JavaScript executes in their browser session. No public exploit code or active exploitation has been identified at time of analysis, and the vendor has released a patch in v8.6.2.
Incorrect authorization enforcement in Snipe-IT's API location creation endpoint allows an authenticated low-privilege user to create a child location under a parent location belonging to a different company, bypassing the intended multi-tenant isolation boundary. The vulnerability affects all Snipe-IT versions prior to 8.6.2 when both Full Multiple Companies Support and the scope_locations_fmcs option are simultaneously enabled. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog; real-world risk is constrained by the non-default configuration prerequisites and the requirement for authenticated access.
Missing authorization on Snipe-IT's asset request cancellation endpoint prior to version 8.6.0 allows any authenticated low-privileged user to cancel another user's pending asset requests by supplying a victim's user ID in the URL path segment. The cancel_by_admin path parameter is accepted without server-side privilege verification, constituting a CWE-862 (Missing Authorization) flaw - effectively a broken object-level authorization issue on an administrative action. No public exploit has been identified at time of analysis, and CVSS 4.0 scoring (5.3) reflects limited scope: integrity-only impact with no data exposure or availability loss.
An authorization bypass in Snipe-IT before 8.6.2 allows low-privilege users with kit edit permissions to attach licenses, consumables, or accessories they are not authorized to view into predefined kits. No active exploitation or public exploit code has been identified.
Server-side request forgery in Snipe-IT before 8.7.0 allows an authenticated low-privileged attacker to pivot the application server against internal network resources, cloud metadata endpoints, or arbitrary external targets. The vulnerability stems from TCPDF's writeHTML() processing unsanitized img tag injection through the employee_num field in the asset acceptance PDF generator. Exploitation is deferred until a victim user signs an asset acceptance form, at which point the server makes an outbound HTTP(S) request to the attacker-controlled URL embedded in the rendered PDF. A proof-of-concept exists per SSVC data; no active exploitation has been confirmed in CISA KEV.
Account takeover in Snipe-IT before 8.7.0 allows low-privileged identity-provider users to hijack arbitrary Snipe-IT accounts by registering IdP usernames that are case or Unicode accent variants of existing victim usernames. The vulnerability exploits MySQL's default utf8mb4_unicode_ci collation, which conflates these variants during database lookups, enabling an attacker to be matched to a different user's record across all federated authentication paths - SAML, LDAP, and OAuth. Vendor-released patch 8.7.0 resolves the issue; no public exploit code or active exploitation has been identified at time of analysis.
Inventory integrity corruption in Snipe-IT ≤8.6.3 allows authenticated users holding consumable-checkout permission to over-allocate stock by exploiting a TOCTOU race condition in the API checkout endpoint. Concurrent POST requests to /api/v1/consumables/{consumable_id}/checkout each pass the pre-transaction availability check before either commits, enabling both to write checkout records and drive remaining inventory negative (e.g., a unit with 1 remaining ends at -1). Fixed in 8.7.0 via database row locking inside the transaction; no confirmed active exploitation at time of analysis, though proof-of-concept feasibility is noted by SSVC.
The asset update API endpoint in Snipe-IT before 8.7.0 allows authenticated users with only edit permission to bypass explicitly denied checkout authorization by submitting assignment parameters directly to PATCH /api/v1/hardware/{id}. This missing authorization check (CWE-862) permits affected users to reassign assets, skip mandatory check-in procedures, and tamper with custody audit trails without ever holding the assets.checkout permission. The patch commit (f71806b1e0efbd3bc2b6be61994ad2a5d5d6c206) adds an explicit Gate::allows('checkout') guard and an availableForCheckout() status check to the update path. No public exploit identified at time of analysis.
Snipe-IT through version 8.6.4 exposes protected component inventory data to any authenticated user holding only the assets.view permission via a missing authorization check on the GET /api/v1/hardware/<asset-id>/assigned/components REST API endpoint. The components.view permission is incorrectly applied only to the available_actions.view flag in the API response rather than to the underlying component data, allowing enumeration of component IDs, names, assigned quantities, and notes that the permission model is designed to restrict. Vendor-released patch 8.7.0 resolves the issue; no public exploit code or active exploitation has been identified at time of analysis.
Snipe-IT before 8.7.0 fails to apply the CheckUserIsActivated middleware to the API middleware group, allowing deactivated accounts to retain full REST API access through their existing Laravel Passport personal access tokens. Any deactivated user whose token has not been explicitly revoked can continue reading and writing assets, users, and licenses at their prior permission level, bypassing the offboarding control that correctly blocks web sessions. The most critical escalation path lets a deactivated account previously holding users.edit permission PATCH its own activation flag via /api/v1/users/{id} to permanently re-enable itself. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 8.7.0.
Missing authorization on the POST /hardware/history endpoint in Snipe-IT before 8.7.0 allows any authenticated user to reassign arbitrary assets and inject fabricated entries into audit logs. By submitting a crafted CSV payload, a low-privileged attacker can silently transfer assets across organizational boundaries and corrupt the audit trail, undermining inventory accountability and chain-of-custody integrity. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis, though exploitation is trivially automatable for any authenticated account.
License key exposure in Snipe-IT before 8.7.0 allows any authenticated low-privilege user to bypass the viewKeys authorization gate and retrieve all product license keys stored in the system. Two distinct exploitation paths exist: bulk extraction via the CSV export endpoint and a key-validation oracle via observable API response discrepancies, making CWE-204 an accurate root-cause classification for the latter. No public exploit code or CISA KEV listing exists at time of analysis; the patch is available in version 8.7.0.
Encrypted custom field values in Snipe-IT before 8.7.0 are exposed in plaintext to authenticated users who lack the assets.view.encrypted_custom_fields permission - a missing authorization gate (CWE-862) on asset form rendering for listbox, textarea, markdown-textarea, and date/datetime picker field types. Any authenticated user holding assets.edit, assets.checkin, assets.checkout, or assets.audit permissions can open an asset form and read values that should be restricted by a separate granular permission. No public exploit code exists and no CISA KEV listing has been identified; risk is confined to insider or low-privilege authenticated users in environments storing sensitive data in encrypted custom fields.
Privilege escalation in Snipe-IT before 8.7.0 allows any authenticated user to register OAuth clients with attacker-controlled redirect URIs by directly accessing Laravel Passport's client management routes, which are not properly gated to administrative users. An attacker with any valid account can then social-engineer an administrator into approving a crafted OAuth consent screen, capturing the resulting authorization code and exchanging it for a bearer token inheriting full admin API permissions. The compounding risk is a token lifetime of up to 40 years, meaning harvested tokens remain valid far beyond typical credential rotation cycles without explicit revocation. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Server-side request forgery and arbitrary file read in Snipe-IT before 8.7.0 allow any authenticated user to exfiltrate sensitive server files - including the Laravel `.env` file containing `APP_KEY` - by injecting markdown image syntax into checkout acceptance note fields. The injected syntax survives HTML escaping, is expanded by the CommonMark parser, and subsequently resolved by the laravel-mail-auto-embed library via `file_get_contents()` (local paths) or `curl` (remote URLs) when email notifications are generated. Vendor-released patch is available in version 8.7.0; no public exploit has been identified at time of analysis, but compromise of `APP_KEY` can facilitate escalation to remote code execution via Laravel cookie/session decryption.
Tenant boundary violation in Snipe-IT ≤ 8.6.3 allows an authenticated low-privileged API user to create or relocate user accounts into company scopes outside their authorization. The REST API handlers Api\UsersController::store() and ::update() commit the user record to the database before filtering submitted company_id and company_ids[] values against the actor's permitted companies via Company::getIdsForCurrentUser(), making the post-hoc authorization check unable to undo the database write. On instances with null_company_is_floater=1 configured, the resulting misaligned account is persisted as a cross-company 'floater,' gaining visibility across all tenant boundaries. No public exploit has been identified at time of analysis, but the exploitation mechanics are described in sufficient detail in the GHSA advisory to reproduce without additional tooling.
Permanent image data destruction in Snipe-IT ≤8.6.3 results from unchecked return values on Laravel storage operations in ImageUploadRequest::handleImages(). When any authenticated user submits an image upload while the configured storage backend (S3, local filesystem, NFS) experiences a transient failure, the silently-returned false from Storage::put() is ignored - the prior image is deleted, and the database record is updated to reference a file that was never written. A symmetric defect in deleteExistingImage() compounds the problem by nulling the model's image field even when Storage::delete() fails, orphaning files on disk. The condition affects all image-carrying models routed through this handler and produces unrecoverable data loss requiring manual reconciliation. No public exploit has been identified at time of analysis.
Privilege escalation in Snipe-IT before 8.7.0 allows any authenticated user to bypass authorization controls by replaying signed Livewire component snapshots directly against the /livewire/update endpoint. Because authorization is enforced only at the HTTP route layer and not within Livewire component lifecycle methods, a low-privilege session holder can invoke protected admin operations including creating OAuth clients, minting personal access tokens, and reading sensitive administrative data. No active exploitation has been confirmed (no CISA KEV listing), but the vendor-confirmed fix is available in version 8.7.0.
Arbitrary file read and SSRF in Snipe-IT before 8.7.0 allow low-privileged users to exfiltrate sensitive server files - including .env credential files - via unsanitized EULA text fields. An attacker with category-edit permissions injects markdown image syntax or raw HTML img tags referencing local file paths or remote URLs; the mail auto-embed library resolves these references server-side during checkout confirmation email generation and returns the resolved content as email attachments. No public exploit has been identified at time of analysis, and a vendor patch is available at 8.7.0.
Stored CSS injection in Snipe-IT before 8.7.0 lets a superuser plant malicious CSS in the Custom CSS branding setting that executes in every other superuser's browser, exfiltrating their CSRF tokens and enabling account takeover. The flawed sanitizer HTML-encoded input but then selectively reversed the encoding on '>' and '"' while never filtering @import or url(), permitting attribute-selector rules to leak tokens character-by-character. Publicly available exploit code exists via the VulnCheck advisory; no public exploit identified as actively exploited, and no EPSS/KEV signal was provided.
Denial of service in Snipe-IT before 8.7.1 allows authenticated users to exhaust PHP worker CPU by submitting arbitrarily large values in the note field of the POST /account/accept/{acceptance} endpoint. The unbounded input is passed directly to synchronous CommonMark markdown rendering during acceptance notification email generation, consuming worker CPU proportional to input size on every request. No public exploit code has been identified at time of analysis, but the attack is straightforward for any authenticated user and requires no special privileges beyond a valid account.
Remote code execution in Snipe-IT before 8.7.0 allows authenticated superadministrators to execute arbitrary OS commands on the server by uploading a crafted backup archive and triggering a restore. The vulnerability stems from Snipe-IT piping SQL backup content directly into the MySQL/MariaDB command-line client without the --binary-mode flag, causing the client to interpret backslash escape sequences (e.g., \!) as local shell commands rather than SQL. Successful exploitation exposes sensitive application secrets including database credentials and APP_KEY, and permits modification of any file writable by the web application process. No public exploit or KEV listing has been identified at time of analysis.
Authorization bypass in Snipe-IT's bulk delete endpoint (all versions before 8.6.3) allows restricted authenticated users to soft-delete user accounts outside their authorized management scope by supplying arbitrary user IDs in a bulk delete request. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR): the endpoint accepts attacker-controlled user IDs without validating them against the requesting user's permitted scope. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Cross-company authorization bypass in Snipe-IT before 8.6.2 allows authenticated users with the reports.view permission to manipulate checkout-acceptance records belonging to other companies in multi-tenant deployments. By enumerating sequential acceptance IDs and exploiting a null check defect on the legacy users.company_id column, an attacker can soft-delete acceptance records or trigger unsolicited reminder emails across company boundaries. Vendor-released patch v8.6.2 is available; no public exploit or active exploitation has been identified at time of analysis.
Insecure direct object reference in Snipe-IT prior to 8.6.3 allows any authenticated low-privilege user to read signed EULA documents belonging to other users by exploiting inconsistent authorization enforcement across two Laravel controllers. The attacker calls /api/v1/users/{target_id}/eulas to learn the target's randomized EULA filename, then retrieves the file via the /account/stored-eula-file/{filename} route, which bypasses the stricter checks enforced by the primary /stored-eula-file/{filename} endpoint. No public exploit has been identified at time of analysis, and the vendor has released a fix in version 8.6.3.
Incorrect authorization in Snipe-IT prior to 8.6.3 allows company-scoped authenticated users operating in FMCS floater mode to cross multi-tenancy boundaries and access, modify, or merge user records associated with no company (null company_id). Affected API endpoints expose cross-tenant personal data and license assignments while bulk edit and merge actions permit unauthorized profile modification and soft-deletion with asset transfer. No public exploit or KEV listing has been identified, but the CVSS 4.0 score of 7.6 reflects the high confidentiality and integrity impact for multi-tenant deployments with floater mode enabled.
Broken authorization in Snipe-IT before 8.6.2 lets an authenticated non-admin user who holds users.view and users.edit - but explicitly not users.delete - soft-delete other non-admin user accounts by POSTing delete_user=1 to /users/bulksave. The root cause is that BulkUsersController::destroy() checks only the 'update' authorization, so the delete permission gate is never enforced. No public exploit identified at time of analysis, and it is not listed in CISA KEV.
Improper permission handling in Snipe-IT before 8.6.0 lets a privileged user strip another user's administrative or granular permissions when editing their account. Because UsersController::update() treats a missing permissions field as a sparse payload rather than a no-op, an administrator editing another administrator — or any user holding users.edit editing a regular account — can silently wipe the target's privileges. No public exploit identified at time of analysis; this is an authenticated integrity/availability issue rather than a remote takeover.
Authorization bypass in Snipe-IT allows authenticated low-privileged users to move maintenance records to assets outside their company scope by manipulating the asset_id field during PATCH/PUT requests on /api/v1/maintenances/{id}. The vulnerability affects versions before 8.6.2 and is fixed in that release. EPSS remains low (0.22%) with no known active exploitation or public proof-of-concept.
Arbitrary file read in Snipe-IT before 8.5.0 lets an authenticated user abuse the ActionlogController::displaySig endpoint, which concatenates the route's filename parameter into a private upload-directory path without sanitization, enabling relative path traversal (CWE-23) to read any file the web server process can access. The CVSS 4.0 base score is 7.1 with high confidentiality impact only; there is no public exploit identified at time of analysis and no CISA KEV listing. Because Snipe-IT stores database credentials and application secrets in web-readable files, the practical impact can extend beyond simple information disclosure toward full application compromise.
Privilege escalation via authorization bypass in Snipe-IT versions prior to 8.6.0 allows any authenticated user holding only the granular `users.edit` permission to disable administrator and superuser accounts through the bulk-edit endpoint, effectively locking all admins out of the instance. By toggling the `activated` and `ldap_import` flags on admin targets, a low-privileged actor denies admins both interactive login and password-reset recovery. No public exploit identified at time of analysis, but the upstream fix and detailed advisory disclose the exact attack surface.
Tenant isolation bypass in Snipe-IT's predefined kit checkout path allows an authenticated low-privileged user to assign company-A assets - including licenses, consumables, and accessories - to users belonging only to company B, circumventing the Full Multiple Company Support (FMCS) isolation that all other checkout paths enforce. The vulnerable service (App\Services\PredefinedKitCheckoutService) has lacked the canCheckoutTo() company-mismatch guard since the feature was introduced in 2019, placing every FMCS-enabled Snipe-IT instance prior to 8.7.2 at risk. No public exploit or active exploitation has been identified at time of analysis; the flaw was runtime-verified on v8.6.3 and code-inspected on v8.7.1.
Broken access control in Snipe-IT before version 8.7.0 allows authenticated users holding only the assets.files permission to upload and delete file attachments on Asset Model records, which are shared catalog objects that normally require the separate models.files permission. The flaw in AssetModelPolicy causes the files() authorization method to cascade from the wrong permission scope, creating an unintended privilege boundary bypass. In multi-company Snipe-IT deployments, this enables cross-tenant mutation of shared Asset Model file attachments; no public exploit has been identified at time of analysis.
Object-level authorization failure in Snipe-IT through 8.6.3 permits an authenticated user holding only the low-privilege `kits.edit` permission to attach Licenses, Consumables, Accessories, or Asset Models - resources they are explicitly denied (HTTP 403) from reading directly - to Predefined Kits via the updateLicense, updateConsumable, updateAccessory, and storeModel endpoints. The kit relation index then discloses the attached objects' names back to the attacker, yielding both unauthorized writes and limited information disclosure. This is the update-path counterpart to CVE-2026-55478, which patched only the store methods in 8.6.2, revealing a pattern of incomplete authorization fixes in this code area. No public exploit or KEV listing identified at time of analysis.
Stored XSS in Snipe-IT before 8.7.0 allows authenticated users holding departments.edit permission to plant malicious JavaScript in department names that executes in every department member's browser when they load the My Assets page. The flaw exists because DepartmentPresenter::formattedNameLink() omits HTML encoding in the fallback branch triggered when the viewing user lacks departments.view permission. Vendor-released patch 8.7.0 is available; no public exploit code has been identified at time of analysis.
Snipe-IT's consumables checkout API endpoint writes the checkout target user's identifier into the `created_by` audit column rather than the authenticated caller's identifier, poisoning the audit trail. Authenticated attackers holding only the `consumables.checkout` permission can silently attribute their checkout actions to any target user in the `consumables_users` pivot table, effectively laundering their operational footprint from the system's records. The fix is available in version 8.7.0; no public exploit or active exploitation has been identified at time of analysis.
Integrity corruption in Snipe-IT before 8.7.0 allows any authenticated user holding checkout permissions to bind live inventory records to soft-deleted users, assets, or locations via the REST API. By submitting POST requests to the hardware, component, or consumable checkout endpoints with IDs of trashed entities, attackers create orphaned database references that corrupt the asset ledger and undermine audit trail integrity. No public exploit code has been identified and the flaw is not listed in CISA KEV, but the network-reachable API and low privilege bar make this straightforward to abuse internally.
Cross-tenant information disclosure in Snipe-IT before 8.7.0 allows authenticated users with standard assets.view permission to read pending asset request records belonging to other companies when the Full Multiple Company Support feature is enabled. The GET /hardware/requested endpoint omits company scope filtering entirely, returning cross-tenant data including asset names, requester display names and profile links, locations, and expected check-in dates without requiring any parameter manipulation. No public exploit has been identified and no active exploitation is listed in CISA KEV; impact is bounded by what the endpoint exposes - operational metadata rather than credentials or full asset inventories.
Insecure direct object reference in Snipe-IT 7.0.12 through 8.6.3 allows any authenticated user holding the import permission to enumerate all Import records on the instance and retrieve preview data from files uploaded by other users. The Livewire importer component (App\Livewire\Importer) enforces permission only at component mount time but leaves individual record queries unscoped, so calling the selectFile($id) action with an arbitrary auto-incrementing integer bypasses ownership checks. In Full Multiple Companies Support (FMCS) deployments this crosses tenant boundaries; impact is limited to metadata and CSV preview rows (headers and first data row) rather than the complete uploaded file, but those rows commonly contain personal data, asset serials, and license keys. No public exploit or CISA KEV listing has been identified at time of analysis.
Authorization bypass in Snipe-IT's location print endpoints allows authenticated users holding only location view permission to retrieve records they are not authorized to access. The printassigned and printallassigned endpoints in LocationsController enforced authorization only at the Location model level, then passed all related Eloquent collections - users, assets, accessories, consumables, and components - directly to the Blade view without per-model Gate checks, exposing data that would be blocked on any other Snipe-IT route. Versions before 8.7.0 are affected; a vendor patch is available and no public exploit code has been identified.
Incorrect authorization in Snipe-IT 8.2.0-8.6.x lets any authenticated user holding the users.edit permission toggle the activated flag on arbitrary accounts - including admin and superuser accounts - by submitting a complete PUT request to the single-user web UI edit route /users/{id}. Because UsersController::update() assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, the unauthorized write persisted through to save(); deactivating a targeted admin account locks it out of the application until re-enabled by another privileged user. No data is disclosed, and the API and bulk-edit paths are unaffected; the issue is fully remediated in 8.7.0.
Open redirect in Snipe-IT 8.5.0-8.6.3 allows an unauthenticated attacker to silently forward an authenticated user's browser to an arbitrary external URL immediately after a successful SAML login. The SAML assertion-consumer endpoint (SamlController::acs, POST /saml/acs) stored the raw RelayState POST parameter directly into Laravel's url.intended session key with only CR/LF stripping applied, and the subsequent redirect()->intended() call emitted that value verbatim in the HTTP Location header. An attacker who tricks a victim into following a crafted IdP-initiated SSO link can redirect the victim to a credential-harvesting phishing site post-login, requiring no account on the target instance and no compromise of the identity provider. No public exploit or CISA KEV listing has been identified at time of analysis; vendor-released patch is available in 8.7.0.
Snipe-IT versions 4.2.0 through 8.6.3 allow any authenticated user with a web session to mint long-lived Laravel Passport bearer tokens via the auto-registered /oauth/personal-access-tokens route, even when an administrator has explicitly denied that user the self.api permission. The root cause is that Laravel Passport's OAuth routes carry only generic 'web' and 'auth:web' middleware, bypassing Snipe-IT's own can:self.api permission gate that protects the application's native token management endpoints. Crucially, the issued tokens remain subject to all existing per-endpoint authorization checks, so this is an authorization-control bypass that defeats administrative intent - not a privilege escalation. No public exploit has been identified at time of analysis, and a fix is available in version 8.7.0.
Snipe-IT before version 8.7.0 allows authenticated users to circumvent administrative asset request controls by submitting checkout requests directly to the POST /account/request/asset_model/{modelId} endpoint, which fails to validate the server-side `requestable` flag on asset models. This business logic flaw enables any authenticated user to request assets that administrators have explicitly restricted, undermining allocation and compliance controls enforced through the requestable designation. No public exploit code or active exploitation has been identified at time of analysis; CVSS 4.0 rates this at 5.3 Medium.
Incorrect authorization in Snipe-IT before 8.7.0 allows authenticated users holding the assets.audit permission to write audit log entries against assets belonging to other companies in multi-tenant deployments. The flaw stems from the asset audit endpoints relying exclusively on query-layer filtering for FMCS (multi-company scoping) rather than enforcing policy-layer authorization checks, meaning the tenant boundary can be bypassed by targeting cross-company asset identifiers directly. No public exploit code has been identified, and a vendor patch is available in version 8.7.0.
Snipe-IT before version 8.7.0 permanently destroys its database when a superuser uploads a corrupted or invalid ZIP archive to the backup restore endpoint, because the wipe operation executes before input validation occurs. The root cause is a validate-after-act ordering flaw (CWE-460): the restore workflow irreversibly clears the database first, then attempts to parse the archive - leaving no rollback path on failure. Exploitation requires superuser privileges and deliberate file upload (CVSS 4.0 PR:H/UI:P), but the consequence is total, unrecoverable data loss for the affected Snipe-IT instance.
Authorization scope bypass in Snipe-IT versions up to 8.6.3 allows an authenticated low-privilege user to send acceptance-reminder emails to users in foreign companies and permanently delete asset acceptance audit records across all companies in a multi-tenant installation. The flaw exists in two report endpoints whose company-isolation guard either was absent (pre-8.6.3) or contains a logic error that grants unconditional access to 'pivot-only' users - those whose scalar `users.company_id` column is NULL. Sequential integer acceptance IDs make cross-company record enumeration trivial. No public exploit has been identified and the CVE is not in CISA KEV; the vendor fix is available in version 8.7.0.
CSV formula injection in Snipe-IT's location-scoping report export allows an authenticated low-privileged user to plant spreadsheet formulas in free-text asset fields that execute when a superuser downloads and opens the report in Excel, LibreOffice Calc, or Google Sheets. The vulnerable endpoint GET /admin/settings/location-scoping-report.csv uses a bare fputcsv() call without the League\Csv\EscapeFormula sanitization that all other CSV exports in the application apply, creating an inconsistency exploitable for data exfiltration via HYPERLINK or WEBSERVICE formulas, or command execution via legacy DDE on Windows Excel. The flaw exists only in master-branch builds after 8.6.3 - it was never included in a tagged release - and is fixed in version 8.7.0.
Race condition in Snipe-IT ≤8.6.3 allows two concurrent checkout requests for the same available asset to both pass the availability check and both commit, corrupting the audit trail with duplicate checkout-history rows, a doubled checkout_counter, and two spurious CheckoutableCheckedOut events. Authenticated users holding the assets.checkout permission can trigger this by issuing precisely timed concurrent HTTP requests. The visible asset assignment remains singular, so the primary tracking record is not altered, but reconciliation, utilization reporting, and ITSM integrations that rely on event counts or the checkout_counter are affected. No public exploit has been identified and CVSS 4.0 scores this 2.1 (Low).
Cross-company asset acceptance report exposure in Snipe-IT before 8.7.0 allows authenticated users holding the reports.view permission to read pending asset acceptances belonging to other companies within the same multi-tenant instance. The unaccepted_assets report page and its CSV export endpoint lack per-company scoping on their database queries, so any user with the reports.view role can enumerate inventory details and assignee names across organizational boundaries. No public exploit exists at time of analysis; a vendor-released patch is available in version 8.7.0.
CSV formula injection in Snipe-IT through 8.6.3 allows authenticated low-privilege users to plant spreadsheet formulas in the unaccepted assets acceptance report export, which execute in the spreadsheet client of any privileged user who downloads and opens the file. The ReportsController::postAssetAcceptanceReport method builds its CSV output by hand without applying the League\Csv\EscapeFormula sanitizer already wired into the six sibling exports in the same controller, permitting injection of =, +, -, @, tab, or CR-prefixed values into free-text fields such as asset name, company name, category, model, or assignee. When a reports.view-privileged user opens the resulting file in Excel, LibreOffice Calc, or Google Sheets, injected functions such as HYPERLINK or WEBSERVICE can exfiltrate spreadsheet context to an attacker-controlled server; on legacy Windows Excel configurations with DDE enabled, arbitrary command execution on the victim's workstation is also achievable. Fixed in version 8.7.0; no public exploit identified at time of analysis.
Silent deletion failure in Snipe-IT before 8.7.0 causes attachment files to persist on disk despite administrators receiving success responses from both the web UI and REST API controllers. The root cause is an unchecked return value from Storage::delete() in UploadedFilesController::destroy() and Api\UploadedFilesController::destroy(), meaning file records are marked deleted and hidden from listings while the physical files remain on the server filesystem. Anyone with direct filesystem or backup access - including system administrators, backup operators, or post-compromise threat actors - can retrieve files an authorized admin believed had been permanently removed. No public exploit or active exploitation has been identified at time of analysis.
Snipe-IT 8.6.3 and earlier silently produce false compliance artifacts when the configured storage backend fails to write acceptance evidence files. In Account\AcceptanceController::store(), the return value of Storage::put() is never checked; if the storage layer returns false rather than throwing an exception, execution proceeds unconditionally to $acceptance->accept(), which stamps the record as complete, records signature and PDF filenames, creates the audit-log entry, and dispatches notifications - all referencing evidence files that were never persisted. The practical result is a compliance record whose audit trail appears valid but whose supporting documentation does not exist, a material risk in regulated environments using Snipe-IT for EULA acknowledgement or equipment-receipt workflows. No public exploit code exists and no active exploitation has been identified; the CVSS 4.0 score of 2.3 reflects the low real-world risk.
Missing authorization on the GET /hardware/{asset}/barcode endpoint in Snipe-IT before 8.7.0 allows any authenticated user to enumerate asset IDs and retrieve barcodes for arbitrary assets, including those belonging to other tenants and soft-deleted records. Authenticated attackers can iterate predictable integer asset IDs to harvest cross-company asset tags and inventory data in multi-tenant deployments, violating tenant isolation and soft-delete access controls. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the fix is version 8.7.0, confirmed by the vendor GHSA advisory.
Counter integrity corruption in Snipe-IT before 8.7.0 allows authenticated users to manipulate the assets.requests_counter field through two distinct abuse patterns: repeatedly invoking the cancel checkout endpoint without an active request drives the counter negative, while submitting duplicate checkout requests inflates it with phantom demand. The impact is confined to the integrity of the admin asset-request queue - administrators see a falsified count of pending checkout requests, which can cause misallocation of assets. No active exploitation (CISA KEV) or public proof-of-concept has been identified at time of analysis.
Server-side request forgery in Snipe-IT before 8.7.0 allows a super-admin to bypass the ExternalUrl webhook SSRF guard by supplying IPv6 transition addresses (NAT64, 6to4, or Teredo) that encode private IPv4 targets. The validation logic only checks IPv4 address representations, so transition-encoded addresses such as 64:ff9b::169.254.169.254 pass unchallenged, enabling the server to reach internal services or cloud metadata endpoints like the AWS IMDSv1 API. No public exploit or CISA KEV listing exists at time of analysis; the vendor-released fix is version 8.7.0.
Broken access control in Snipe-IT before v8.7.0 allows authenticated users holding only the `assets.edit` permission to restore soft-deleted assets via the bulk restore endpoint, directly reversing administrator deletions they are not authorized to undo. The `POST /hardware/bulkrestore` handler in `BulkAssetsController` incorrectly gated on `authorize('update', Asset::class)` rather than `authorize('delete', Asset::class)`, the check used by every other restore path in the codebase. No active exploitation is confirmed (not in CISA KEV) and no public exploit has been identified, but the attack surface is any authenticated edit-permission holder in an affected deployment.
Horizontal privilege escalation in Snipe-IT prior to 8.6.3 allows any authenticated company user to read asset maintenance records - including purchase costs, supplier details, asset tags, and notes - without holding asset view or maintenance permissions. The root cause is a missing `authorize()` call in `MaintenancesController.php show()`, which the company-scoped route-model binding did not compensate for since it only blocks cross-company access, not intra-company unauthorized reads. No public exploit has been identified at time of analysis; vendor-released patch is available in version 8.6.3.
Stored cross-site scripting in Snipe-IT prior to 8.6.2 allows an authenticated low-privilege user to inject arbitrary JavaScript via a crafted manufacturer or supplier name, which executes in the browser of any authenticated user who views the affected detail page. The CVSS 4.0 vector assigns SC:H/SI:H on the subsequent system, reflecting that a successful payload delivered to an administrator can yield full session compromise - including data exfiltration and action execution - against the Snipe-IT instance. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the vulnerability mechanism is fully disclosed via the public GitHub security advisory and fix commit.
Authorization bypass in Snipe-IT before 8.6.0 allows any authenticated low-privileged user to cancel other users' pending asset checkout requests by supplying arbitrary values in URL path segments. The checkout-request cancellation endpoint reads `cancel_by_admin` and `requestingUser` directly from user-controlled URL segments without server-side ownership validation, enabling any logged-in user to bypass request-ownership checks. Because asset and user identifiers are sequential integers, a determined attacker can enumerate the full ID space and systematically cancel every pending checkout request platform-wide, disrupting the asset-management workflow. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog; a vendor patch is confirmed in v8.6.0, reported by Tenable (TRA-2026-54).
Stored cross-site scripting (XSS) in Snipe-IT before 8.6.2 allows a low-privileged user with the assets.edit permission to plant a malicious javascript: URI inside a Markdown hyperlink in a custom textarea field. When any other user opens the affected asset detail page and clicks the crafted link, arbitrary JavaScript executes in their browser session. No public exploit code or active exploitation has been identified at time of analysis, and the vendor has released a patch in v8.6.2.
Incorrect authorization enforcement in Snipe-IT's API location creation endpoint allows an authenticated low-privilege user to create a child location under a parent location belonging to a different company, bypassing the intended multi-tenant isolation boundary. The vulnerability affects all Snipe-IT versions prior to 8.6.2 when both Full Multiple Companies Support and the scope_locations_fmcs option are simultaneously enabled. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog; real-world risk is constrained by the non-default configuration prerequisites and the requirement for authenticated access.
Missing authorization on Snipe-IT's asset request cancellation endpoint prior to version 8.6.0 allows any authenticated low-privileged user to cancel another user's pending asset requests by supplying a victim's user ID in the URL path segment. The cancel_by_admin path parameter is accepted without server-side privilege verification, constituting a CWE-862 (Missing Authorization) flaw - effectively a broken object-level authorization issue on an administrative action. No public exploit has been identified at time of analysis, and CVSS 4.0 scoring (5.3) reflects limited scope: integrity-only impact with no data exposure or availability loss.
An authorization bypass in Snipe-IT before 8.6.2 allows low-privilege users with kit edit permissions to attach licenses, consumables, or accessories they are not authorized to view into predefined kits. No active exploitation or public exploit code has been identified.