Snipe

يفشل البرنامج في التحقق من قيمة إرجاع الدالة `ldap start tls()` ضمن الدالة `connectToLdap()`. يسمح هذا للمهاجم الموجود على المسار (on-path) بفرض عمليات ربط LDAP بنص واضح من خلال الرد على طلب StartTLS بخطأ في البروتوكول، مما يمكنه من التقاط بيانات اعتماد حساب الخدمة وكلمات مرور تسجيل دخول المستخدم النهائي.

توجد مشكلة في إعادة تشغيل تأكيد SAML بسبب فحص nonce غير ذري في معالج SAML acs. يسمح هذا للمهاجمين بإعادة استخدام التأكيدات الملتقطة عن طريق إرسال طلبات POST متزامنة إلى نقطة النهاية '/saml/acs'. ومن خلال القيام بذلك، يمكنهم الحصول على جلسات متعددة موثقة للضحايا تتجاوز عملية الإلغاء التي يقودها مزود الهوية (IdP).

توجد مشكلة في الدالة `ApiAssetsController::store` حيث يتم كتابة نص واضح في أعمدة الحقول المخصصة المحددة للتشفير عندما يفتقر المستدعي إلى إذن `assets.view.encrypted custom fields`. يمكن لمستخدمي واجهة برمجة التطبيقات (API) المصرح لهم والذين لا يملكون هذا الإذن إنشاء أصول تظل قيم حقولها المخصصة الحساسة غير مشفرة في قاعدة البيانات، مما يعرضها للكشف من خلال النسخ الاحتياطية أو النسخ المتماثلة أو الوصول المباشر إلى قاعدة البيانات.

يوجد تجاوز للمصادقة في دالة `handleGoogleCallback()` ضمن `GoogleAuthController`. يقوم النظام بتسجيل دخول المستخدمين الذين يتطابق اسم المستخدم الخاص بهم مع البريد الإلكتروني لحساب Google دون التحقق من حالة التفعيل. وبناءً على ذلك، يمكن للمستخدمين غير النشطين الذين لديهم أسماء مستخدمين على شكل بريد إلكتروني وهويات Google نشطة تسجيل الدخول عبر Google SSO واستعادة جلساتهم بمستوى صلاحياتهم الأصلي، بما في ذلك صلاحيات المسؤول.

توجد ثغرة تزوير الطلبات عبر الخادم (SSRF) في ميزة اختبار الويب هوك (webhook). يسمح هذا لمستخدمي المسؤول الخارق (super-admin) بفحص عناوين الشبكة الداخلية، بما في ذلك عناوين loopback ونطاقات RFC1918 (مساحات عناوين IP الخاصة). من خلال توجيه الويب هوك إلى مضيفات ومنافذ داخلية ومقارنة استجابات 4xx مقابل 5xx من وظيفة اختبار الويب هوك، يمكن للمهاجم رسم خريطة للمضيفات النشطة والمنافذ المفتوحة.

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.