CVE-2026-102095 in Email Protection Gateway
Summary
by MITRE • 10/01/2026
Kiteworks Email Protection Gateway before version 9.5.0 is vulnerable to Server-Side Request Forgery. Kiteworks Email Protection Gateway performed server-side fetches of URLs contained in the message content it processed, without adequately restricting the fetch destination. A remote, unauthenticated sender could craft a message that caused the gateway to issue requests to internal services and cloud instance metadata endpoints and return the responses, potentially disclosing sensitive internal data and, depending on the internal service reached, affecting its state.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in Kiteworks Email Protection Gateway prior to version 9.5.0 represents a critical Server-Side Request Forgery (SSRF) flaw rooted in insufficient input validation of URL parameters embedded within processed email messages. The core technical failure lies in the gateway's mechanism for fetching URLs contained in message content, which operates without adequate restrictions on destination addresses or protocols. This architectural oversight allows an attacker to manipulate the target endpoint by crafting a maliciously formatted email that instructs the server to initiate HTTP requests to arbitrary destinations. Because the validation logic fails to distinguish between external public resources and internal network segments, the application effectively acts as a proxy for unauthenticated remote actors, enabling them to leverage the gateway's privileged position within the network infrastructure to access sensitive backend services.
From an operational perspective, this vulnerability poses severe risks regarding data confidentiality and system integrity. An attacker can exploit this flaw to probe internal networks that are typically isolated from direct internet exposure, including cloud instance metadata endpoints such as those found in AWS EC2 or Azure managed identities. Accessing these metadata services is particularly dangerous because they often contain temporary security credentials, API keys, and configuration details necessary for authenticating with other cloud resources. By retrieving this information, an adversary can escalate privileges within the cloud environment, potentially gaining control over associated virtual machines or storage buckets. Furthermore, depending on the specific internal service targeted by the forged requests, the attacker may be able to trigger unintended state changes, leading to denial of service conditions or further exploitation of backend applications that trust requests originating from the email gateway due to its trusted network location.
This vulnerability aligns with Common Weakness Enumeration (CWE) ID 918, which defines Server-Side Request Forgery as a weakness where a web server retrieves a specified resource using a user-supplied URL without proper validation of the destination address. In terms of offensive security tactics, this exploitation vector corresponds to ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer variants that involve leveraging internal services for reconnaissance and credential access. The ability to interact with cloud metadata endpoints is a hallmark of modern cloud-native attacks, where initial footholds are used to pivot deeper into the infrastructure by stealing identity tokens rather than attempting direct brute-force authentication against exposed ports.
To mitigate this risk, organizations must immediately upgrade Kiteworks Email Protection Gateway to version 9.5.0 or later, which addresses these validation gaps through enhanced URL parsing and destination filtering mechanisms. In environments where an immediate patch is not feasible, network-level controls should be implemented to restrict the email gateway's outbound traffic. This includes configuring firewall rules to block access to private IP ranges such as RFC 1918 addresses for internal services and blocking requests to known cloud metadata endpoint IPs like 169.254.169.254 for AWS or similar reserved addresses for other providers. Additionally, implementing strict allow-listing of permitted URL schemes and domains within the application configuration can provide a defense-in-depth layer that prevents the gateway from being abused as an open proxy for internal network reconnaissance.