ag-ui CVE-2026-101100

Requires the application to use ag-ui client's FilterToolCallsMiddleware configured with a disallowedToolCalls list as a security control, AND a deployment pattern where the same middleware instance/subscription serves multiple agent runs (concurrent, stalled, or reused runId/toolCallId). The security-relevant bypass triggers when one run's blocked tool call is left open while a second run's RUN_STARTED event clears the shared blocking state, allowing the first run's remaining disallowed tool-call events to pass. Limiting factors: the attacker needs low-privilege ability to initiate agent runs (PR:L), the filter must actually be relied on to enforce tool-call policy, and a single-run/single-subscription deployment is not affected; impact is bounded to filter bypass and mis-blocking rather than direct code execution.

This is a medium-severity issue with modest real-world risk. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L, score 5.3) indicates network reachability with low attacker privileges and no required user interaction, but impact is limited to low integrity and low availability with zero confidentiality impact - despite the 'Information Disclosure' tag, no data is disclosed. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis; the only public artifact is the fix PR (#2494) with regression tests that demonstrate the flaw mechanically, which is not the same as weaponized exploitation. The core weakness (CWE-459 incomplete cleanup) is that FilterToolCallsMiddleware maintains blocked tool-call state on the middleware instance rather than per-run, so a later run can clear the state that was protecting an earlier still-open run and allow previously-blocked (disallowed) tool-call events to pass the filter - a security-control bypass rather than a memory-corruption or code-execution bug. Signals are consistent: low CVSS, no exploitation evidence, and a narrow impact profile all point to a genuine LOW-to-MEDIUM operational priority, not a high-urgency issue. Note the tag says 'Information Disclosure' while the vendor vector explicitly sets VC:N - the tag conflicts with the actual impact and should be treated as integrity/availability.

An attacker who can drive agent runs through a shared FilterToolCallsMiddleware instance starts a run whose disallowed tool call is left interrupted/stalled, then initiates a second concurrent run whose start event clears the shared blocking state; the first run's remaining blocked tool-call events (ARGS/END/RESULT) then leak through the filter that was meant to suppress them. No weaponized public exploit exists - only the vendor's regression tests demonstrate the concurrency/state-reuse behavior. Alternatively a benign but reused tool-call ID from a prior run wrongly blocks a legitimate tool call in a later run (availability side).