SURIQ
Keycloak sends your password-reset links, email-verification messages, and admin notifications over SMTP. CVE-2026-107121, published on October 7, 2026, means a network attacker sitting between Keycloak and that mail server can quietly cancel the encryption Keycloak believes it negotiated and read those messages, plus the SMTP login, in plaintext. Red Hat scores it 6.5, medium. The number undersells the problem, because the channel it exposes is the one that carries account-recovery tokens. There is no fixed build yet, so the response is a setting you change today.
The flaw is tracked as cleartext transmission of sensitive information (CWE-319) and was reported by Paul Bottinelli of Trail of Bits, working with OpenAI, per Red Hat's advisory. The CVE record is in the PUBLISHED state and names the affected component as keycloak-services, shipped in the Red Hat Build of Keycloak.
How the STARTTLS downgrade works
STARTTLS is opportunistic encryption. The client opens a cleartext SMTP session, asks the server to upgrade the connection to TLS with a STARTTLS command, and only then starts sending anything sensitive. The weak point has always been that first cleartext moment: if an on-path attacker interferes with the upgrade, a client that does not insist on success will keep talking in the clear.
That is what happens here. When STARTTLS is enabled, Keycloak does not strictly require the TLS upgrade to have succeeded. An attacker who can tamper with the traffic can interfere with the upgrade request, and the session drops back to unencrypted while Keycloak carries on sending the SMTP authentication and the message bodies. Red Hat's scoring reflects the shape of this: network-reachable, no credentials and no user interaction required, but high attack complexity because it needs an active man-in-the-middle position. Confidentiality impact is high, integrity is low.
Which Keycloak deployments are exposed
The man-in-the-middle precondition is the governor on real-world risk, so triage by network path, not by the CVSS alone. The deployments that matter are the ones where Keycloak reaches an SMTP relay across a segment an attacker could sit on:
- A cloud-hosted Keycloak talking to an external mail provider over the internet on port 587.
- Keycloak reaching a relay across a VLAN boundary, through a router or gateway an attacker might control.
- Any path reachable from a foothold an attacker already holds, which is exactly the lateral-movement stage defenders should assume after initial access.
The lowest-risk case is a relay on localhost or a trusted same-host sidecar, where there is no untrusted segment to intercept. If your Keycloak points at an outside SMTP service using STARTTLS, treat yourself as in scope.
Close the downgrade window with implicit TLS
Because there is no fixed build to install, the move that removes this outright is to stop relying on opportunistic STARTTLS and use implicit TLS instead. Implicit TLS, often called SMTPS on port 465, wraps the entire session in TLS from the first byte. There is no cleartext STARTTLS negotiation for an attacker to interfere with, so the downgrade path simply does not exist. In the Keycloak admin console, open the email settings and switch encryption from StartTLS to SSL:
Host: smtp.example.com Port: 465 Enable SSL: On Enable StartTLS: Off Enable Authentication: On
In an exported configuration the same change is the smtpServer block's ssl and starttls values. Pair it with network hygiene: keep the mail path on a trusted segment, and do not route Keycloak's SMTP across an untrusted network if an encrypted-from-the-start option exists on your provider.
How to tell if the channel is being stripped
Detection here is about the connection, not a file on disk. Watch the Keycloak host for SMTP sessions that advertise STARTTLS and then never complete the TLS handshake, and for any mail connection that carries AUTH or a message body while the session is still cleartext. On the network between Keycloak and the relay, alert on SMTP traffic to port 587 or 25 that stays in plaintext after an upgrade was offered. Collecting and keeping those connection logs from your identity server is what turns a silent downgrade into something you can see. This is the kind of continuous log and network monitoring that Suriq's managed detection is built to run for the services you expose.
Move Keycloak's mail to port 465 before a patch exists
The first action is concrete and does not wait on the vendor: switch Keycloak's email connection to implicit TLS on port 465 and confirm StartTLS is off. Then audit which deployments reach their relay across an untrusted path, because those are where the medium score hides a real exposure.
This is the soft edge of identity infrastructure showing again. The trust and mail boundaries of an authentication server keep producing bugs that look small in isolation: we have written up a secret-handling flaw in Keycloak and an unauthenticated account-takeover bug in recent months, and Keycloak has had STARTTLS-handling mistakes before, including the much older LDAP authentication bypass tracked as CVE-2019-14910. The lesson for defenders is to stop treating the email channel of an identity server as plumbing. It carries the tokens that reset accounts, and it deserves the same encryption discipline as the login flow itself.