CVE-2026-107121 is a downgrade weakness in how Keycloak sent email. When a realm’s SMTP settings had Enable StartTLS switched on, Keycloak asked the mail server to upgrade to an encrypted connection, but if the server did not offer the upgrade (or an attacker on the network removed the offer), Keycloak carried on anyway and sent the SMTP login and the message in plaintext. Keycloak 26.8.1, tagged on 13 October 2026, fixes it by making the upgrade mandatory: with StartTLS enabled, a failed upgrade now means the email is not sent. Because of that, 26.8.1 is also a breaking change for any realm whose mail relay never supported StartTLS in the first place.
This post explains what the bug was, why a setting called “enable” did not mean “require”, who needs to act, and how to check your realms after upgrading. If you only need to set up SMTP from scratch, the Keycloak email configuration guide covers that, and this post only deals with the CVE.
What exactly did CVE-2026-107121 let an attacker do?
An attacker positioned between Keycloak and the SMTP relay could strip the relay’s STARTTLS advertisement from the conversation, and Keycloak would then continue the session unencrypted. No CVSS score or separate security advisory had been published for this CVE when I checked on 13 October 2026, so the upgrade guide entry is the primary source. The 26.8.1 upgrade guide describes the old behavior this way: if the SMTP server did not advertise STARTTLS, or a network attacker stripped the advertisement, Keycloak “continued and sent credentials and message content in plaintext” (Keycloak 26.8.1 upgrading guide, “SMTP StartTLS is required when enabled”).
Two kinds of data were exposed in that situation. The first is the SMTP username and password that the realm uses to authenticate to the relay. The second is the content of every message sent during the session, and for an identity provider that content is sensitive by nature: email verification links, password reset links, one-time passcodes if you use email OTP, and the emails that an administrator triggers, such as organization invitations and required-action emails.
The attacker needs to be on the network path between Keycloak and the relay, so this is not something anyone on the internet can trigger against a relay that sits inside a private network. It matters more when the relay is a third-party service reached over the public internet, or when your cluster network is shared with workloads you do not fully trust.
Why did “Enable StartTLS” not mean the connection was encrypted?
STARTTLS is a command defined in RFC 3207 that lets a client and server begin a conversation in plaintext and then upgrade it to TLS. Because the first part of the conversation is unencrypted, the client has to decide what to do when the server does not offer the upgrade. If the client carries on without TLS, that is called opportunistic TLS: you get encryption when both sides cooperate and nothing when they do not.
Opportunistic TLS protects against passive eavesdropping but not against an active attacker, because the attacker can simply delete the line in which the server says it supports STARTTLS, and the client treats the server as one that never offered it. The standard defense is for the client to treat the upgrade as mandatory, which is exactly what the Keycloak fix does.
Keycloak sends mail through Jakarta Mail, which exposes two separate properties for this: mail.smtp.starttls.enable, which tells the library to use the STARTTLS command if the server supports it, and mail.smtp.starttls.required, which tells it to fail if the server does not. Before 26.8.1, Keycloak set only the first one. The fix in DefaultEmailSenderProvider adds the second whenever the realm’s StartTLS option is on, with a code comment that says it is there to “prevent STARTTLS downgrade: fail if the server does not advertise STARTTLS”.
Which Keycloak versions and realms are affected?
Realms are affected when all of the following were true, based on the source of the releases I checked on 13 October 2026:
- The realm’s SMTP settings (Realm settings, Email tab, Connection & Authentication) had Enable StartTLS on.
- The server was running a version of
DefaultEmailSenderProviderwithout thestarttls.requiredline. The 26.8.0 source does not have it, and neither do the latest tags of the older lines I looked at (26.7.5, 26.6.7 and 26.4.16). The 26.8.1 tag has it. - An attacker could modify traffic between Keycloak and the relay.
Realms that used implicit TLS (the Enable SSL option, usually on port 465) were not relying on the upgrade command in the first place, and realms that used plain SMTP with both options off were never encrypted to begin with. The 26.8.1 upgrading guide lists the fix and marks it as a breaking change. For older lines, the position on 13 October 2026 is this: the fix has been merged to the release/26.6 branch and its upgrade note is already written for 26.6.8, but 26.6.8 had not been released yet. The release/26.4 branch did not have it as of 12 October. The 26.7 and 26.5 lines are archived upstream, so they will not get a patch, and anyone on them has to move to 26.8.1 (or to 26.6.8 once it ships).
What breaks after you upgrade to 26.8.1?
Any realm that had Enable StartTLS on while talking to a relay that does not support STARTTLS will stop sending mail. Before the upgrade it worked silently because Keycloak fell back to plaintext; after the upgrade it fails, and the user sees whatever error the flow produces when email cannot be sent (for example, a failed password reset or a verification email that never arrives). The user sees a generic “Failed to send email, please try again later” message in that case. The upgrade guide gives the two ways out: confirm your SMTP server supports StartTLS, or turn off Enable StartTLS if you deliberately use plaintext SMTP without TLS.
The second option is only reasonable on a network you control end to end. For anything that crosses the internet, the better fix is on the relay side, or switching to implicit TLS. RFC 8314 recommends implicit TLS for mail submission over STARTTLS where both are available, because it removes the plaintext phase entirely.
How do you verify your realms after the upgrade?
A short test plan is enough, and it should run in staging first.
- Send a test email from each realm. In Realm settings, Email tab, use the Test connection button (the test email goes to the signed-in admin’s own address, so give that admin an email address first). If it fails with a TLS or STARTTLS error, the relay is not offering the upgrade on that port.
- Check the port and the option together. Submission ports are typically 587 with StartTLS and 465 with SSL. If the two do not match your relay’s documentation, fix that first, because a mismatch is one way to end up with a failed upgrade that has nothing to do with an attacker.
- Trigger the real flows. Run a password reset, an email verification, and any email-based second factor you use, since these are the flows your users depend on.
- Watch the logs for send failures for a day after the rollout. Realms that are rarely used can hide a broken relay until someone needs a reset email.
- Rotate the SMTP credentials if there was a plausible exposure. If your relay is reached across a network you do not control and StartTLS was only opportunistic, treat the SMTP password as potentially seen and replace it. There is no evidence in the upstream notes that exploitation occurred, so this is a precaution that depends on your own threat model.
What else should you review about email in your identity provider?
Email is part of your authentication surface even when you use another factor for sign-in, because password reset and verification links let someone take over an account if they can read the message. It is worth knowing which of the following your realms use:
- Email-based password reset and verification. These are the highest-value messages. Short link lifetimes limit the damage of any exposure.
- Email OTP. If you use a one-time passcode sent by email, the code travels the same path as any other message from the realm.
- Relay authentication. Use a dedicated sending account with the narrowest permissions your provider offers, not a personal mailbox.
If emails are failing for reasons unrelated to TLS, the email not sending troubleshooting guide walks through the usual causes. For the other fixes that shipped around this period, the same 26.8.1 release also changed X.509 CRL loading and Kerberos ticket handling, and an earlier patch release is covered in the Keycloak 26.7.4 patch checklist.
What does this mean if Skycloak runs your Keycloak?
On a managed deployment the cluster follows upstream releases, so the version that carries this fix reaches your cluster through the normal patch process, and it is worth confirming with us which version your cluster is on and when the move to 26.8.1 or later is planned. Because the fix is a breaking change for relays that do not support StartTLS, check your realm’s mail settings and test them in a non-production realm before the upgrade lands. Our trust page lists how we handle security and procurement questions if you need that for your records.
Frequently asked questions
Is CVE-2026-107121 remotely exploitable by anyone on the internet?
No. The attacker has to be able to alter traffic between Keycloak and the SMTP relay, for example on a shared network segment or somewhere along the route to a third-party relay. Without a position on the network path there is nothing to strip.
What is the difference between StartTLS and SSL in Keycloak’s email settings?
StartTLS begins in plaintext and upgrades the connection with a command, usually on port 587. SSL (implicit TLS) wraps the connection in TLS from the first byte, usually on port 465. Since 26.8.1, turning StartTLS on means the upgrade must succeed.
Do I need to rotate my SMTP password?
Only if the credentials may have crossed an untrusted network in plaintext. If the relay was on a private network you control, the risk is low. If it was a third-party service over the internet and StartTLS was opportunistic, rotating is a sensible precaution.
Why did my realm stop sending email after upgrading to 26.8.1?
The most likely cause is a relay that does not offer STARTTLS on the configured port. Check the host and port, and use Test connection in the Email tab. If you deliberately use plaintext SMTP on a trusted network, you can turn off Enable StartTLS, as the upgrade guide describes.
Did Keycloak backport the fix to older lines?
Partly. As of 13 October 2026 the fix was merged to the 26.6 branch for the unreleased 26.6.8, it was not on the 26.4 branch as of 12 October, and the 26.7 and 26.5 lines are archived and will not be patched. Check the release notes for your line before relying on a point release.