ash Framework CVE-2026-82743

Exploitation requires ash version 2.19.0 through 3.32.2 to be deployed and for the application to execute concurrent asynchronous read operations that include at least one slow task - such as loading related resources backed by an external API call, a slow database query, or a long-running calculation. The busy-spin manifests only while all outstanding async tasks in a batch are still running; a fast application where all reads complete quickly will not exhibit scheduler exhaustion. The CVSS 4.0 AT:P flag confirms specific attack requirements are present. Limiting factors: the application must use ash's async read path (not purely synchronous reads), at least one async task must be slow relative to the polling cycle, and impact scales with the number of concurrent slow reads. There is no authentication requirement to trigger the condition if the vulnerable endpoint is publicly accessible, but the endpoint must be one that internally uses ash async reads.

The vendor-assigned CVSS 4.0 score of 2.1 (Low) reflects the narrow real-world impact: only availability is affected (VA:L), there is no confidentiality or integrity dimension, and the attack requires specific conditions (AT:P - concurrent slow async reads) to manifest at meaningful scale. The AV:L rating is debatable; in typical ash deployments, slow reads are initiated by HTTP request handlers, meaning a remote actor making many requests against a data-heavy endpoint could trigger the condition - this analysis rates AV:N independently (see assessed_cvss_vector). Attack Complexity is effectively High because scheduler exhaustion requires multiple concurrent slow operations, not a single crafted request. There is no KEV listing and no public exploit code, placing real-world exploitation risk very low. The EPSS signal is absent from the provided data. The practical risk profile is an internal performance regression under heavy or adversarially crafted load, not a classic availability-denial primitive. Defenders running ash 2.19.0-3.32.2 with data-intensive or slow relationship-loading operations (e.g., large aggregate queries or external-API-backed calculations) face the highest residual risk before patching.

An operator runs an ash-powered Phoenix application with endpoints that load resource graphs involving slow external calculations or large related-dataset queries. An attacker - or simply a flood of legitimate users - issues many concurrent requests to those endpoints; each triggers an async read, and the AsyncLimiter busy-polls a BEAM scheduler thread for the full duration of every slow task. With enough concurrent slow reads, all scheduler threads are pinned at 100% CPU, starving other processes and causing application-wide latency spikes or unresponsiveness. No special exploit tooling is required beyond sustained concurrent HTTP traffic to a data-heavy endpoint.