Christopherfi-Dev

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.

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.

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.

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.

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.

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.

Incomplete sanitization in the Custom CSS field allows for CSS injection because HTML encoding on greater-than and double-quote characters is reversed. Superusers can inject malicious CSS payloads using `@import` and `url()` references. This allows the exfiltration of CSRF (Cross-Site Request Forgery) tokens—unique tokens used to prevent unauthorized commands from being transmitted from a user the web application trusts—from other superusers via attribute-selector rules, which can lead to account takeover.