CVE-2026-86734: Snipeitapp Snipe-it DOS Vulnerability

CVE-2026-86734 Overview

CVE-2026-86734 is a denial of service vulnerability in Snipe-IT, an open-source IT asset management platform, affecting versions prior to 8.7.1. The flaw exists in the POST /account/accept/{acceptance} endpoint, which fails to validate the length of the note field. Authenticated users can submit arbitrarily large note values that reach synchronous CommonMark markdown rendering during acceptance email notification processing. The unbounded input consumes PHP worker CPU on a per-request basis, exhausting server resources and degrading service availability. The vulnerability is classified as CWE-400 (Uncontrolled Resource Consumption).

Critical Impact
Authenticated attackers can exhaust PHP worker CPU by submitting oversized note payloads, causing denial of service across the Snipe-IT application.

Affected Products

Snipe-IT versions prior to 8.7.1
Snipeitapp Snipe-IT self-hosted deployments
Instances relying on the bundled league/commonmark parser below 2.9.0

Discovery Timeline

2026-09-08 - CVE-2026-86734 published to NVD
2026-09-10 - Last updated in NVD database

Technical Details for CVE-2026-86734

Vulnerability Analysis

The vulnerability resides in app/Http/Controllers/Account/AcceptanceController.php, which handles user acceptance of asset checkouts. When an authenticated user submits a POST request to /account/accept/{acceptance}, the controller accepts a note parameter without applying any server-side length validation. That note is later processed through the CommonMark markdown parser during synchronous rendering of the acceptance notification email.

Because CommonMark parsing operates in the request lifecycle rather than a background job, each oversized note directly consumes PHP-FPM worker CPU time. An attacker holding any valid authenticated session can chain multiple large payloads to saturate the worker pool. This produces resource exhaustion and denial of service against legitimate users of the Snipe-IT instance.

Root Cause

The root cause is missing input validation on the note field combined with synchronous invocation of a parser that exhibits non-linear performance characteristics on pathological input. Two defects compound: the controller lacked a max length constraint, and the bundled league/commonmark version was susceptible to parser complexity issues addressed in 2.9.0.

Attack Vector

Exploitation requires authenticated access with permission to accept a checkout acceptance record. The attacker submits a POST request with a very large note value to the acceptance endpoint. No user interaction is required beyond the attacker's own request, and repeated submissions amplify the impact against worker capacity.

php

// Patch: app/Http/Controllers/Account/AcceptanceController.php
            abort(403, trans('general.insufficient_permissions'));
        }

+        // Bound the note server-side. Unbounded notes were reaching synchronous
+        // CommonMark rendering in the acceptance notification email and
+        // consuming worker CPU on a per-request basis (defense in depth against
+        // the parser CVE; the commonmark bump to 2.9.0 is the primary fix).
+        $request->validate([
+            'note' => 'nullable|string|max:1000',
+        ]);
+
        $acceptance = CheckoutAcceptance::find($id);

        if (! $acceptance) {
// Source: https://github.com/grokability/snipe-it/commit/66770cfe20cb135e2b7022c7a83d01e6783c914a

The patch adds a Laravel validation rule capping the note field at 1000 characters and upgrades league/commonmark to ^2.9.0 in composer.json as the primary parser-level fix.

Detection Methods for CVE-2026-86734

Indicators of Compromise

Elevated PHP-FPM or Apache worker CPU utilization correlated with requests to /account/accept/{acceptance}
HTTP POST requests to the acceptance endpoint with abnormally large Content-Length headers or oversized note form fields
Repeated acceptance submissions from a single authenticated session within a short interval
Queued or delayed acceptance notification emails caused by synchronous rendering backlog

Detection Strategies

Inspect web server access logs for POST requests to /account/accept/ paths with request body sizes exceeding typical baselines
Correlate application logs with worker process CPU spikes to attribute exhaustion events to specific authenticated users
Monitor Laravel logs for prolonged request durations on the AcceptanceController route

Monitoring Recommendations

Alert on sustained PHP worker saturation combined with traffic to acceptance endpoints
Track per-user submission rates on /account/accept/{acceptance} and flag anomalous volumes
Baseline request payload sizes for authenticated Snipe-IT endpoints and alert on outliers

How to Mitigate CVE-2026-86734

Immediate Actions Required

Upgrade Snipe-IT to version 8.7.1 or later, which enforces the max:1000 validation on the note field and ships league/commonmark2.9.0
Audit authenticated user accounts and revoke sessions or credentials for accounts exhibiting abusive acceptance submissions
Place a Web Application Firewall (WAF) rule in front of the acceptance endpoint to reject requests with oversized note parameters until patching is complete

Patch Information

The fix is committed in the Snipe-IT patch commit 66770cf and detailed in the GitHub Security Advisory GHSA-4vcv-fc5x-jjwv. Additional context is available in the VulnCheck advisory for Snipe-IT. Administrators should upgrade to 8.7.1 and confirm the composer.lock file reflects league/commonmark at 2.9.0 or higher.

Workarounds

Enforce request body size limits at the reverse proxy or load balancer for the /account/accept/* route
Configure a WAF rule to reject POST bodies to the acceptance endpoint exceeding a conservative threshold such as 4 KB
Restrict acceptance permissions to trusted user roles until the upgrade is applied

bash

# Nginx configuration example: cap request body size for the acceptance route
location ~ ^/account/accept/ {
    client_max_body_size 4k;
    proxy_pass http://snipeit_backend;
}