Snipe

The software fails to check the return value of the `ldap start tls()` function within the `connectToLdap()` function. This allows an on-path attacker to force cleartext LDAP binds by responding to the StartTLS request with a protocol error, enabling the capture of service-account credentials and end-user login passwords.

A SAML assertion replay issue exists due to a non-atomic nonce check in the SAML acs handler. This allows attackers to reuse captured assertions by sending concurrent POST requests to the '/saml/acs' endpoint. By doing so, they can obtain multiple authenticated victim sessions that bypass revocation driven by the Identity Provider (IdP).

An issue exists in the `ApiAssetsController::store` function where plaintext is written into custom-field columns flagged for encryption when the caller lacks the `assets.view.encrypted custom fields` permission. Authenticated API users without this permission can create assets with sensitive custom-field values that remain unencrypted in the database, potentially exposing the data through backups, replicas, or direct database access.

An authentication bypass exists in the `handleGoogleCallback()` function within the `GoogleAuthController`. The system logs in users whose usernames match the Google account email without verifying the activated flag. Consequently, deactivated users who possess email-formatted usernames and active Google identities can authenticate via Google SSO to regain access with their previous permission levels, including administrative privileges.

A server-side request forgery (SSRF) issue exists in the webhook testing feature. This allows super-admin users to probe internal network addresses, including loopback and RFC1918 ranges (private IP address spaces). By pointing webhooks at internal hosts and ports and comparing 4xx versus 5xx responses from the Test Webhooks functionality, an attacker can map active hosts and open ports.

When Full Multiple Company Support (FMCS) is enabled, the predefined kit checkout path fails to enforce tenant isolation on the checkout target. The `PredefinedKitCheckoutService` function does not call `$item->canCheckoutTo($target)`, performing only actor-vs-item policy and availability checks. This allows a non-superuser with `assets.checkout` permissions who belongs to at least two companies to use the '/kits/{kit}/checkout' endpoint to assign assets, licenses, consumables, or accessories from one company to a user belonging to a different company by providing the `user id` of that user.

An open redirect exists in the SAML assertion-consumer endpoint `POST /saml/acs` (handled by the `SamlController::acs` function). The issue occurs because the `RelayState` POST parameter is written directly into the `url.intended` session key with only CR/LF characters removed. Subsequently, the `LoginController` executes `redirect()->intended()`, which sends an absolute URL to the Location header without modification. An unauthenticated attacker can trick a user of an instance with SAML SSO enabled into visiting a crafted IdP-initiated SSO link, causing the browser to redirect to an arbitrary external URL after successful authentication. This can be used to facilitate credential-harvesting phishing attacks. No account on the target instance or compromise of the identity provider is necessary.

The software fails to enforce per-instance FMCS scoping in asset audit endpoints. It relies on query-layer filtering instead of policy-layer authorization checks. This allows attackers with valid sessions and `assets.audit` permissions to write audit log entries against assets belonging to other companies if the query-layer scope is bypassed or refactored.

Insufficient validation of company assignment authorization occurs when persisting user records via the REST API. In the `store()` and `update()` functions of `ApiUsersController`, user records are saved before the `company id` or `company ids[]` variables are filtered against the actor's permitted companies via `Company::getIdsForCurrentUser()`. In installations using Full Multiple Companies Support (FMCS), a non-superuser with `users.create` or `users.edit` permissions can submit company identifiers outside their authorized scope. If the `null company is floater=1` configuration is active, the account may be persisted as a floater with cross-company visibility, enabling the creation or relocation of user accounts across tenant boundaries.

The software wipes the database before validating the uploaded backup archive in the restore endpoint. If a superuser uploads a corrupted or invalid zip file, it triggers permanent data loss because there is no recovery path or rollback mechanism.

In the `AccountAcceptanceController::store()` function, the software fails to verify the return value of `Storage::put()` when saving signature PNGs and generated acceptance PDFs. On filesystem drivers that return a false value instead of throwing an exception during write failures—such as local disks with restrictive permissions, S3 with expired credentials, or storage backends exceeding quotas—the process continues to the `accept()` function. This results in the `accepted at`, `signature filename`, and `eula filename` fields being updated, an accepted action-log entry being created, and completion notifications being sent, despite the evidence files not being stored. This creates incomplete compliance artifacts for equipment-receipt or EULA acknowledgement workflows. The issue occurs when an authenticated user completes an acceptance while the storage backend is failing writes.

An issue exists where the system fails to verify the return value of the `Storage::delete()` function within `UploadedFilesController::destroy()` and `ApiUploadedFilesController::destroy()`. This allows deletion requests to report success even if the files remain on the disk. Consequently, while administrators see files hidden from listings, the physical files persist and remain accessible to individuals with filesystem or backup access.

Insufficient sanitization of the category EULA text field allows users with low-privilege permissions to inject markdown image syntax or raw HTML img tags. These tags can point to local files or remote URLs, which the mail auto-embed library resolves server-side and includes as email attachments. This behavior enables Server-Side Request Forgery (SSRF), a technique where an attacker induces the server to make requests to an unintended location, and the exfiltration of sensitive files such as `.env` credentials.

Authenticated users with `reports.view` permissions can access pending asset acceptances across all companies due to improper scoping of report queries. This allows unauthorized disclosure of cross-company inventory details and assignee names through the `unaccepted assets` report page or its CSV export, as the system fails to perform per-row access validation.

An issue exists where formula elements are not neutralized in the unaccepted assets acceptance report CSV export. The `postAssetAcceptanceReport()` function in `ReportsController` manually constructs the CSV without applying formula escaping or honoring the `app.escape formulas` configuration. An authenticated user with low privileges can inject values starting with =, +, -, @, tab, or CR into free-text fields such as asset name, tag, company name, category, model, or assignee display name. When a user with `reports.view` privileges requests the export via the 'POST /reports/unaccepted assets' endpoint and opens the file in spreadsheet software like Excel, LibreOffice Calc, or Google Sheets, the injected content is executed as a formula. This can lead to data exfiltration through functions like HYPERLINK or WEBSERVICE, or DDE (Dynamic Data Exchange) command execution on legacy Windows Excel configurations.

A race condition exists in the asset checkout paths. The functions `ApiAssetsController::checkout()` and `AssetsAssetCheckoutController::store()` call `Asset::availableForCheckout()` outside the mutation path and subsequently invoke `Asset::checkOut()` without implementing a row lock or re-verifying availability. Consequently, two concurrent checkout requests for the same available asset can both be processed as successful. This results in duplicate checkout-history rows, a doubled `checkout counter`, and two `CheckoutableCheckedOut` events for a single-assignment asset, which corrupts the audit trail and utilization/reconciliation reporting. The final `assigned to` value remains singular, leaving the visible assignment intact. Exploitation requires an authenticated session with the `assets.checkout` permission or superuser privileges, combined with precise concurrent timing.

An issue exists in the `SettingsController::downloadLocationScopingReport` function where the FMCS location-scoping mismatch report is streamed via the '/admin/settings/location-scoping-report.csv' endpoint using a bare `fputcsv()` call. This process fails to apply `LeagueCsvEscapeFormula`, ignoring the `app.escape formulas` configuration. An authenticated user with create or edit permissions can inject spreadsheet formulas into free-text fields such as item name, asset tag, serial, item or location company name, and location name. If a superuser downloads this report and opens it in software like Excel, LibreOffice Calc, or Google Sheets with formula evaluation enabled, cells starting with `=`, `+`, `-`, `@`, tab, or CR are executed. This can lead to data exfiltration via `HYPERLINK` or `WEBSERVICE` functions, or legacy DDE command execution on Windows Excel.

An authorization bypass exists in Livewire components that enforce authorization only at the route level rather than within component lifecycle methods. An authenticated attacker can replay signed component snapshots via the 'POST /livewire/update' endpoint to invoke protected methods. This allows for privilege escalation, enabling the creation of OAuth clients, minting of personal access tokens, and access to sensitive administrative data.

When Full Multiple Company Support (FMCS) is enabled, certain report acceptance endpoints are not correctly scoped. An authenticated user with the `reports.view` permission can send acceptance-reminder emails or permanently delete any pending acceptance record across the entire installation, regardless of company ownership. This occurs because the `currentUserCanAccessAcceptance()` function in the `ReportsController` incorrectly allows access for pivot-only users (users associated with companies via a pivot table whose `company id` is NULL), and versions prior to 8.6.3 lack this guard entirely. The affected endpoints are `POST /reports/unaccepted assets/sent reminder` (via `sentAssetAcceptanceReminder()`) and `DELETE /reports/unaccepted assets/{acceptanceId}/delete` (via `deleteAssetAcceptance()`). Deletion is destructive and removes the acceptance audit trail, while the reminder email may expose item names and assignment metadata across companies. Acceptance IDs are sequential integers and can be enumerated.

An issue exists where the application fails to verify the return value of storage write operations within the `ImageUploadRequest::handleImages()` function. Due to the default disk mode of the Laravel framework not throwing exceptions on failure, a failed `Storage::disk('public')->put(...)` call results in the application deleting the previous image via `deleteExistingImage()` and updating the database reference to a new filename that was never actually written to disk. Similarly, a failure in `Storage::delete()` within `deleteExistingImage()` can null the image field in the database while leaving the file on the disk. This condition occurs when an authenticated user uploads an image during a storage backend failure, such as S3 network errors, filesystem permission issues, or quota exhaustion, leading to unrecoverable data loss and database inconsistency. This affects multiple models including assets, users, companies, manufacturers, locations, categories, suppliers, and departments.