Snipe-IT CVE-2026-86734

The attacker must hold a valid authenticated Snipe-IT user account (PR:L). No elevated or administrative privileges are required - any account capable of submitting an asset acceptance acknowledgement can reach the vulnerable endpoint. The vulnerability is triggered by submitting an oversized note value to POST /account/accept/{acceptance}; no special deployment mode, non-default configuration, or specific platform is required beyond a running Snipe-IT instance before 8.7.1. Exploitation is limited by the authentication barrier and by network-level access to the Snipe-IT instance, which is often internal-only in enterprise deployments.

The CVSS 4.0 score of 7.1 with VA:H accurately reflects a meaningful but bounded availability threat. The attack requires a low-privilege authenticated account, which limits exploitation to insiders or accounts obtained through phishing or credential reuse - an attacker without a valid login cannot trigger this. The synchronous rendering model means repeated requests could sustain CPU exhaustion across multiple PHP-FPM workers, potentially degrading the application for all users. Even a modestly staffed IT team relying on Snipe-IT for daily asset management operations would feel the impact acutely, and the attacker needs only one valid account to cause disproportionate disruption. EPSS data is not provided in the input; no CISA KEV listing and no public exploit code have been identified, placing real-world exploitation risk in the opportunistic-insider category rather than active threat-actor campaigns. The dual-fix approach (input cap plus commonmark library upgrade) implies the library itself had a latent complexity-based DoS behavior that the application's lack of validation exposed.

An attacker with a valid low-privilege Snipe-IT account - whether an insider or one acquired via phishing - crafts a POST request to /account/accept/{acceptance} with a note field containing several megabytes of CommonMark-formatted text. Submitted repeatedly in parallel, each request blocks a PHP-FPM worker during synchronous markdown rendering, exhausting the worker pool and making the application unresponsive to all users. No public proof-of-concept code has been identified, but the technique requires only standard HTTP tooling.