CVE-2026-86742: Snipe-IT before 8.7.0 CSV Formula Injection via Asset Acceptance Report
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.escapeformulas') 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/unacceptedassets) 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Snipe-ITto a version that resolves this vulnerability.Fixed in 8.7.0
Event History
Frequently Asked Questions
Who can exploit this issue, and who is at risk when the CSV is opened?
An authenticated low-privilege user with ordinary create or edit rights can poison free-text fields that appear in the unaccepted-assets report. A user with reports.view privileges is exposed when they export a pending checkout acceptance referencing that record and open the CSV in a spreadsheet application.
Are default deployments affected?
Yes. The affected export does not apply formula escaping and does not honor the app.escape_formulas configuration setting, unlike sibling exports in the same controller.
What conditions are required for exploitation?
The attacker must be able to edit a relevant asset, company, category, model, or assignee display-name field and set it to a value beginning with =, +, -, @, a tab, or a carriage return. The poisoned record must be associated with a pending checkout acceptance, and a reports.view user must request POST /reports/unaccepted_assets and open the resulting CSV.
What can be done if upgrading is not immediately possible?
Restrict ordinary users from creating or editing records whose free-text fields appear in the report, and restrict access to the unaccepted-assets export to trusted users. Do not open exported CSV files in Excel, LibreOffice Calc, or Google Sheets until affected data has been reviewed for formula-prefixed values.
How can teams identify possible prior exposure?
Review pending checkout acceptance records and the associated asset name or tag, company, category, model, and assignee display-name fields for values beginning with =, +, -, @, tab, or carriage return. Also identify users who have requested the unaccepted-assets report and opened its CSV output.