ag-ui Java SDK CVE-2026-101098

Exploitation requires network reachability to an application that instantiates JdkAgentHttpHandler from the ag-ui Java community server SDK using either two-argument constructor (which defaulted to no body-size limit before the fix). The attacker sends an oversized request body - or a chunked request without Content-Length - to the agent context path (e.g. '/agent'). The limiting factors are: the target must actually deploy this specific Java SDK handler (a niche component), and impact is bounded to availability (memory exhaustion) with no data exposure. The vendor rates this PR:L (some access level), though the shown handler contains no authentication, so credential requirements are deployment-dependent and not confirmed by the code.

This is a genuine but low-to-moderate severity denial-of-service issue (CWE-400 uncontrolled resource consumption). The pre-patch code path new String(exchange.getRequestBody().readAllBytes(), ...) buffers the entire HTTP request body into a byte array with no size ceiling, so a client sending an arbitrarily large body forces unbounded heap allocation on the server JVM. The vendor CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N/VA:L, base 5.3) reflects a network-reachable, low-complexity attack with only limited availability impact and no confidentiality or integrity impact - consistent with the fix, which simply caps bodies at 8 MiB and returns HTTP 413. No EPSS score, no CISA KEV listing, and no public exploit code are present in the supplied intelligence, so exploitation is theoretical at this time. Note a conflict in the metadata: the description states 'the pull request to fix this issue awaits acceptance' while the metadata says 'Patch: Available from vendor' - the fix (PR #2671) exists but may not yet be merged/released, so treat patch availability as pending verification. Also note the PR:L (authenticated) rating is questionable: the JDK HttpHandler shown carries no authentication logic, so in default deployments the DoS may be reachable without credentials. Overall this is a real hygiene fix for operators of the Java SDK, not a high-urgency emergency.

An attacker who can reach the agent HTTP endpoint served by JdkAgentHttpHandler sends a single HTTP request with an enormous body (or a chunked request with no Content-Length). The unbounded readAllBytes() call allocates the whole payload in memory, and repeated or sufficiently large requests exhaust the JVM heap and degrade or crash the service. No public exploit code is identified at time of analysis; the attack is trivial to reproduce given the described code path.