Which versions of AgenticMail are affected by CVE-2026-57494?

AgenticMail @agenticmail/api (versions prior to 0.9.64) contains an authorization flaw that allows any authenticated agent to access and manipulate tasks assigned to other agents, exposing sensitive…. A patch is available.

How to fix or mitigate CVE-2026-57494?

Within 24 hours, identify all deployments of @agenticmail/api and verify current version numbers-if running prior to version 0.9.64, escalate for urgent patching. Within 7 days, upgrade to version 0.9.64 or later in staging environments and validate that inter-agent task access controls are properly enforced. Within 30 days, deploy the patched version across all production systems, confirm all instances are running 0.9.64 or later, and review task access logs for any unauthorized cross-agent activity.

AgenticMail CVE-2026-57494

Q: What is the CVSS score of CVE-2026-57494?

CVE-2026-57494 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-07-20 security-advisories@github.com

GHSA-hjwc-26pj-v3pm

Authentication Bypass

7.1

CVSS 4.0 · Vendor: github

Severity by source

Vendor (github) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.1 HIGH

Requires a valid low-privilege agent token (PR:L) over the network with no interaction; reads victim task payloads (C:H) and can submit or alter task results (I:H), raising integrity above the vendor's VI:N.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 20, 2026 - 22:32 vuln.today

Analysis Generated

Jul 20, 2026 - 22:32 vuln.today

CVE Published

Jul 20, 2026 - 22:17 cve.org

HIGH 7.1

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1 npm packages depend on @agenticmail/api (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.9.64.

DescriptionCVE.org

AgenticMail gives AI agents real email addresses and phone numbers. In @agenticmail/api prior to version 0.9.64, a low-privileged authenticated AgenticMail agent can enumerate another agent's pending/claimed tasks by supplying the target agent name to GET /api/agenticmail/tasks/pending?assignee=<name>. The returned task objects include the task IDs and payloads. The same task IDs can then be used with the capability-style task mutation endpoints (/tasks/:id/claim, /tasks/:id/result, /tasks/:id/complete, /tasks/:id/fail) to claim, complete, or fail tasks assigned to a different agent. Because ordinary authenticated agents can discover agent names through GET /api/agenticmail/accounts/directory, the task ID effectively stops being a secret capability. This turns the intended capability model into a cross-agent authorization bypass. Version 0.9.64 contains a fix.

AnalysisAI

Cross-agent authorization bypass in AgenticMail's @agenticmail/api (prior to 0.9.64) lets any low-privileged authenticated agent read and hijack tasks belonging to other agents. By calling GET /api/agenticmail/tasks/pending?assignee=<victim>, an attacker enumerates a target agent's pending/claimed tasks - including task IDs and sensitive payloads - then reuses those IDs against the /tasks/:id/claim, /result, /complete, and /fail endpoints, which never verify the caller is the assignee. Fixed in 0.9.64; no public exploit identified at time of analysis, though the GitHub advisory (GHSA-hjwc-26pj-v3pm) includes a working local reproduction, and no EPSS or KEV signal is present in the input.

Technical ContextAI

AgenticMail provisions AI agents with real email addresses and phone numbers and coordinates their work through a task queue exposed by the @agenticmail/api package. The design intended task IDs to act as unforgeable capabilities - possession of the ID was meant to authorize mutation of that task. This is a textbook CWE-639 (Authorization Bypass Through User-Controlled Key): per the advisory's cited code paths (packages/api/src/app.ts, routes/accounts.ts, routes/tasks.ts), createAuthMiddleware only verifies that a bearer token is valid, after which GET /accounts/directory discloses agent names to any authenticated caller and GET /tasks/pending?assignee=<name> resolves arbitrary names into that agent's queue. The mutation endpoints perform no object-level ownership check tying the authenticated caller to the task's assignee or assigner, so an authenticated identity plus a leaked identifier is sufficient to act on another principal's object.

Affected ProductsAI

The affected component is the npm package @agenticmail/api, part of the agenticmail/agenticmail repository, in all versions prior to 0.9.64 (the advisory observed the flaw in 0.9.62). This is the API backend of AgenticMail, the platform that assigns AI agents real email addresses and phone numbers. No CPE string was provided in the input. The authoritative reference is the GitHub Security Advisory GHSA-hjwc-26pj-v3pm at https://github.com/agenticmail/agenticmail/security/advisories/GHSA-hjwc-26pj-v3pm.

RemediationAI

Vendor-released patch: upgrade @agenticmail/api to 0.9.64 or later, which contains the fix, per GHSA-hjwc-26pj-v3pm (https://github.com/agenticmail/agenticmail/security/advisories/GHSA-hjwc-26pj-v3pm). If an immediate upgrade is not possible, apply compensating controls at the API layer: enforce an object-level ownership check so /tasks/:id/claim, /result, /complete, /fail and GET /tasks/:id reject callers who are not the task's assignee or assigner; constrain GET /tasks/pending so the assignee parameter can only resolve to the authenticated caller's own identity rather than arbitrary names; and restrict or gate GET /accounts/directory so agent names are not freely enumerable, noting the trade-off that locking down the directory may break legitimate agent-discovery workflows. As a coarser stopgap, tighten issuance and scoping of agent API keys and monitor for one agent querying another agent's assignee queue, since exploitation requires only a valid low-privilege token.