a2a-java EUVD-2026-110929

Exploitation requires an attacker with the privilege to register push notification configurations for a task (CVSS PR:L) by invoking InMemoryPushNotificationConfigStore.setInfo or the JpaDatabasePushNotificationConfigStore equivalent on a server using the Push Notification Config Store (either the in-memory or the JPA-database extras store). The flaw is present in default configurations of a2a-java up to 1.2.0.Final because no per-task limit existed; the fix adds a configurable cap (a2a.push-notification-config.max-per-task, default 100) that throws InvalidParamsError when exceeded. Limiting factors: the attacker must be authorized to call setInfo (not anonymous), only genuinely new config IDs drive consumption (re-registering an existing ID does not), and impact is confined to availability degradation with no confidentiality or integrity effect.

This is a medium-severity, uncontrolled-resource-consumption flaw (CWE-400) rather than a top-priority emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with only low availability impact (VA:L) and no confidentiality or integrity impact yields a 5.3 score, and the vuln.today decision label is 'this_month' - not act_now or emergency. No EPSS score, no CISA KEV listing, and no public PoC/exploit reference are present in the input (the only GitHub links are the fix PR, commit, and release, which are patch artifacts, not exploit code), so there is no public exploit identified at time of analysis. The PR:L metric indicates the attacker must already be able to register push notification configurations for a task, which bounds this to authenticated/authorized callers rather than anonymous internet attackers. The signals are mutually consistent: a real but low-impact, authenticated DoS against a niche SDK. No key data appears conflicting; the main gap is the absence of EPSS/KEV/PoC data, which is expected for a freshly disclosed VulDB-reported issue and is not itself an error.

An authorized caller who can submit tasks repeatedly registers large numbers of distinct push notification configurations for a single task via the setInfo path. Because the pre-1.3.0.Final store enforced no per-task limit, each new config consumes memory and can cause an outbound HTTP request on every task event, progressively exhausting server resources. No public exploit code is identified; the attack is low-complexity (AC:L) over the network but requires the privilege to register configs (PR:L).