CVE-2026-57495
CVE-2026-57495 is a Missing Authentication vulnerability in @agenticmail/core. O3 Security confirms whether CVE-2026-57495 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
AgenticMail: Unauthenticated inbound mail triggers bypassPermissions resume of the operator's Claude Code session (bridge-wake)
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-57495.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@agenticmail/corenpm@agenticmail/claudecodenpm@agenticmail/codexnpmDescription
Summary
Two inbound-mail handlers act on a privileged effect without verifying that the sender is the operator, while a sibling handler in the same repo does. The higher-impact one: any external email routed to the bridge inbox causes the dispatcher to resume the operator's Claude Code session with permissionMode: 'bypassPermissions', embedding the attacker-controlled from/subject/preview verbatim into the prompt the resumed agent reads — an indirect prompt injection into a fully-privileged agent (Bash/Write/Edit/WebFetch + the agenticmail MCP toolbelt) running as the operator's OAuth identity. The sibling operator-query email-reply hook gates the same untrusted-From provenance with isOperatorReplySender(replyFrom, config.operatorEmail) (fail-closed); the bridge-wake path — a strictly higher-privilege effect — has no equivalent.
Affected code (current HEAD, commit b95f52e)
Untrusted provenance: external inbound email enters at packages/api/src/routes/inbound.ts:41 (POST /mail/inbound); the x-inbound-secret authenticates only the relay->API hop, not the external sender, so from/subject/preview are attacker-controlled.
Privileged sink (bridge-wake, bypassPermissions):
packages/claudecode/src/dispatcher.ts:2040handleBridgeMailextractssubject/from/preview(:2045-2049) and callsplanBridgeWake({ session, mail: { ..., from, preview } })(:2052) with NO sender check — routing keys only on session freshness (skip-live / escalate / resume).planBridgeWake->packages/core/src/host-bridge.ts:141composeBridgeWakePromptembeds the untrustedfrom/subject/preview(preview sliced to 600 chars at:144) verbatim into the prompt.packages/claudecode/src/bridge-wake.ts:103resumeBridgeSessionruns the prompt via the Claude Code SDK withpermissionMode: 'bypassPermissions'against the operator's last session (resume + same mcpServers).
Guarded sibling (same class, authenticated): packages/api/src/routes/inbound.ts:102 rejects an operator-query email reply unless isOperatorReplySender(replyFrom, config.operatorEmail) (def packages/core/src/phone/realtime-tools.ts:999, fail-closed when no operatorEmail), with a v0.9.53 security-review comment (inbound.ts:93-100) stating inbound mail provenance is untrusted and an emailed answer is only honored when its From matches the configured operator. The Telegram sibling likewise gates on operatorChatId. The bridge-wake path ignores this exact lesson.
Secondary instance (same root cause): packages/core/src/gateway/manager.ts:261 tryProcessApprovalReply releases a held outbound email on an "approve" reply matched only by In-Reply-To / notification_message_id, with no sender check — again unlike the isOperatorReplySender sibling.
Impact
In a configured headless-bridge deployment (operator uses the CLI so a host-session is saved; session fresh <24h per host-sessions.ts:127; external mail routed to the bridge inbox via relay sub-addressing or a Cloudflare webhook), an external sender achieves indirect prompt injection into a bypassPermissions operator session -> arbitrary OS command execution, filesystem read/write, and exfiltration under the operator's OAuth identity. The auth gap (no sender check on the bridge path) is structural and unconditional; the impact realization is config-conditional and depends on the resumed model following injected instructions.
Proof of concept (static / request-difference; dynamic on operator's OWN setup only)
Static: the from/subject/preview extracted at dispatcher.ts:2045-2049 flow into composeBridgeWakePrompt (host-bridge.ts:141) and resumeBridgeSession (bridge-wake.ts:103) with no interposed sender check, while the sibling inbound.ts:102 has one — the same untrusted-From provenance is authenticated on one privileged email path and not on the higher-privileged one. Dynamic (own instance only): with a configured bridge + fresh host-session, send mail from a non-operator address into the bridge inbox whose subject/preview contains a benign instruction writing a fresh CSPRNG marker; observe the resumed bypassPermissions session act on it. Use only your own instance; do not target third-party deployments.
Suggested fix
Mirror the guarded sibling: before any bypassPermissions resume (dispatcher.ts handleBridgeMail, before planBridgeWake), require trusted provenance — an internal sub-agent wake OR isOperatorReplySender(from, config.operatorEmail); otherwise deliver the mail normally but do NOT resume. Reuse the existing exported isOperatorReplySender from @agenticmail/core so the two privileged email paths share one authentication helper. Defense-in-depth: in composeBridgeWakePrompt, wrap the untrusted fields in explicit untrusted-data delimiters and drop bypassPermissions for mail-triggered resumes whose provenance is not the operator. Apply the same sender gate to tryProcessApprovalReply (manager.ts:261).
Affected versions
Present on current HEAD (core 0.9.42 / claudecode 0.2.38, commit b95f52e). No fix retrofits the sender check onto bridge-wake.
Severity (honest, both ways)
HIGH, plausibly CRITICAL in a configured headless-bridge deployment. Ceiling ~9.0 (unauthenticated external sender -> operator-privileged code execution). Floor ~7.0: the auth gap is unconditional, but full impact requires (1) a fresh <24h host-session, (2) external mail routed to the bridge inbox, (3) the resumed model obeying injected instructions (non-deterministic). Not a deterministic RCE primitive. CWE-306 (missing authentication for the privileged action) + CWE-77/CWE-94 (injected instructions realized as command execution). Novelty: the two existing agenticmail advisories (CVE-2026-50287 MCP missing-auth; CVE-2026-47255 storage SQL) do not cover this sink. Please rate per your deployment assumptions.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @agenticmail/core | all versions | 0.9.43 |
| 📦npm | @agenticmail/claudecode | all versions | 0.2.39 |
| 📦npm | @agenticmail/codex | all versions | 0.1.33 |
| 📦npm | @agenticmail/openclaw | all versions | 0.5.71 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @agenticmail/core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @agenticmail/core to 0.9.43 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-57495 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-57495 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-57495. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-57495 in your dependencies?
O3 detects CVE-2026-57495 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.