CVE-2026-77831 in ash_paper_trail
Summary
by MITRE • 08/30/2026
Inefficient Algorithmic Complexity vulnerability in ash-project ash_paper_trail allows a user who can submit a large array attribute to a paper-trailed create or update action to cause a denial of service through excessive CPU and memory use.
With full-diff change tracking, AshPaperTrail.ChangeBuilders.FullDiff.ListChange pairs each prior array element against the new list by rebuilding the remaining-elements accumulator with acc ++ [tuple] on every step, copying the growing list each time, so the pairing scales cubically in the array length. Nothing bounds the length and the value comes straight from action input, so one request carrying a large accepted {:array, _} attribute forces tens of seconds of CPU and multi-gigabyte allocations.
This issue affects ash_paper_trail: from 0.1.1 before 0.7.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in the ash-paper-trail library represents a critical inefficiency in algorithmic complexity, specifically categorized under CWE-400 as Uncontrolled Resource Consumption. This flaw manifests when an authenticated user submits a request containing a large array attribute during either a create or update action that triggers paper trail change tracking. The core technical issue lies within the FullDiff ChangeBuilders implementation for list changes, where the system attempts to pair each prior array element against the new list by rebuilding a remaining-elements accumulator on every iteration. This process involves concatenating tuples using an operation such as acc ++ [tuple], which necessitates copying the entire growing list at each step rather than appending efficiently. Consequently, the computational cost scales cubically relative to the length of the input array, creating a severe performance bottleneck that can be exploited by malicious actors seeking to disrupt service availability.
From an operational perspective, this vulnerability allows for a denial-of-service attack with minimal effort from the attacker's side. Because there are no bounds placed on the maximum length of accepted arrays and the data originates directly from user input, a single request carrying a sufficiently large array can force the server to consume tens of seconds of CPU time and allocate multiple gigabytes of memory. This excessive resource consumption not only degrades performance for legitimate users but can also lead to application crashes or system instability if resources are exhausted. The lack of input validation regarding array size means that even moderately sized arrays, which might be considered normal in other contexts, become dangerous when processed by this specific inefficient algorithmic logic within the paper trail mechanism.
This issue affects versions of ash-paper-trail from 0.1.1 up to but not including version 0.7.0. The vulnerability aligns with ATT&CK technique T1496, Resource Hijacking, where an adversary uses computing resources such as CPU or memory in a way that negatively impacts the availability of those resources for legitimate users. To mitigate this risk, organizations must upgrade to ash-paper-trail version 0.7.0 or later, which presumably addresses the algorithmic inefficiency through optimized data structures or bounded processing logic. In addition to upgrading, administrators should implement strict input validation policies at the application gateway or API layer to limit the maximum size of array attributes submitted in create and update actions. This defense-in-depth approach ensures that even if a vulnerability exists within the library, the malicious payload is rejected before it can trigger the inefficient computational path, thereby preserving system stability and availability.