SECURITYCRITICALCVE-2026-102102

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

Unauthenticated SSRF (CVSS 9.1) in Kiteworks Email Protection Gateway lets attackers force the gateway to fetch internal resources via certificate validation.

Dylan H.

Security Team

October 1, 2026
10 min read
CVE-2026-102102: Critical Unauthenticated SSRF in Kiteworks Email Protection Gateway

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • Kiteworks Email Protection Gateway versions prior to 9.5.0

Overview

Kiteworks Email Protection Gateway, deployed versions before 9.5.0, is affected by CVE-2026-102102, a critical Server-Side Request Forgery (SSRF) flaw. Per NVD and the vendor's own GitHub Security Advisory (GHSA-jxv9-v53f-c79m), the weakness lets a remote, unauthenticated attacker induce the gateway to issue crafted requests to internal or otherwise unintended network destinations. The vendor advisory specifies that the flaw manifests when the gateway retrieves an issuer certificate referenced by an inbound message during certificate validation — a server-side fetch step that doesn't adequately restrict where the gateway is allowed to connect. NVD assigned a CVSS 3.1 score of 9.1 (Critical) and published the record on September 30, 2026; no patch date discrepancy exists here — version 9.5.0 resolves it.

This CVE was disclosed alongside several closely related CWE-918 SSRF findings in the same Email Protection Gateway component, as part of a much larger Kiteworks security update. See "Part of a broader disclosure batch" below for how it fits into that picture — and for an honest note on where this advisory can and cannot distinguish CVE-2026-102102 from its closest sibling, CVE-2026-102095.

Technical Details

AttributeValue
CVE IDCVE-2026-102102
SeverityCritical
CVSS Score9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H)
Attack VectorNetwork
AuthenticationNot required (PR:N) — no user interaction needed (UI:N)
CWECWE-918 — Server-Side Request Forgery (SSRF)
Component / Affected FlowIssuer-certificate retrieval during inbound-message certificate validation (per vendor GitHub Security Advisory GHSA-jxv9-v53f-c79m)
Exploit StatusNo public proof-of-concept or confirmed in-the-wild exploitation identified as of publication; NVD analysis status listed as "Awaiting Analysis"
Patch StatusFixed in Email Protection Gateway 9.5.0 (superseded by the consolidated 9.5.1 release that closes out the full 78-vulnerability Kiteworks batch)

How It Works

The vulnerability class

CVE-2026-102102 is a textbook Server-Side Request Forgery (CWE-918): a server-side component makes an outbound network request to a destination that is, in whole or in part, attacker-influenced, without adequately validating or restricting where that request can go. SSRF bugs are especially dangerous in internet-facing infrastructure that also has privileged reach into internal networks — which describes an email security gateway almost by definition, since it must sit at the network edge to inspect inbound mail while often retaining connectivity back into internal systems.

The attack chain

  1. Kiteworks Email Protection Gateway validates certificates associated with inbound messages as part of its mail-security processing (for example, verifying signed/S-MIME mail or sender certificate chains).
  2. As part of that validation, the gateway needs to retrieve the issuer certificate — the certificate of the authority that signed the message's certificate — and does so by fetching a URL referenced by the inbound message.
  3. Because an unauthenticated remote sender controls the content of an inbound message, they can craft a message in which that issuer-certificate reference points somewhere the gateway should never be allowed to reach: an internal admin interface, an internal-only service, or a cloud instance metadata endpoint (169.254.169.254 and equivalents on AWS/Azure/GCP) that often holds IAM credentials.
  4. The gateway — reachable by design from the public internet to receive mail, and requiring no authentication and no user interaction to trigger this flow — issues the crafted request on the attacker's behalf, from inside whatever network segment the gateway itself occupies.
  5. Depending on what's reachable and how (or whether) results are reflected back, this can disclose sensitive internal data, or simply tie up gateway resources against slow/unreachable targets, degrading mail processing.

How this differs from CVE-2026-102095 — and where our confidence ends

CVE-2026-102102 is frequently discussed alongside CVE-2026-102095, a separate, also-critical SSRF in the same gateway. Per the task brief for this advisory and our own research, CVE-2026-102095 covers server-side fetches of URLs contained in inbound message content itself (i.e., the gateway following a link embedded in the body/attachment of a message it's rendering or processing). CVE-2026-102102, by contrast, is specifically about the issuer-certificate retrieval step of certificate validation — a different internal code path triggered by certificate-chain handling, not message-content rendering.

That distinction comes from the vendor's GitHub Security Advisory for CVE-2026-102102, which explicitly names the issuer-certificate-retrieval mechanism. NVD's own base description for this CVE is generic ("induce the gateway to issue crafted requests to internal... network resources") and, as of this writing, does not itself include analyst notes contrasting CVE-2026-102102 against CVE-2026-102095 or the other related CVEs below — so where we draw on the vendor advisory rather than NVD directly, we've said so.

Part of a broader disclosure batch

CVE-2026-102102 was not disclosed in isolation. Per Kiteworks' own advisory ecosystem and third-party coverage, this release addressed 78 security vulnerabilities across the Kiteworks platform (Core, Email Protection Gateway, and forms products) — broken down as roughly 9 Critical, 35 High, 29 Medium, and 5 Low. The single most severe finding in the batch is a separate, unrelated bug, CVE-2026-102115 (CVSS 9.8), a password-reset flaw that reportedly lets an attacker who knows a user's email address bypass verification and reset that user's password — including administrative accounts.

Within the Email Protection Gateway specifically, third-party CVE trackers (strix.ai, aggregator sites) describe five Critical SSRF findings sharing CWE-918, all affecting versions before 9.5.0:

  • CVE-2026-102095 — SSRF via server-side fetch of URLs in inbound message content
  • CVE-2026-102102 — SSRF via issuer-certificate retrieval during inbound-message certificate validation (this advisory)
  • CVE-2026-102103 — reported by third-party trackers as SSRF triggered during certificate revocation list (CRL) retrieval for inbound messages
  • CVE-2026-102104 — reported by third-party trackers as SSRF triggered during an online certificate status (OCSP) check for inbound messages
  • CVE-2026-102105 — reported by third-party trackers as SSRF triggered while rendering message content that references external resources

We want to be precise about confidence levels here: the mechanism for CVE-2026-102102 above is vendor-confirmed via its GitHub Security Advisory. The mechanisms described for 102103, 102104, and 102105 come from third-party aggregator summaries we were not able to independently verify against a vendor advisory for each individual CVE, and in places those summaries were not fully consistent with each other (particularly around what exactly 102105 covers versus 102095). Treat those three as "reported elsewhere to be related and similarly scoped," not as independently confirmed by this publication. All five share the same affected-version range (before 9.5.0) and the same fix (9.5.0), so the practical patching guidance is identical regardless of the exact internal mechanism.

Impact Assessment

Impact AreaDescription
ConfidentialityRated High (C:H) — if the gateway can be induced to reach an internal admin endpoint or cloud metadata service, the content of the response may expose credentials, tokens, or internal configuration data
IntegrityRated None per the CVSS vector (I:N) — the SSRF itself doesn't directly let an attacker modify gateway or internal-system data, though credentials disclosed via confidentiality impact could enable integrity-affecting follow-on attacks
AvailabilityRated High (A:H) — repeatedly forcing the gateway to connect to slow, unreachable, or malicious hosts during certificate validation can exhaust connections or threads, disrupting inbound mail processing
Network Position / Trust BoundaryEmail security gateways sit at the network edge by necessity (to receive inbound mail) while often retaining broader internal reachability than a typical public-facing service — making a pre-auth SSRF here a direct bridge from the open internet into otherwise-unreachable internal segments
Cloud Metadata ExposureIf the gateway runs on cloud infrastructure, a crafted issuer-certificate URL pointed at the instance metadata service could leak IAM/role credentials — the classic high-value SSRF outcome flagged by third-party trackers covering this disclosure batch
Regulatory / Data-Sensitivity ExposureKiteworks markets Email Protection Gateway for regulated, compliance-sensitive mail flows (healthcare, government, defense); SSRF-driven internal recon or credential exposure in those environments carries outsized downstream risk

Recommendations

For organizations running Kiteworks Email Protection Gateway

  1. Upgrade to 9.5.0 at minimum. Kiteworks has since shipped 9.5.1, which consolidates fixes for the full 78-vulnerability batch — including the CVSS 9.8 password-reset/account-takeover bug (CVE-2026-102115). Where feasible, go straight to 9.5.1 rather than patching piecemeal.
  2. Treat this as pre-authentication and network-reachable — don't wait for a routine maintenance window if the gateway is internet-facing, which it functionally must be to receive inbound mail at all.
  3. Restrict the gateway's outbound egress with a proxy or allow-list so it cannot reach arbitrary internal IP ranges or cloud metadata addresses, as defense in depth beyond patching alone.
  4. If hosted on cloud infrastructure, enforce IMDSv2 (or the equivalent token-required metadata API) on the underlying instance, so a bare SSRF request cannot retrieve credentials even if egress filtering is incomplete.

For security teams

  1. Patch all five related SSRF CVEs together — CVE-2026-102095, 102102, 102103, 102104, and 102105 share CWE-918 and the same before-9.5.0 affected range, so a single upgrade closes all of them regardless of which exact code path each one occupies.
  2. Don't conflate CVE-2026-102102 with CVE-2026-102095. Per the vendor's own advisory language, this one is about issuer-certificate retrieval during certificate validation, not message-content URL fetching — different entry points worth validating independently in any internal tracking or risk register, even though the remediation is the same.
  3. Track Kiteworks' trust/security center and CISA's KEV catalog for updates, given this CVE is part of a much larger 78-finding batch headlined by a more severe account-takeover bug.

For detection

  1. Watch gateway/firewall egress logs for outbound connections from the Email Protection Gateway host to RFC1918 address ranges, loopback, or cloud metadata IPs (169.254.169.254 and equivalents) that fall outside its normal mail-relay and update-check baseline.
  2. Alert on unusual delays, timeouts, or crash-and-restart patterns in the gateway's certificate-validation path, which may indicate SSRF probing against unreachable or slow-responding internal targets.
  3. If your mail-filtering pipeline logs certificate metadata from inbound messages, flag unusual or non-standard issuer-certificate URLs for review.

Key Takeaways

  1. CVE-2026-102102 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. Per the vendor's GitHub Security Advisory, it's triggered when the gateway retrieves an issuer certificate referenced by an inbound message during certificate validation — not during message-content rendering, which is the separate CVE-2026-102095.
  3. No authentication or user interaction is required to trigger it; the CVSS vector rates confidentiality and availability impact High, consistent with the classic SSRF-to-cloud-metadata risk pattern.
  4. It's fixed in 9.5.0; Kiteworks' broader 9.5.1 release closes out a 78-vulnerability batch that also includes a more severe CVSS 9.8 password-reset/account-takeover bug (CVE-2026-102115) and up to four sibling Critical SSRF findings in the same gateway component.
  5. NVD's base description does not itself distinguish CVE-2026-102102 from its closest sibling, CVE-2026-102095 — that distinction comes from the vendor advisory, and the mechanisms reported for some of the other sibling CVEs (102103–102105) come from third-party trackers we could not fully independently verify.
  6. No public proof-of-concept or confirmed in-the-wild exploitation exists as of publication, but given the pre-auth, no-user-interaction profile and the gateway's inherent internet exposure, patching should not wait for a routine cycle.

Sources

CosmicBytez Labs will update this advisory if Kiteworks publishes further analyst notes distinguishing the Email Protection Gateway SSRF CVEs, or if active exploitation of CVE-2026-102102 is confirmed.