CVE-2026-78228: Unbounded handle_error recursion enables denial of service in AshOban triggers
Uncontrolled Recursion vulnerability in ash-project ashoban allows a user who can drive a trigger's onerror action to fail on the final attempt to exhaust worker CPU and memory, denying service.
The generated worker's atomic handleerror/4 runs the trigger's onerror action on a job's final attempt inside a rescue that, when the action itself raises, calls handleerror/4 again with the same job. The job's attempt still equals maxattempts, so it re-enters the same clause and re-runs the failing action, with no exit. Any deterministic onerror failure (a data-layer outage, a misconfigured action, or a record the action rejects) loops forever; because the recursive call is not in tail position, each iteration retains a formatted stacktrace and the process heap grows without bound while the failing statement is re-issued against the data layer until the runtime kills the worker.
This issue affects ashoban: from 0.8.0-rc.1 before 0.8.14.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_obanto a version that resolves this vulnerability.Fixed in 0.8.14
Event History
Frequently Asked Questions
Who is realistically exposed to this denial of service?
Deployments using ash_oban versions from 0.8.0-rc.1 through before 0.8.14 are exposed when a trigger can reach its final job attempt and its on_error action can fail. Exposure includes deterministic failures caused by data-layer outages, misconfigured actions, or records rejected by the error action.
What conditions are required to trigger the loop?
A user must be able to drive a trigger's on_error action and cause that action to fail on the job's final attempt. When the action raises, handle_error/4 invokes itself with the same job; because the attempt remains at max_attempts, the failing action is retried recursively without an exit.
What is the operational impact while the issue is being triggered?
The affected worker repeatedly issues the failing operation against the data layer while consuming CPU and growing its heap. Each non-tail-recursive iteration retains a formatted stacktrace, and the runtime eventually kills the worker after memory is exhausted.
How can teams tell whether they may already be affected?
Check whether ash_oban is in the affected version range and inspect trigger jobs that fail on their final attempt. Repeated execution of a failing on_error action, sustained worker CPU or memory growth, and repeated failing data-layer statements are indicators of this behavior.