CVE-2026-42865: Inbox Zero Information Disclosure Flaw

CVE-2026-42865 Overview

CVE-2026-42865 is an information disclosure vulnerability in Inbox Zero, an open-source AI personal assistant for email. Versions prior to 2.29.3 used a shared Redis subscription listener in the cleaner email stream endpoint. The shared listener could deliver thread events belonging to one authenticated account to another authenticated account when both used the cleaner feature concurrently. The issue is tracked under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. Maintainers fixed the flaw in release 2.29.3.

Critical Impact

Authenticated users of the cleaner feature could receive Server-Sent Events containing email thread data belonging to other authenticated Inbox Zero accounts.

Affected Products

• Inbox Zero versions prior to 2.29.3
• The apps/web/app/api/clean/gmail/route.ts cleaner endpoint
• The apps/web/app/api/clean/history/route.ts history endpoint

Discovery Timeline

• 2026-05-11 - CVE-2026-42865 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42865

Vulnerability Analysis

Inbox Zero exposes a Server-Sent Events (SSE) endpoint under the cleaner feature to stream Gmail thread processing events to the browser. The endpoint subscribed to a Redis channel using a process-wide shared listener rather than a per-request, per-account subscription. When multiple authenticated users invoked the cleaner concurrently, the shared subscription dispatched messages to any active stream consumer in the same Node.js process.

This design caused thread events generated for one emailAccountId to be delivered to a client authenticated as a different emailAccountId. The leaked payloads include Gmail thread identifiers and clean action metadata processed through updateThread in @/utils/redis/clean. No authentication bypass was required: the attack required only that two users happened to be using the cleaner feature at the same time.

Root Cause

The root cause is improper isolation of pub/sub subscribers. The cleaner route bound a single Redis subscription callback at module scope and reused it across all SSE clients. Subscription messages carried no per-account filtering, and the route did not scope the channel name or callback closure to the authenticated emailAccountId. The fix introduces assertCleanerApiEnabled and isolates SSE subscriptions per request.

Attack Vector

The vulnerability is exploited passively over the network by an authenticated user. An attacker only needs valid credentials to an Inbox Zero account with cleaner access. While the attacker maintains an open SSE connection to the cleaner endpoint, any concurrent cleaner activity from other tenants can surface in the attacker's stream.

// Patch excerpt: apps/web/app/api/clean/gmail/route.ts
 import { CleanAction } from "@/generated/prisma/enums";
 import { updateThread } from "@/utils/redis/clean";
 import { withQstashOrInternal } from "@/utils/qstash";
+import { assertCleanerApiEnabled } from "@/utils/cleaner-feature";

 const cleanGmailSchema = z.object({
   emailAccountId: z.string(),

Source: GitHub Commit 02341923

// Patch excerpt: apps/web/app/api/clean/history/route.ts
 import { NextResponse } from "next/server";
 import prisma from "@/utils/prisma";
 import { withEmailAccount } from "@/utils/middleware";
+import { assertCleanerApiEnabled } from "@/utils/cleaner-feature";

 export type CleanHistoryResponse = Awaited<ReturnType<typeof getCleanHistory>>;

Source: GitHub Commit 02341923

The added assertCleanerApiEnabled guard and the broader SSE subscription isolation in pull request #2362 ensure each connection receives only events scoped to its own emailAccountId.

Detection Methods for CVE-2026-42865

Indicators of Compromise

• Application logs showing SSE clients on /api/clean/gmail receiving thread events with an emailAccountId that does not match the authenticated session.
• Redis MONITOR output showing a single subscriber callback handling messages across multiple tenants on the cleaner channel.
• User reports of unexpected thread IDs or clean action notifications appearing in the cleaner UI.

Detection Strategies

• Audit access logs for the /api/clean/gmail and /api/clean/history endpoints and correlate session identifiers with event payload emailAccountId values.
• Inspect deployed Inbox Zero builds for the presence of assertCleanerApiEnabled imports in the cleaner and history routes to confirm the patch is applied.
• Review Redis pub/sub channel naming conventions to verify per-account scoping rather than a single shared channel.

Monitoring Recommendations

• Alert on Inbox Zero versions older than 2.29.3 in software inventory feeds and container image scans.
• Monitor outbound SSE response sizes and message rates per session for anomalies that suggest cross-account event leakage.
• Track authentication events for the cleaner feature and flag concurrent sessions handled by a single Node.js process during the exposure window.

How to Mitigate CVE-2026-42865

Immediate Actions Required

• Upgrade all Inbox Zero deployments to version 2.29.3 or later.
• If immediate upgrade is not possible, disable the cleaner feature for all users until the patched release is deployed.
• Rotate any session tokens that were active during periods of concurrent cleaner usage on vulnerable versions.

Patch Information

The fix is delivered in Inbox Zero 2.29.3 through pull request #2362, which isolates SSE subscriptions per request and adds the assertCleanerApiEnabled guard. Review the GitHub Security Advisory GHSA-f3gp-v7cj-2569 and the upstream commit for the full change set.

Workarounds

• Restrict cleaner endpoint access at the reverse proxy to a single tenant per process until upgrading.
• Run separate Inbox Zero instances per tenant so a shared in-process Redis listener cannot bridge accounts.
• Set the cleaner feature flag to disabled in environment configuration to prevent traffic to the affected routes.

# Configuration example: disable the cleaner feature and pin to patched version
# package.json
npm install inbox-zero@2.29.3

# .env
NEXT_PUBLIC_CLEANER_ENABLED=false