Export limit exceeded: 16399 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 389427 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 389427 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (389427 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-86759 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 7.1 High |
| Snipe-IT versions before 8.7.0 fail to authorize the POST /hardware/history endpoint, allowing any authenticated user to reassign arbitrary assets and modify audit logs. Attackers can submit a CSV file to reassign assets across companies and inject fraudulent audit trail entries, compromising inventory integrity and accountability. | ||||
| CVE-2026-86758 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.5 Medium |
| Snipe-IT before 8.7.0 fails to properly enforce the viewKeys authorization gate in CSV export and API index endpoints, allowing authenticated users with only licenses.view permission to access product keys. Attackers can download all license keys in bulk via CSV export or validate candidate keys through API response discrepancies without needing the viewKeys permission. | ||||
| CVE-2026-86757 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.5 Medium |
| Snipe-IT before 8.7.0 fails to properly gate access to encrypted custom-field values in asset form templates for listbox, textarea, markdown-textarea, and date/datetime picker elements. Authenticated users with assets.edit, assets.checkin, assets.checkout, or assets.audit permissions can read plaintext encrypted custom field values by opening asset forms, bypassing the assets.view.encrypted_custom_fields permission check. | ||||
| CVE-2026-86756 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.1 Medium |
| Snipe-IT 8.5.0 through 8.6.3 contains an open redirect vulnerability in its SAML assertion-consumer endpoint (SamlController::acs, POST /saml/acs). The endpoint wrote the RelayState POST parameter directly into Laravel's url.intended session key with only CR/LF characters stripped, and LoginController later issued redirect()->intended(), which passes an absolute URL through to the Location header unchanged. An unauthenticated attacker who induces a user of a SAML-SSO-enabled instance to visit a crafted IdP-initiated SSO link can therefore cause the victim's browser to be redirected to an arbitrary absolute external URL immediately after a successful authentication, which the advisory notes facilitates credential-harvesting phishing. No account on the target instance and no compromise of the identity provider are required. Only deployments with SAML SSO enabled are affected. Fixed in 8.7.0 (commit d30b73d, PR #19386), which validates RelayState via a new Helper::sameOriginUrl check before storing it. | ||||
| CVE-2026-86755 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 5.4 Medium |
| Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens*) with only 'web' and 'auth:web' middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user's own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware. | ||||
| CVE-2026-86754 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 7.3 High |
| Snipe-IT before 8.7.0 fails to properly gate Laravel Passport's OAuth client management routes, allowing any authenticated user to register OAuth clients with attacker-controlled redirect URIs. Attackers can trick administrators into approving consent screens, then exchange authorization codes for bearer tokens inheriting full admin API permissions lasting up to 40 years. | ||||
| CVE-2026-86753 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 4.3 Medium |
| snipe-it versions before 8.7.0 fail to validate the requestable flag for asset models in the POST /account/request/asset_model/{modelId} endpoint. Authenticated users can bypass administrative restrictions and create checkout requests for non-requestable asset models by submitting requests directly to the endpoint. | ||||
| CVE-2026-86752 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 5.4 Medium |
| snipe-it versions before 8.7.0 fail to enforce per-instance FMCS scoping in asset audit endpoints, relying solely on query-layer filtering instead of policy-layer authorization checks. Attackers with valid sessions and assets.audit permissions could write audit log entries against cross-company assets if the query-layer scope were bypassed or refactored. | ||||
| CVE-2026-86751 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 8.5 High |
| Snipe-IT before 8.7.0 fails to properly sanitize markdown image syntax in note fields, allowing authenticated users to read arbitrary server files and issue server-side HTTP requests. Attackers can submit markdown image syntax in checkout acceptance notes that survive HTML escaping, are expanded by CommonMark parser, and resolved by laravel-mail-auto-embed via file_get_contents or curl, exfiltrating sensitive files like .env containing APP_KEY. | ||||
| CVE-2026-86750 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 7.7 High |
| Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a "floater" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries. | ||||
| CVE-2026-86749 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.3 Medium |
| Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not check the return value of storage write operations in ImageUploadRequest::handleImages(). Because Laravel's default disk mode does not throw on failure, a silently failed Storage::disk('public')->put(...) call still caused the application to delete the previous image via deleteExistingImage() and to reassign and persist the model's image reference to the new filename, destroying the existing image and leaving the database row pointing at a file that was never written. A mirror problem existed in deleteExistingImage(), where a failed Storage::delete() still nulled the model's image field, orphaning the file on disk. The condition is not directly attacker-controlled: it is triggered when any legitimate authenticated user submits an image upload while the storage backend transiently fails (for example an S3 network error, a local filesystem permission problem, or quota exhaustion). The result is unrecoverable loss of the prior image and a durable inconsistency between the database and disk that requires manual reconciliation. All models whose controllers route through ImageUploadRequest::handleImages (assets, asset models, users, companies, manufacturers, locations, categories, suppliers, departments, and other image-carrying models) are affected. | ||||
| CVE-2026-86748 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.1 Medium |
| Snipe-IT versions before 8.7.0 wipe the database before validating the uploaded backup archive in the restore endpoint. Superusers uploading corrupted or invalid zip files trigger permanent data loss with no recovery path or rollback mechanism. | ||||
| CVE-2026-86747 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 5.4 Medium |
| Snipe-IT is an open source IT asset management system. In versions up to and including 8.6.3, the report acceptance endpoints POST /reports/unaccepted_assets/sent_reminder (ReportsController::sentAssetAcceptanceReminder) and DELETE /reports/unaccepted_assets/{acceptanceId}/delete (ReportsController::deleteAssetAcceptance) are not correctly scoped when Full Multiple Company Support (FMCS) is enabled. In 8.6.3 the guard ReportsController::currentUserCanAccessAcceptance() early-exits with 'return true' when '! $user->company_id' is truthy, which is the case for every pivot-only user (a user associated with companies through the company_user pivot table whose scalar users.company_id column is NULL); versions prior to 8.6.3 lacked the guard altogether. As a result, an authenticated user holding the reports.view permission can send acceptance-reminder emails for, and permanently delete, any pending acceptance record in the install regardless of which company owns the underlying checkoutable. Deletion is destructive and forfeits the acceptance audit trail for the affected item, and the reminder email exposes limited cross-company acceptance context (item name and assignment metadata) to the recipient. Acceptance IDs are sequential integers and can be enumerated. This issue is fixed in version 8.7.0. | ||||
| CVE-2026-86746 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.4 Medium |
| Snipe-IT before 8.7.0 contains an authorization bypass vulnerability in Livewire components that enforce authorization only at the route level, not within component lifecycle methods. Attackers with a valid authenticated session can replay signed component snapshots via POST /livewire/update to invoke protected methods and escalate privileges, including creating OAuth clients, minting personal access tokens, and accessing sensitive admin data. | ||||
| CVE-2026-86745 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.5 Medium |
| Snipe-IT is an IT asset management application. In Snipe-IT master-branch builds after 8.6.3 (the code was never included in a tagged release), SettingsController::downloadLocationScopingReport streams the FMCS location-scoping mismatch report (GET /admin/settings/location-scoping-report.csv) through a bare fputcsv() call without applying League\Csv\EscapeFormula, unlike the other CSV exports which honor config('app.escape_formulas'). An authenticated user with ordinary create/edit rights can place a spreadsheet formula in free-text fields that appear in the report (item name, asset tag, serial, item or location company name, location name) and arrange for the record to be FMCS-mismatched so it is included in the export. When a superuser downloads the report and opens it in Excel, LibreOffice Calc, or Google Sheets with formula evaluation enabled and external-content warnings dismissed or disabled, cells beginning with =, +, -, @, tab, or CR are executed in the victim's spreadsheet context, enabling data exfiltration (e.g., HYPERLINK/WEBSERVICE) or, on Windows Excel, legacy DDE command execution. This issue is fixed in version 8.7.0. | ||||
| CVE-2026-86744 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 2.2 Low |
| Snipe-IT 8.6.3 and earlier (and develop pre-release commits prior to the fix) contain a race condition in the asset checkout paths. Api\AssetsController::checkout() and Assets\AssetCheckoutController::store() call Asset::availableForCheckout() outside the mutation path and then invoke Asset::checkOut() without taking a row lock or re-checking availability, so two concurrent checkout requests for the same available asset can both observe it as available and both commit. This produces duplicate checkout-history rows, a doubled checkout_counter, and two CheckoutableCheckedOut events for a single-assignment asset, corrupting the audit trail and utilization/reconciliation reporting; the asset's final assigned_to remains singular, so the visible assignment stays intact. Exploitation requires an authenticated session holding the assets.checkout permission (or superuser) and precise concurrent timing. Fixed in 8.7.0. | ||||
| CVE-2026-86743 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 5 Medium |
| Snipe-IT versions before 8.7.0 fail to properly scope asset acceptance report queries by company, allowing authenticated reports.view users to read pending acceptances across all companies. Attackers can access the unaccepted_assets report page or CSV export to disclose cross-company inventory details and assignee names without per-row access validation. | ||||
| CVE-2026-86742 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.5 Medium |
| Snipe-IT through 8.6.3 does not neutralize formula elements in the "unaccepted assets" acceptance report CSV export. ReportsController::postAssetAcceptanceReport builds the CSV by hand (stripping commas and joining rows manually) and, unlike the six sibling exports in the same controller, never applies League\Csv\EscapeFormula or honors the config('app.escape_formulas') setting. An authenticated low-privilege user with ordinary create/edit rights on any record whose free-text fields appear in the report (asset name/tag, company name, category, model, or assignee display name) can set such a field to a value beginning with =, +, -, @, tab, or CR. When a user with reports.view privileges requests the export (POST /reports/unaccepted_assets) for a pending checkout acceptance referencing the poisoned record and opens the resulting CSV in Excel, LibreOffice Calc, or Google Sheets, the injected content is evaluated as a formula in the downloader's spreadsheet context, enabling data exfiltration (e.g., HYPERLINK/WEBSERVICE) or, on legacy Windows Excel configurations, DDE command execution. Fixed in 8.7.0. | ||||
| CVE-2026-86741 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 8.5 High |
| Snipe-IT versions before 8.7.0 fail to sanitize the category EULA text field before rendering it in checkout confirmation emails. Attackers with low-privilege permissions can inject markdown image syntax or raw HTML img tags pointing to local files or remote URLs, which the mail auto-embed library resolves server-side and returns as email attachments, exfiltrating sensitive files like .env credentials and enabling SSRF attacks. | ||||
| CVE-2026-86740 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 3.8 Low |
| Snipe-IT before 8.7.0 fails to check the return value of Storage::delete() in UploadedFilesController::destroy() and Api\\UploadedFilesController::destroy(), allowing deletion requests to report success while files remain on disk. Administrators performing attachment deletions receive success responses and see files hidden from listings, but the physical files persist on disk and remain accessible to anyone with filesystem or backup access. | ||||