CVE-2026-102095: Critical Unauthenticated SSRF in Kiteworks Email Protection Gateway

Overview

Kiteworks has disclosed CVE-2026-102095, a critical Server-Side Request Forgery (SSRF) vulnerability in its Email Protection Gateway affecting all versions before 9.5.0. According to the National Vulnerability Database (NVD) and Kiteworks's own GitHub security advisory (GHSA-f252-4w8q-g74g), the gateway "performed server-side fetches of URLs contained in the message content it processed, without adequately restricting the fetch destination." The flaw was credited to researchers truff, Icare, and wlayzz, reported through the YesWeHack bug bounty program, and was reserved on September 28, 2026 and published on September 30, 2026, carrying a CVSS 3.1 base score of 9.1 (Critical). It is fixed in version 9.5.0.

CVE-2026-102095 is one of several SSRF findings disclosed against the Email Protection Gateway at the same time — it sits alongside CVE-2026-102102, CVE-2026-102103, CVE-2026-102104, and CVE-2026-102105 — as part of a much larger Kiteworks security update spanning 78 vulnerabilities (9 rated Critical) across its Core platform, Email Protection Gateway, and forms products, comprehensively resolved in version 9.5.1. No in-the-wild exploitation has been reported for any of these issues as of this writing.

Technical Details

How It Works

SSRF in a nutshell

Server-Side Request Forgery occurs when a server-side component fetches a resource at a URL supplied (directly or indirectly) by an untrusted party, without adequately validating or restricting where that fetch is allowed to go. The attacker doesn't need network access to the target destination themselves — they only need to convince the vulnerable server to make the request on their behalf. Because the request originates from the trusted server, it can reach internal services, management interfaces, and cloud metadata endpoints that are normally shielded from the public internet.

How the gateway's URL fetch becomes a weapon

Per NVD and the vendor advisory, the Email Protection Gateway performs server-side fetches of URLs found in the message content it processes — functionality presumably intended for things like link previews, attachment-by-reference resolution, or similar message-rendering features common to email security gateways. The vulnerable code path did not adequately restrict which destinations that fetch could target. A remote, unauthenticated sender could therefore embed a URL pointing at an internal address (an RFC 1918 address, a loopback address, or a cloud provider's instance metadata service, for example 169.254.169.254 on AWS/Azure) inside a message, and have the gateway itself issue the outbound request on the attacker's behalf when it processed that message.

A plausible attack chain

1. An attacker crafts and sends an email (or otherwise submits content) to a Kiteworks Email Protection Gateway deployment running a pre-9.5.0 build, with a URL in the message body or a related field pointed at an internal or cloud-metadata destination rather than a legitimate external resource.
2. The gateway's message-processing pipeline parses the content and performs its server-side URL fetch as part of normal handling — no authentication or prior session with the gateway is required, since the trigger is simply processing an inbound message.
3. The fetch request is issued from the gateway itself, which typically sits in a trusted position in the network (often with reachability to internal services and, in cloud deployments, to the instance's metadata endpoint).
4. Depending on what the fetch returns and how the gateway surfaces it (directly in a response, in logs, in a rendered preview, or indirectly via timing/behavior), the attacker may be able to infer or directly read back data from the internal destination — including, in a worst case against cloud metadata services, temporary credentials or API keys.

The CVSS vector's C:H/I:H/A:N sub-scores indicate the realistic worst case is confidentiality and integrity impact — exposure of internal data and the ability to influence what the gateway interacts with — without a direct availability/denial-of-service component from this specific flaw.

Part of a broader disclosure batch

NVD's record for CVE-2026-102095 does not include analyst notes distinguishing it mechanically from the other SSRF CVEs disclosed in the same Kiteworks update, and the NVD description text for this entry is generic: a server-side fetch of message-embedded URLs without adequate destination restriction. Third-party CVE aggregators have characterized the neighboring IDs as targeting more specific fetch flows — for example, describing CVE-2026-102102 as triggered during certificate issuer retrieval, and CVE-2026-102105 as triggered while the gateway renders message content that references external resources — which would make CVE-2026-102095 the more general "URL fetching from message content" entry in the set. That characterization comes from secondary sources, not from NVD's or the vendor's own text for this specific CVE ID, so it should be treated as a plausible read of the disclosure batch rather than a confirmed, vendor-stated distinction. What is confirmed: both CVE-2026-102095 and CVE-2026-102102 share the same CWE-918 classification, the same CVSS 9.1 severity, the same unauthenticated/no-interaction attack profile, and the same affected-version boundary (before 9.5.0) — and both are addressed by the same upgrade.

Impact Assessment

Recommendations

For organizations running Kiteworks Email Protection Gateway

1. Upgrade to version 9.5.0 or later immediately. Given the broader 78-vulnerability disclosure, upgrading to 9.5.1 (which addresses the full set, including the separate CVSS 9.8 password-reset authentication flaw, CVE-2026-102115) is the more complete remediation.
2. Confirm your current version before assuming you're unaffected — this flaw applies to "all versions prior to 9.5.0," which likely covers a wide range of deployments that haven't recently patched.
3. If immediate patching isn't possible, restrict the gateway's outbound network access at the firewall/network layer — deny reachability to RFC 1918 internal ranges and cloud metadata addresses (for example 169.254.169.254) from the gateway host wherever operationally feasible.
4. Harden cloud metadata access independently of this patch — enforce IMDSv2 (or your cloud provider's equivalent session-bound metadata protocol) on any instance running the gateway, so that even a successful SSRF cannot retrieve long-lived credentials.

For security teams

1. Treat this as part of a batch, not an isolated bug — the same disclosure includes four other SSRF CVEs against the same gateway (CVE-2026-102102 through CVE-2026-102105) plus a critical authentication bypass (CVE-2026-102115) and remote-code-execution findings (CVE-2026-102097, CVE-2026-102108, CVE-2026-102131, CVE-2026-102135). Patch for the full set, not just this one CVE ID.
2. Review egress logs from the gateway for outbound requests to internal or unexpected destinations around and after message processing, looking for signs of prior exploitation attempts.
3. Apply standard SSRF compensating controls where the gateway can't be patched immediately: an egress proxy with destination allow-listing, and a WAF/IPS ruleset tuned to flag suspicious URL patterns in inbound message content.

For detection

1. Monitor for outbound connections initiated by the gateway host toward private IP ranges, loopback addresses, or cloud metadata endpoints that fall outside its normal external-fetch patterns.
2. Flag inbound messages containing URLs that resolve to internal/private addresses — a strong signal of attempted exploitation, whether or not the gateway is already patched.

Key Takeaways

1. CVE-2026-102095 is a CVSS 9.1 critical, unauthenticated Server-Side Request Forgery (CWE-918) in Kiteworks Email Protection Gateway versions before 9.5.0, published September 30, 2026.
2. The gateway performs server-side fetches of URLs embedded in processed message content without adequately restricting the fetch destination, letting a remote sender direct requests at internal services or cloud metadata endpoints with no authentication and no user interaction required.
3. It is fixed in version 9.5.0, and is one of five related SSRF CVEs (alongside CVE-2026-102102 through CVE-2026-102105) disclosed in the same Kiteworks update — a 78-vulnerability release (9 Critical) fully resolved in version 9.5.1.
4. NVD's record does not clearly distinguish this CVE's exact trigger mechanism from the closely related CVE-2026-102102; third-party aggregators describe neighboring IDs as targeting more specific fetch flows (certificate retrieval, message rendering), but that distinction is not confirmed in NVD's or the vendor's text for this specific ID.
5. Impact is rated High for confidentiality and integrity, None for availability — the primary risk is internal data exposure and influence over internal service state, not denial of service.
6. No in-the-wild exploitation or CISA KEV listing has been reported as of this writing, but given the unauthenticated, zero-interaction attack profile, organizations should patch to 9.5.0/9.5.1 without delay rather than wait for confirmed exploitation.

Sources

• NVD — CVE-2026-102095
• GitHub Security Advisory — GHSA-f252-4w8q-g74g
• CISA CSAF — VA-26-274-01
• SecurityOnline — Kiteworks Patches 78 Vulnerabilities, Including Critical Account Takeover Flaw

CosmicBytez Labs will update this advisory if Kiteworks publishes additional analyst detail distinguishing this CVE from CVE-2026-102102, or if active exploitation is confirmed.