CVE-2026-102149 · Kiteworks Email Protection Gateway did not sufficiently restrict wh…

01 · The Real Story

Like a locksmith shop that lets anyone walk in and re-key someone else's house without showing ID

CVE-2026-102149 is a missing-authentication flaw (CWE-306) in the certificate management function of Kiteworks Email Protection Gateway (EPG), all versions prior to 9.5.1. The gateway fails to enforce any authentication on the API endpoint responsible for assigning S/MIME or PGP certificates to user accounts. An unauthenticated, network-reachable attacker can bind their own certificate to any victim account by supplying the target's email address or account ID. Once bound, the attacker can decrypt email intended for the victim (if they intercept it) and — where certificate-based login is enabled — authenticate as the victim outright. The CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L reflects the zero-interaction, zero-privilege nature of the flaw.

The vendor's CRITICAL / 9.4 rating accurately captures the *technical* severity of an unauthenticated remote attack on a trust-infrastructure endpoint. However, it overestimates real-world risk for the majority of defenders. Kiteworks EPG is a niche enterprise product with roughly 1,500 organizational deployments globally; Shadowserver counts only ~400 internet-facing instances, most in the US. The vulnerable endpoint sits on the EPG's management interface, which competent deployments place behind a VPN or internal firewall — not on the internet-facing SMTP path. No public proof-of-concept exists, no exploitation has been observed, and the 78-CVE bulk disclosure dilutes attacker focus. Certificate-based login — required for full account takeover — is an optional feature, not a default. noisgate reassesses this as HIGH / 8.0: still urgent, but the microscopic attack surface and absent tooling make this a 30-day mitigation window rather than a 3-day emergency.

"Unauthenticated cert-rebinding on a trust gateway — HIGH, not CRITICAL, due to tiny attack surface"

02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach the EPG management interface

The attacker identifies a Kiteworks Email Protection Gateway instance whose management interface (typically HTTPS on port 443 or 8443) is network-reachable. Shodan dorks like http.title:"Kiteworks" or favicon hash -1923055866 surface candidates. Shadowserver reports ~400 instances internet-facing globally.

Conditions required:

Network path to EPG management port (443/8443)
Instance running EPG < 9.5.1

Where this breaks in practice:

Most enterprise deployments place the EPG management UI behind VPN or internal firewall; only the SMTP relay ports face the internet
~400 instances internet-facing out of ~1,500 total deployments — roughly 27% exposure rate, but many are US federal/defense with segmented networks

Detection/coverage: Shodan/Censys/FOFA queries for Kiteworks favicon hash or HTTP title. GreyNoise has no dedicated tag for Kiteworks EPG scanning as of 2026-10-01.

STEP 02

Enumerate target account identifiers

The attacker needs the email address or internal user ID of the victim whose certificate they want to rebind. In most EPG deployments, user identifiers map directly to corporate email addresses, which are trivially discoverable via LinkedIn, OSINT, or prior breach data. No EPG-side enumeration API is needed.

Conditions required:

Knowledge of at least one target email address

Where this breaks in practice:

None — email addresses are effectively public

STEP 03

Submit unauthenticated certificate assignment request

The attacker crafts an HTTP request to the EPG's certificate management endpoint, supplying the victim's account identifier and their own public certificate (for which they hold the private key). Because the endpoint has no authentication check (CWE-306), the gateway accepts the request and binds the attacker's certificate to the victim's account. This can be scripted to rebind certificates for all known users in a single pass. No known weaponized tool exists yet; the request is a straightforward REST API call.

Conditions required:

Network access established in Step 1
A valid X.509 or PGP public certificate generated by the attacker

Where this breaks in practice:

No public PoC or weaponized script exists — attacker must reverse-engineer the API contract from the EPG appliance
The exact API endpoint and parameter format are not publicly documented

Detection/coverage: EPG audit logs should record certificate assignment events. Monitor for certificate-change events that originate from non-administrative source IPs or that occur in bulk.

STEP 04

Intercept or receive encrypted email

With their certificate bound to the victim's account, the attacker can now decrypt messages encrypted to the victim — but only if they also intercept the ciphertext. This typically requires a separate network position (MitM on the mail flow, compromise of a mail relay, or access to a mail archive). Alternatively, if the EPG is configured to re-encrypt outbound mail with the recipient's bound certificate, the attacker receives a copy encrypted to their key.

Conditions required:

Ability to intercept encrypted mail traffic or access mail archives
OR: EPG configured to encrypt using the bound certificate on outbound delivery

Where this breaks in practice:

Intercepting TLS-protected SMTP traffic requires a separate compromise (mail relay, DNS hijack, or BGP hijack)
Many organizations additionally use TLS 1.3 point-to-point, which prevents passive interception

Detection/coverage: TLS certificate mismatch alerts on mail relays. DMARC/DKIM validation failures if mail is rerouted.

STEP 05

Authenticate as victim via certificate-based login (conditional)

If the EPG or downstream Kiteworks Core instance is configured to accept certificate-based authentication, the attacker uses their now-bound certificate to log in as the victim. This grants access to the victim's Kiteworks portal — encrypted mail archive, file shares, and secure forms. This path is only available where certificate-based login is explicitly enabled, which is an optional configuration.

Conditions required:

Certificate-based login enabled on the EPG or Kiteworks Core
Attacker's certificate successfully bound in Step 3

Where this breaks in practice:

Certificate-based login is opt-in; many deployments use SAML/OIDC or username+password instead
MFA policies may block login even with a valid certificate

Detection/coverage: Authentication logs showing cert-based login from unusual IPs or with recently rebound certificates. SIEM correlation on certificate-change → login events.

03 · Compensating Control

HIGH 8.0→LOW 3.0

SEVERITY REDUCED

Block external access to EPG management interface immediately — Place a firewall rule or WAF policy that restricts access to the EPG management ports (443/8443) to only authorized admin source IPs or VPN subnets. This breaks Step 1 of the attack chain by eliminating unauthenticated network access from the internet. The SMTP relay ports (25/587) can remain open for mail flow. Deploy within the noisgate mitigation SLA of 30 days — but given the unauthenticated nature, prioritize within 7 days.

HIGH 8.0→HIGH 7.5

Enable audit logging and alerting on certificate assignment events — Configure the EPG to log all certificate binding operations and forward those logs to your SIEM. Create a detection rule that alerts on: (a) certificate assignments from non-admin IPs, (b) bulk certificate changes (>5 in 60 seconds), (c) certificate changes for privileged accounts. This does not prevent exploitation but enables rapid detection and response. Deploy within 30 days per the noisgate mitigation SLA.

HIGH 8.0→MEDIUM 5.5

SEVERITY REDUCED

Disable certificate-based login if not operationally required — If your organization does not rely on certificate-based authentication to the Kiteworks portal, disable it in the EPG/Core configuration. This eliminates Step 5 (account takeover) entirely, reducing the impact to encrypted mail interception only — which itself requires a separate traffic intercept capability. Deploy within 30 days.

HIGH 8.0→IGNORE 0.0

SEVERITY REDUCED

Upgrade to EPG version 9.5.1 — The definitive fix. Version 9.5.1 adds authentication checks to the certificate management endpoint. Apply within the noisgate remediation SLA of 180 days for HIGH severity. Given that Kiteworks deploys as a hardened virtual appliance, the upgrade path is well-defined: snapshot → upgrade → validate mail flow.

What doesn't work

TLS enforcement on mail flow — TLS 1.3 on SMTP protects mail in transit but does not prevent the attacker from rebinding certificates at the API level. The flaw is in the management plane, not the data plane.
S/MIME certificate pinning on the client side — Outlook and other mail clients may cache previously seen certificates, but they do not reject re-encrypted mail from the gateway; the gateway is the trusted intermediary.
Network segmentation of the SMTP ports alone — Blocking port 25/587 externally does not help; the vulnerable endpoint is on the HTTPS management interface, which is a different port and protocol.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None confirmed. Not listed in CISA KEV. No campaigns reported by Proofpoint, Mandiant, or CrowdStrike threat feeds as of 2026-10-01. Kiteworks stated they found "no indication the vulnerability was ever exploited" and "no abnormal activity" during monitoring of the related September 2026 incident.
Proof-of-concept availability	No public PoC found. Not indexed on pocindex.io, ExploitDB, or nuclei templates. No GitHub repositories named after CVE-2026-102149. The vulnerability was disclosed 2026-09-30 as part of a 78-CVE bulk advisory; exploit development likely requires reverse-engineering the EPG's REST API from the appliance image.
EPSS score	Awaiting FIRST scoring. Disclosed <48 hours ago; EPSS typically populates within 7 days. Given the niche product and absent PoC, expect a low percentile (<5%) initially.
KEV status	Not listed in CISA Known Exploited Vulnerabilities catalog as of 2026-10-01.
CVSS vector interpretation	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L` — Full unauthenticated remote attack, no user interaction. The vector is technically accurate: the API endpoint is reachable over the network with zero privileges. Scope is Unchanged (confined to the EPG context). Availability impact is Low because cert rebinding does not crash the service.
Affected versions	Kiteworks Email Protection Gateway ≥ 0 through 9.5.0 (all versions before the fix). Package identifier: `pkg:github/kiteworks/email-protection-gateway`.
Fixed version	9.5.1 — released 2026-09-30 as part of a coordinated 78-CVE disclosure. Both EPG and Kiteworks Core received fixes in 9.5.0 and 9.5.1; this specific CVE requires 9.5.1.
Scanning / exposure data	Shadowserver: ~400 internet-facing Kiteworks instances globally, 234 in the US. Shodan dork: `http.title:"Kiteworks"` or `http.favicon.hash:-1923055866`. GreyNoise has no dedicated Kiteworks tag. No mass scanning observed.
Disclosure context	Disclosed 2026-09-30 as part of a 78-CVE bulk advisory covering Kiteworks Core (28 CVEs), Email Protection Gateway (19 CVEs), and Secure Data Forms. 9 CRITICAL, 35 HIGH, 29 MEDIUM, 5 LOW. The highest-severity flaw is CVE-2026-102115 (CVSS 9.8, password reset → admin takeover).
Vendor / researcher	Disclosed by Kiteworks via coordinated advisory. No external researcher credited. Kiteworks serves ~1,500 enterprises and government agencies globally, with strong presence in US defense and regulated industries.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (8.0/10)

Why this verdict

Unauthenticated API confirms the high base. The CVSS vector's PR:N/UI:N/AC:L is accurate — the certificate management endpoint has zero authentication. Any attacker who can reach the management port can rebind certificates. This is a genuine missing-auth flaw, not a theoretical bypass, and the base score starting point is fair.
Microscopic attack surface applies strong downward pressure. Kiteworks EPG has ~1,500 organizational deployments globally; Shadowserver counts ~400 internet-facing instances. Compare this to a vulnerability in Exchange, Postfix, or Barracuda ESG, which have hundreds of thousands of exposed instances. The reachable population for this CVE is roughly 0.01% of enterprise email infrastructure.
Management interface segregation further narrows exposure. The certificate management API sits on the EPG's administrative HTTPS interface, not on the SMTP relay ports that handle mail flow. Competent deployments restrict management access to internal networks or VPN. The ~400 Shadowserver count likely includes instances where only the mail ports are exposed but the management UI is filtered.
No PoC, no tooling, no exploitation. Disclosed <48 hours ago with zero public exploit code. The attacker must reverse-engineer the undocumented REST API from the appliance image. The 78-CVE bulk disclosure further dilutes attacker focus — CVE-2026-102115 (CVSS 9.8, password reset) is a more attractive target.
Certificate-based login is opt-in. Full account takeover (Step 5) requires certificate-based authentication to be enabled — an optional configuration. Many enterprises use SAML, OIDC, or password+MFA instead. Without cert-based login, the impact is limited to encrypted mail interception, which itself requires a separate traffic intercept capability.
Role multiplier: The Kiteworks EPG is a certificate and email encryption gateway — it functions as trust infrastructure for email. In its canonical deployment role (production email encryption for regulated data), a successful attack enables organization-wide cert rebinding, which is tenant-scale compromise of encrypted email confidentiality and integrity. This sets a floor of HIGH. However, the EPG is not a domain controller, hypervisor, PKI CA, or identity provider — its blast radius is confined to the email encryption layer and does not grant lateral movement to AD, fleet management, or supply chain. The ~1,500-deployment installed base means <0.1% of enterprises run this product, preventing the floor from reaching CRITICAL despite the trust-infrastructure role.

Why not higher?

The vendor's CRITICAL/9.4 would be justified if the EPG were as widespread as Exchange or if the management API were guaranteed internet-facing. Neither is true. With ~400 internet-facing instances globally, no PoC, no exploitation, and certificate-based login as an optional prerequisite for full ATO, the real-world probability of exploitation is materially lower than the CVSS base score implies. A CRITICAL rating would misallocate scarce patching resources away from higher-impact vulnerabilities.

Why not lower?

Despite the small footprint, this IS an unauthenticated remote flaw on a trust-infrastructure component with zero interaction required. The certificate management API handles the cryptographic identity bindings that protect all organizational encrypted email. A scripted attack could rebind every user's certificate in minutes. Even without cert-based login, the integrity of the entire email encryption system is compromised. The trust-infrastructure role sets a hard floor at HIGH.

06 · Verification

Crowdsourced verification payload.

Run this script on the Kiteworks EPG appliance itself via SSH as root (or via the Kiteworks admin console shell). It checks the installed EPG version against the patched version 9.5.1. Example: sudo bash check_cve_2026_102149.sh

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_102149.sh
# Checks whether the Kiteworks Email Protection Gateway is patched
# against CVE-2026-102149 (certificate assignment missing auth).
# Run on the EPG appliance as root.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PATCHED_VERSION="9.5.1"

# Try multiple known locations for version info
VERSION=""
for f in /opt/kiteworks/version /opt/kiteworks/epg/version.txt \
         /etc/kiteworks-release /opt/totemomail/version; do
  if [[ -f "$f" ]]; then
    VERSION=$(grep -oP '[0-9]+\.[0-9]+\.[0-9]+' "$f" | head -1)
    break
  fi
done

# Fallback: try dpkg or rpm
if [[ -z "$VERSION" ]]; then
  if command -v dpkg &>/dev/null; then
    VERSION=$(dpkg -l 2>/dev/null | grep -i 'kiteworks\|epg\|totemomail' \
              | awk '{print $3}' | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  elif command -v rpm &>/dev/null; then
    VERSION=$(rpm -qa 2>/dev/null | grep -i 'kiteworks\|epg\|totemomail' \
              | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  fi
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — Could not determine EPG version. Verify manually."
  exit 2
fi

# Compare versions using sort -V
if printf '%s\n' "$PATCHED_VERSION" "$VERSION" | sort -V | head -1 | grep -qx "$PATCHED_VERSION"; then
  echo "PATCHED — EPG version $VERSION >= $PATCHED_VERSION (CVE-2026-102149 fixed)"
  exit 0
else
  echo "VULNERABLE — EPG version $VERSION < $PATCHED_VERSION (CVE-2026-102149 applies)"
  exit 1
fi

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously