Last updated: September 2026
CVE-2026-82968 is a moderate flaw in Keycloak’s first-broker-login flow: the verification proof generated during account linking is not strictly bound to the specific upstream identity being verified. An attacker holding a different account on the same social provider can intercept the linking step and end up attached to someone else’s local profile. It carries a CVSS 3.1 base score of 6.4 and is classified as CWE-639. As of 11 September 2026 there is no patched Keycloak release, and the upstream tracking issue is still open, so the work available to you today is configuration hardening rather than an upgrade.
That pending status is the main thing to get straight before you plan around this one. Several triage write-ups have paired the CVE with a generic “upgrade Keycloak” instruction. There is currently nothing to upgrade to.
What does CVE-2026-82968 actually allow?
The flaw is a binding failure between the proof of verification and the identity that proof was supposed to cover. Per the GitHub Advisory Database entry GHSA-2w6p-j7xq-6p7v, published 2 September 2026, “the verification proof generated is not strictly bound to the specific upstream identity being verified,” which permits an attacker with a separate account on the same social provider to intercept the linking process and reach the victim’s local profile.
To see why that matters you need what first-broker-login does. When someone signs in through a social or external identity provider and Keycloak has never seen that upstream identity before, it has to decide between two things: create a fresh local user, or link this upstream identity to a local account that already exists. That second path is the sensitive one. Linking says “this Google account and this local account are the same person,” and everything downstream trusts it.
The verification step is what’s supposed to establish the claim. When the proof of that step isn’t tightly bound to the specific upstream identity in play, the association can be made with an identity other than the one that was verified. The result is a persistent wrong link rather than a one-off session anomaly. That persistence is what makes it worth acting on: the bad association stays in your identity store until someone notices and unlinks it.
Keycloak’s own tracking issue, keycloak/keycloak#52321, “[CVE-2026-82968] Persistent wrong-account linking through null / GitHub identity provider”, is labelled area/identity-brokering, kind/cve and priority/important, and remains open at the time of writing.
How serious is it, really?
The CVSS vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N, and the three middle components are the ones that should shape your urgency.
Attack complexity is high. Privileges required is low, meaning the attacker needs an account of their own on the same social provider, which is not much of a barrier when the provider is Google or GitHub. User interaction is required, so the victim has to be moving through a linking flow for the attack to land. Confidentiality and integrity impact are both high, which is what pulls the score up to 6.4 despite those preconditions.
Put plainly: this isn’t a flaw someone runs against your realm on a schedule. It needs a victim mid-linking and an attacker positioned for it. That’s why it scores moderate rather than critical, and it’s a genuine difference from something like the unauthenticated reset-credentials takeover in CVE-2026-18963, which needs no privileges and no user interaction at all.
Our read: the preconditions make this lower urgency than the score alone suggests, but they also make it harder to detect after the fact. A successful attack leaves a link that looks like every other link in your identity store. Low likelihood and low detectability is a combination worth an audit even when it isn’t worth a weekend patch window.
Which deployments are exposed?
You’re in scope if your realm has identity brokering enabled with at least one external or social identity provider, and the first-broker-login flow can reach the link path.
That covers most B2C and B2B realms running Google, GitHub or Apple sign-in, and it covers brokered enterprise providers too. The upstream issue title names GitHub specifically, but the defect described in the advisory is in how first-broker-login binds its verification proof, not in any one provider’s connector.
You’re out of scope if brokering is off entirely, or if your providers are configured so first-broker-login never offers linking, which we get to below.
It’s worth separating this from ordinary social login setup problems. If you’re standing up Google or GitHub sign-in for the first time, our social login guide and the identity brokering walkthrough for GitHub cover the configuration. This post is about a specific defect in the link path, not a reason to rethink the setup.
What can I harden while there’s no patch?
Five things, in rough order of how much risk they remove per unit of effort. All of them are realm configuration rather than code.
1. Turn off identity providers you aren’t actually using. The most reliable mitigation for a brokering flaw is not brokering. Realms accumulate providers from experiments and pilots, and an enabled-but-unused social provider is attack surface with no upside. Audit the identity providers list and disable what nobody signs in with.
2. Review your first-broker-login flow’s link path. Look at whether linking is offered at all, and under what conditions. A realm that’s configured to create a new local user rather than offer a link to an existing one doesn’t traverse the vulnerable path in the same way. Whether that’s right for you depends on whether duplicate accounts are acceptable in your product, which is a product decision as much as a security one.
3. Require email verification before a link is established. If the flow demands proof of the local account’s mailbox before attaching an upstream identity to it, an attacker who intercepts the broker step still has to defeat a control that isn’t part of this defect.
4. Require MFA on accounts worth linking to. A second factor on the local account means a wrong link doesn’t immediately become access. This is the same reasoning that limits the damage of the password reset CVE, and it’s the highest-leverage control in both cases.
5. Monitor broker and link events. Keycloak emits IDENTITY_PROVIDER_FIRST_LOGIN, IDENTITY_PROVIDER_LINK_ACCOUNT and related events. Push them to your SIEM and alert on the patterns that shouldn’t happen: a link established on a privileged account, several links to one local user from different upstream identities, or a spike in first-broker-login volume. Since a successful attack leaves an ordinary-looking link, event history is most of what you’d have to investigate with.
If you want background on how brokered identities map onto local ones, the shadow accounts post on broker versus identity store covers the model, and attribute mapping during OIDC identity brokering covers what actually flows across on link.
How do I audit for links that are already wrong?
Start from the accounts where a wrong link would hurt most, not from the full user table.
For each admin, billing owner and support operator in the realm, list the federated identities attached to their local account and confirm each one belongs to that person. In a realm of any size you can’t do this for everyone, but the privileged set is usually small enough to check by hand and is exactly where an attacker would aim.
Two patterns are worth querying for across the wider user base. First, local accounts carrying more federated identities than your onboarding flow would ever produce. Second, links created in a window where you have other reasons for suspicion. Neither is proof on its own. A user who legitimately linked Google and GitHub looks the same as a bad link, which is the detection problem again.
Where you find something you can’t explain, unlinking the federated identity is low risk and reversible. The user re-links on next sign-in if it was legitimate.
What should self-hosted teams do when the patch lands?
Watch the upstream issue rather than the CVE feed, and expect a backport.
Issue #52321 is where the fix will be referenced when it merges, and it’ll name the release it ships in. Keycloak does patch older minor lines: the account takeover in CVE-2026-18963 went into 26.4.15, 26.6.6 and 26.7.2 on their respective lines rather than forcing everyone onto the newest minor. So when this fix appears, check the newest tag on your own line before assuming you need a minor-version jump.
In the meantime, the ordinary version hygiene still applies. If you’re behind on the 26.7.3 security set, that’s twenty CVEs with fixes already available, which is a better use of a patch window than waiting on this one.
What does managed Keycloak change here?
It changes who’s watching and how fast the patched build reaches you, and it doesn’t change your broker configuration.
On Skycloak, which is identity management as a service running real Keycloak, we track advisories and roll patched builds, so the gap between a fix merging upstream and it running in your cluster isn’t a window you have to staff. For a CVE with no fix yet, that’s the whole of the difference, and it’s worth being precise rather than overselling it: there’s no managed-platform setting that closes a defect upstream hasn’t closed.
The hardening list above stays yours either way. Which identity providers you enable, whether your first-broker-login flow offers linking, and whether you require email verification before a link is established are realm-level decisions that depend on how your product is supposed to behave, so they need a call from your team rather than a default from ours.
FAQ
Is there a fixed Keycloak version for CVE-2026-82968?
Not as of 11 September 2026. The GitHub advisory lists no patched version and the upstream tracking issue, keycloak/keycloak#52321, is open. Anyone telling you to upgrade to a specific release for this CVE is working from an assumption rather than a published fix.
Does this affect every identity provider or only GitHub?
The upstream issue names GitHub, but the advisory describes the defect in first-broker-login’s verification binding, which is shared code rather than a provider connector. Treat any enabled social or external provider as in scope until the fix names otherwise.
How likely is exploitation in practice?
Low, on the CVSS reading. Attack complexity is high and user interaction is required, so an attacker needs a victim actively moving through a linking flow. That lowers likelihood without lowering impact, which stays high for confidentiality and integrity.
Will disabling social login fix it?
It removes the exposure, since a realm that doesn’t broker doesn’t run first-broker-login. Whether that’s an acceptable trade depends on how much of your sign-in volume arrives through social providers. Disabling the providers nobody uses is the version of this advice with no downside.
Can I detect whether a wrong link already exists?
Not reliably from events alone, because a bad link produces the same records as a good one. The practical approach is auditing federated identities on privileged accounts by hand and querying for users carrying more links than your flow should create.
Does MFA on the local account help?
Yes, as a blast radius control rather than a fix. A wrong link still gets established, but it doesn’t grant access on its own, which turns an account takeover into an anomaly you can find and unlink.
Sources
- GitHub Advisory Database, advisory for CVE-2026-82968 (GHSA-2w6p-j7xq-6p7v), published 2 September 2026, retrieved 2026-09-11, https://github.com/advisories/GHSA-2w6p-j7xq-6p7v
- Keycloak, issue #52321, “[CVE-2026-82968] Persistent wrong-account linking through null / GitHub identity provider”, retrieved 2026-09-11, https://github.com/keycloak/keycloak/issues/52321
- GitHub Advisory Database, “Keycloak: Unauthenticated account takeover via reset-credentials flow bypass” (GHSA-4gv3-mc9p-5wqc), retrieved 2026-09-11, https://github.com/advisories/GHSA-4gv3-mc9p-5wqc