Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
74 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Snipe-IT S3 signature image retrieval lacks authorization before temporary URL. On S3-backed deployments, authenticated users who know a signature filename can obtain a 5-minute signed S3 URL because the S3 branch returns before the authorize() call used by the local-file branch. Key evidence routes/web.php:135-143; app/Http/Controllers/ActionlogController.php:16-44; app/Http/Controllers/Account/AcceptanceController.php:160,175; app/Listeners/LogListener.php:56; app/Http/Transformers/ActionlogsTransformer.php:188 Patches Patched in https://github.com/grokability/snipe-it/commit/ded6515cbc27a28f07395da318483c2e96263259 Credit Disclosed by Ikaro tiagonas
Recommended action: Upgrade to 8.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability was identified in Snipe-IT v8.4.0 (build 21280-g91a95dbc6) that allows any authenticated user with generic asset edit permissions to delete files attached to any asset in the system, regardless of ownership or company assignment. This constitutes an Insecure Direct Object Reference (IDOR) vulnerability caused by a class-level authorization check in the file deletion endpoint, where an instance-level check is required. The vulnerability exists in both the web and API controllers, affecting all Snipe-IT installations running version 8.4.0 and potentially earlier versions. Patches Patched in https://github.com/grokability/snipe-it/commit/8bc7d50e35d93eee5a0d48b4923e497937cf93fd
Recommended action: Upgrade to 8.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The store() method in both the web and API UsersController only strips the superuser permission when a non-superuser creates a user. It does not strip the admin permission. This allows any authenticated user with the users.create permission to create a new user with full admin privileges. The users.create permission may commonly be delegated to HR staff, department leads, or similar roles. Patches Patched in aea3877718
Recommended action: Upgrade to 8.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The BulkAssetsController::update() method accepts companyid directly from user input without calling Company::getIdForCurrentUser(), the standard company-scoping function used by every other controller in the codebase. A non-superadmin user can move assets across company boundaries, breaking multi-tenancy isolation. Patches Patched in https://github.com/grokability/snipe-it/commit/d58fda626e8febfeff4cabbc20ba03edfc411e18
Recommended action: Upgrade to 8.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user who can edit other users could reset a superadmin's 2FA. Patches Patched in 8.5.0
Recommended action: Upgrade to 8.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The CSV user import in update mode bypasses user-edit authorization. A user with only the import permission can overwrite any non-admin user's email by uploading a CSV, then trigger a password reset to take over the account. UserImporter.php checks the canEditAuthFields gate and tries to strip auth fields from the model: The unset()s operate on the model, but sanitizeItemForUpdating() rebuilds its array from $this-item (the raw CSV row), not from the model: The attacker's CSV values pass through untouched. For non-admin attacker vs. non-admin, non-superuser target, the gate returns true at AuthServiceProvider.php:137, so the unset() block never executes. The entire import path checks only $this-authorize('import') (ImportController.php:196); no users.edit check anywhere. The normal API route PATCH /api/v1/users/{id} correctly returns 403 for the same user. Attacker must have import privileges to exploit this, and that permission must be granted specifically and intentionally…
Recommended action: Upgrade to 8.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact POST /two-factor had no rate limiting, lockout, or attempt counter. An attacker with valid credentials can submit unlimited TOTP guesses. The TOTP implementation accepts the current code plus one step on either side (config/google2fa.php window=1), so at any instant 3 of 1,000,000 codes are accepted. After a correct guess the attacker holds a fully authenticated session. If the instance is configured with 2FA in optional mode (twofactorenabled='1'), the attacker can additionally disable 2FA via POST /account/profile with twofactoroptin=0. No OTP re-verification is required. The account is then accessible with the password alone on future logins. If 2FA is in required-for-all mode (='2'), the per-user opt-out path is closed and the impact stops at session-level account takeover. For an admin target, POST /api/v1/users/twofactorreset additionally clears another user's 2FA secret. Patches Patched in v8.6.0
Recommended action: Upgrade to 8.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability allows a non-admin user holding only the granular users.edit permission to lock every admin out of the instance by editing the activated flag (which determines whether or not a user can login) and the ldapimport flag, which determines whether or not the user can request a password reset. Patches Patched in https://github.com/grokability/snipe-it/commit/403f9c848b05274642f64450696bdcdc242a352a
Recommended action: Upgrade to 8.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user with only users.edit AND api permissions can send a PATCH to /api/v1/users/{theirownid} and grant themselves any permission except admin and superuser — for example assets.view, assets.create, reports.view, import, etc. Patches Patched in https://github.com/grokability/snipe-it/pull/19024
Recommended action: Upgrade to 8.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The GET /api/v1/{object}/selectlist API endpoint is missing an authorization check. Any user who can log into Snipe-IT - regardless of permissions - can retrieve a paginated list of all user accounts using only their web session cookie. No API token or elevated permissions are required. This exposes usernames, display names, employee numbers, and user IDs for every active account in the system if FMCS is not enabled, and within the company they belong to if FMCS is enabled. What an attacker can do with a valid login and zero permissions: - Enumerate all active user accounts by paginating through the endpoint - Harvest usernames for credential stuffing or password spray attacks - Collect employee numbers and full names for social engineering - Perform indirect email enumeration via the search parameter - Map user IDs for use in further enumeration against other endpoints This vulnerability is exploitable only by users who have a working login to the Snipe-IT system. Patches…
Recommended action: Upgrade to 8.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open redirect vulnerability in Snipe-IT allows attackers to redirect users to malicious sites via unvalidated HTTP Referer header stored in session variable. Impact - Phishing: Redirect users to fake login pages to steal credentials - Session Hijacking: Redirect to attacker site that captures session cookies via JavaScript - Malware Distribution: Redirect to sites hosting malware or drive-by downloads - Reputation Damage: Users lose trust when redirected to malicious sites from legitimate application - Social Engineering: Use trusted Snipe-IT domain to increase phishing success rate When the user clicks "Save", the application: 1. Processes the form 2. Checks redirectoption (if set to 'back') 3. Calls Helper::getRedirectOption() 4. Retrieves backurl from session: https://evil.com/phishing?target=snipeit 5. Executes redirect()-to($backUrl) 6. User is redirected to attacker's site This would still require session poisoning, so the actual practical threat here is minimal. Patches…
Recommended action: Upgrade to 8.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Insecure Permissions vulnerability in grokability snipe-it versions through 8.4.0, fixed after 2026-03-10 commit 676a9958, allow a remote attacker to execute arbitrary code via the app/Http/Controllers/Api/UploadedFilesController.php component Impact Users who can view assets, consumables, etc were able to send a POST request to /api/v1/{objecttype}/{id}/files. The API authorized with "view" instead of write permission and persists the file and audit log entry. Patches Fixed after 2026-03-10 commit 676a9958, fix released to 8.4.1. Workarounds None.
Recommended action: Upgrade to 8.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user with only users.edit permission can escalate their own privileges to admin by sending a PATCH request to /api/v1/users/{id} with permissions[admin]=1. The API controller only strips the superuser key from the permissions array, allowing admin and all other permission keys to be set by any user who can update users. Patches Patched in https://github.com/grokability/snipe-it/commit/ce18ff669ceb0f0349749fd5d11c1d3d40b10569, fix was released in v8.4.1 Workarounds None.
Recommended action: Upgrade to 8.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with component view access could be impacted by an unescaped notes column. Patches This was patched in https://github.com/grokability/snipe-it/commit/28f493d84d057895fbb93b6570e7393a2c2fa438, and is fixed in v8.4.1 or greater. Workarounds None.
Recommended action: Upgrade to 8.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Snipe-IT versions prior to 8.3.7 contain sensitive user attributes related to account privileges that are insufficiently protected against mass assignment. An authenticated, low-privileged user can craft a malicious API request to modify restricted fields of another user account, including the Super Admin account. By changing the email address of the Super Admin and triggering a password reset, an attacker can fully take over the Super Admin account, resulting in complete administrative control of the Snipe-IT instance.
Recommended action: Upgrade to 8.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Snipe-IT before 8.3.4 allows stored XSS via the Locations "Country" field, enabling a low-privileged authenticated user to inject JavaScript that executes in another user's session.
Recommended action: Upgrade to 8.3.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Snipe-IT before 8.3.4 allows stored XSS, allowing a low-privileged authenticated user to inject JavaScript that executes in an administrator's session, enabling privilege escalation.
Recommended action: Upgrade to 8.3.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Snipe-IT before 8.1.18 allows unsafe deserialization.
Recommended action: Upgrade to 8.1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Recommended action: Upgrade to 8.1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Grokability Snipe-IT before 8.1.0 has incorrect authorization for accessing asset information.
Recommended action: Upgrade to 8.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Snipe-IT before 7.0.10 allows remote code execution (associated with cookie serialization) when an attacker knows the APPKEY. This is exacerbated by .env files, available from the product's repository, that have default APPKEY values.
Recommended action: Upgrade to 7.0.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Users with "User:edit" and "Self:api" permissions can promote or demote themselves or other users by performing changes to the group's memberships via API call.This issue affects snipe-it: from v4.6.17 through v6.4.1.
Recommended action: Upgrade to 6.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-Site Request Forgery (CSRF) in GitHub repository snipe/snipe-it prior to v.6.2.3.
Recommended action: Upgrade to 6.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - Stored in GitHub repository snipe/snipe-it prior to v6.2.2.
Recommended action: Upgrade to 6.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Snipe-IT before 6.0.14 is vulnerable to Cross Site Scripting (XSS) for View Assigned Assets.
Recommended action: Upgrade to 6.0.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.