Bytebot Agent DoS Vulnerability in Execution Flow due to Missing Budget Limits

Vulnerability Overview Bytebot contains a Denial of Service (DoS) vulnerability in its agent execution budget handling. A normal task prompt may cause the agent to repeatedly call the model and desktop tools until the model eventually emits a terminal state signal. The backend fails to enforce maximum iteration counts, tool call counts, wall-clock timeouts, model call budgets, token/cost budgets, sub-task budgets, or storage tool result byte budgets. This leads to continuous scheduling of the next agent iteration instead of proceeding correctly before the next agent iteration. Scope of Impact Affected Versions: Bytebot local source package version 0.0.1 Verification Method: Verified via the following Docker images: Vulnerable Files Description Bytebot has a Denial of Service (DoS) vulnerability in its agent execution workflow. A normal task prompt may cause the agent to repeatedly call the model and desktop tools until the model eventually emits a terminal state signal. The backend fails to enforce maximum iteration counts, tool call counts, wall-clock timeouts, model call budgets, token/cost budgets, sub-task budgets, or storage tool result byte budgets. This results in the system scheduling the next iteration of the agent rather than terminating or proceeding appropriately. In real-world deployments, a single malicious or malformed task can monopolize the shared agent execution pool, repeatedly consuming LLM and desktop tool resources, storing screenshot results in the message database, and holding other normal tasks in a pending state. This can lead to wallet and task queue starvation, database growth, and functional unavailability, impacting legitimate users. Code Analysis The agent sends accumulated task messages to the configured model in each iteration: The model response may contain computer tool calls. Each tool call is executed, and its results are appended to the task messages: If the task is not explicitly completed or moved to a help state, the processor schedules another iteration without checking any execution budgets: Desktop tool execution also amplifies each iteration. After storing more tool executions, Bytebot waits and captures another screenshot, storing it as base64 tool result data: The scheduler processes only one task at a time. When a looping task is running, it returns before selecting the next queued task: Messages are loaded back into the next model call without a hard per-task message budget: Root Cause: Low-trust task prompts -> Model response controls tool calls -> Desktop tool execution and screenshot capture POC This POC utilizes Bytebot's normal task API and a local OpenAI-compatible model endpoint. The local model returns a valid Chat Completions response containing tool calls. This makes reproduction deterministic while still exercising Bytebot's real model provider path, task scheduling path, desktop tool path, scheduler, database persistence, and UI. Model Behavior: Attack Task Prompt: Create attack task via the normal API: After the attack task enters the model/tool loop, create a normal follow-up task: Verify the impact using command-line requests: Successful exploitation displays: Observed Local Proof: The terminal screenshot is a live window query of the local Bytebot container. It directly shows successful baseline checks, repeated model/tool responses, the attack task still running, the normal task still pending, and the final reproduction result. The application screenshot is a real Microsoft Edge window, with the local Bytebot UI opened after exploitation. It shows the normal follow-up task still in a pending/task-hold state rather than being executed. Remediation Recommendations 1. Create a root execution budget before processing each task. 2. Enforce root budgets for maximum model calls, tool calls, wall-clock runtime, tokens, estimated costs, sub-tasks, stored message bytes, and screenshot/tool result bytes. 3. Check the budget after every model call, task scheduling, screenshot capture, sub-task creation, message persistence, and summary generation. 4. Break the loop; upon budget exhaustion, transition the task to a finished state instead of scheduling another iteration. 5. Propagate cancellation and budget status to the model client, desktop tool HTTP calls, subprocesses, and sub-tasks. 6. Add per-tenant or per-user queue admission and fairness controls so that a single running task cannot indefinitely block other normal tasks. 7. Limit and model context assembly using message counts and byte size constraints. 8. Add regression tests using models that return repeated tool calls, asserting that execution stops when no additional model/tool calls are made within the configured budget.

Goal Reached Thanks to every supporter — we hit 100%!

Bytebot Agent DoS Vulnerability in Execution Flow due to Missing Budget Limits

More from this source