What happened
The A2AServer exposes a Google A2A agent over HTTP (tasks/send, tasks/get, tasks/cancel) but only enforces Bearer authentication when a secret option is configured. Because the option is optional and startServer() performs no fail-closed check, the default configuration of a network-facing agent endpoint has no authentication. The project's own documentation describes the A2A server as Bearer-gated, so the fail-open default contradicts the documented security posture, and it differs from the package's MCP transports, which refuse to start without a secret.
Why it matters
This is a fail-open missing-authentication flaw in an agent-to-agent (A2A) protocol endpoint. Any attacker who can reach the server can submit arbitrary tasks to the agent executor, read stored task results, and cancel tasks — and because the task text is passed directly to whatever the developer wired as the executor, the impact escalates to whatever tools or systems that agent is allowed to drive.
Attack vector
An operator starts A2AServer.startServer() without a secret (the field is optional with no default). The Bearer-authentication block is gated by if (this.options.secret), so with no secret configured the entire authorization check is skipped and the route proceeds to task handling. An attacker reaches the agent card (which advertises no auth schemes) and submits JSON-RPC tasks/send, tasks/get, and tasks/cancel with no credentials, passing attacker-controlled task text directly to the developer-supplied executor.
Affected systems
network-ai npm package, A2AServer class (lib/a2a-server.ts) <= 5.15.4; fix in 5.15.5 (or configure a secret).
Mitigation
Configure a Bearer secret on A2AServer (fail closed) or upgrade to >= 5.15.5; bind to loopback only where possible and treat the A2A endpoint as authenticated. The advisory notes the fix was not yet present in the latest release checked.