You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
security: unbounded ACP frames and per-request goroutines (Z-017) #923
The Agent Communication Protocol (ACP) implementation currently lacks resource boundaries for frame processing and concurrency. Specifically, there are no hard caps on the number of frames that can be processed per request, nor is there a limit on the number of goroutines spawned to handle concurrent lapped requests or streaming responses.
A malicious or malformed ACP stream could be designed to send an excessive number of frames or initiate a large number of concurrent requests, forcing the system to allocate unbounded memory or exhaust the available thread pool.
Impact
This is a classic Denial of Service (DoS) vector. An attacker (or a malformed provider response) could crash the Zero process by triggering an Out-Of-Memory (OOM) event or by exceeding the operating system's process thread limit, rendering the agent unavailable.
Recommended Fix
Implement strict resource quotas for ACP sessions:
Frame Budgeting: Introduce a maxFramesPerRequest limit. Once a request exceeds this budget, the connection should be terminated with a protocol error.
Concurrency Throttling: Implement a semaphore or worker pool to cap the number of concurrent goroutines active for a single ACP session or request.
Memory Capping: Use limited readers or pre-allocated buffers to prevent a single large frame from consuming all available system memory.
Approved after checking current main. ACP still reads newline frames with ReadBytes and starts request handlers in goroutines without explicit frame-size or per-connection concurrency limits. The fix must bound both memory and handler concurrency and fail closed without deadlocking shutdown. PR #944 is already active.
Activity
vedantlavale commentedon Aug 21, 2026
working on this :)
gnanam1990 commentedon Aug 25, 2026
Approved after checking current
main. ACP still reads newline frames withReadBytesand starts request handlers in goroutines without explicit frame-size or per-connection concurrency limits. The fix must bound both memory and handler concurrency and fail closed without deadlocking shutdown. PR #944 is already active.security(acp): bound frame size and throttle concurrent request handl…
security(acp): bound frame size and throttle concurrent request handl…