CVE-2026-105305

Executive Summary

CVE-2026-105305 is a flaw in the OpenID Connect (OIDC) implementation of Keycloak, specifically in the Device Authorization Grant flow — the OAuth 2.0 component that lets input-constrained devices (smart TVs, CLI tools, IoT appliances, kiosks) obtain security tokens. The flow fails to enforce the minimum authentication level (ACR) required by a client's configuration, so an attacker who has already stolen a user's password can complete the device flow without satisfying mandatory multi-factor authentication and reach the Keycloak Admin REST API.

The vulnerability is an authentication/authorization control bypass (CWE-287 — Improper Authentication), not a memory-safety or injection defect. It does not grant access without a valid password; its impact is the full defeat of the second authentication factor that the client configuration was supposed to enforce. Any Keycloak realm that relies on step-up or mandatory MFA to protect administrative access, and that permits the device flow, is in scope.

Technical Analysis

Keycloak is an open-source identity and access management server implementing OAuth 2.0, OpenID Connect, and SAML, and is widely deployed as the authentication and SSO backbone for enterprise applications and for its own Admin Console and Admin REST API. The Device Authorization Grant (RFC 8628) is designed for devices that cannot host a browser or accept rich input: the device requests a device code and a user code, the user authenticates on a separate browser-capable device, and the device polls the token endpoint until authorization completes.

The vulnerability class here is Improper Authentication (CWE-287). Per the NVD description, the device flow "fails to check the minimum authentication level required by a client configuration." In Keycloak terms, clients can be configured with an authentication flow and required authentication level (ACR/LOA). The device flow is required to honor this constraint so that a token is only issued after the configured level (for example, MFA) has been satisfied. CVE-2026-105305 is the case where that minimum-level check is omitted or not enforced within the device authorization grant code path. Consequently, a session that has satisfied only the password factor — Single Factor Authentication (SFA) — is treated as sufficient for token issuance, even though the client mandates a higher level.

Two properties of the flaw matter operationally:

• It is a check-enforcement failure, not a credential-theft technique. The attacker must already possess a valid username/password pair. The vulnerability converts a password compromise into full access, removing the MFA backstop.
• It is specifically scoped to the device authorization grant path. Other OIDC flows may correctly enforce the minimum authentication level; the reported defect is in this component and its failure to consult the client's configured minimum level.

The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4 Medium) is consistent with this reading: remotely exploitable over the network with low complexity, but requiring low privileges (the attacker is already an authenticated/credential-holding party), with no user interaction, no scope change, and limited confidentiality and integrity impact and no availability impact. The limited C/I subscores reflect that reaching the Admin REST API is highly sensitive on its own, but the direct measurable impact of a single exploitation is bounded and the flaw does not, by itself, achieve code execution or denial of service.

Note: the NVD description does not disclose the specific function, class, module, or configuration parameter names involved, and no affected version range has been published. No granular implementation detail is available beyond the description above; no PoC or exploit code is public as of this writing.

Exploitation Scenarios

Because no public PoC exists, the following chain is inferred from the vulnerability class (Improper Authentication / missing minimum-authentication-level enforcement) and the NVD description. It contains no invented function names, parameters, or endpoints — it stays at the level of the OIDC device flow and the Keycloak Admin REST API.

1. Reconnaissance / target identification. The attacker identifies a Keycloak deployment and determines which realm and clients expose the OIDC Device Authorization Grant. The device authorization endpoint is publicly reachable (authorization servers publish their endpoint metadata for OIDC discovery). The attacker also determines, through reconnaissance or prior knowledge, which client is configured to require a minimum authentication level (e.g., MFA) — typically the client backing administrative or high-value access.

2. Credential acquisition. The attacker already holds a valid username/password for the target user. This is the PR:L precondition. The acquisition vector is out of scope for this CVE (phishing, credential reuse, prior breach); the CVE only matters once valid credentials exist.

3. Triggering the flaw. The attacker initiates the device authorization grant flow against the vulnerable Keycloak realm using the stolen credentials: the device flow is started, the user code is submitted, and authentication is completed with the password factor alone. Because the flow fails to check the client's configured minimum authentication level, the token endpoint issues tokens even though only SFA has been satisfied. No second factor is prompted or verified, and no user interaction is required on the victim's part (UI:N) beyond the initial credential submission.

4. Post-exploitation impact. With a token for the affected client, the attacker reaches the Keycloak Admin REST API and performs administrative operations, subject to the privileges of the compromised account. The confidentiality and integrity impact is limited (C:L/I:L) but administrative access to an identity provider is a high leverage position, as described below. No availability impact is attributed by the vector.

It is important to state plainly: no public exploit exists for this CVE and none of the above should be treated as a working exploit string. It is an analysis of the attack surface the vulnerability class permits.

Impact Assessment

Primary affected component: Keycloak's OIDC Device Authorization Grant flow. Impacted assets are Keycloak realms that (a) enable or permit the device flow and (b) enforce multi-factor or higher authentication levels for the affected clients, particularly clients that gate the Admin REST API.

Business impact is driven entirely by what the compromised user can do. When the bypassed client is an administrative client, the attacker obtains Admin REST API access, enabling: reading and enumerating realm data, users, clients, and configuration; modifying clients, authentication flows, and policies; creating or altering users and credentials; and, at the most damaging end, weakening the identity provider's own security posture. For an identity provider that intermediates authentication for downstream applications, a compromised admin plane can translate into wide lateral reach across every application federated to that realm.

Blast radius within the CVE scope is necessarily a single compromised realm at a time, but the downstream fan-out across federated applications can be large. CVSS subscores: Confidentiality Low and Integrity Low with no Availability impact (C:L/I:L/A:N) constrain the per-incident measurable damage, and Scope is Unchanged (S:U). The vector's PR:L reflects that the attacker must already be a credential-holding principal, and AC:L reflects that a successful condition results from a normal, low-complexity flow rather than a fragile exploit chain. The overall score is 5.4 (Medium). No CISA KEV listing, no public PoC, and no exploit code are associated with this CVE.

Detection Guidance

The detection strategy for this class of flaw is to find OIDC device-flow authentications that succeed with only SFA for clients that are configured to require a higher authentication level, and to identify anomalous device-flow usage against administrative clients. Detection should correlate Keycloak authentication/audit events (device authorization started, device code exchanged, successful token issuance) with the authentication level satisfied, and compare it to the client's configured minimum level.

Sigma Rule

title: Keycloak Device Authorization Grant Bypasses Required Authentication Level
id: 8f5a2c41-6d3e-4b7a-9c1e-2d0f3a9b7c41
status: experimental
description: Detects successful OIDC Device Authorization Grant token issuance for a client that requires a higher authentication level (e.g. MFA) but where only single-factor authentication was satisfied. Corresponds to CVE-2026-105305 (CWE-287, Keycloak).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-105305
author: threat-intel
date: 2026/01/01
tags:
  - attack.t1078
  - attack.defense_evasion
  - cve.2026-105305
logsource:
  product: keycloak
  service: authentication
detection:
  selection_flow:
    event_type|contains:
      - 'DEVICE_CODE_TO_EXCHANGE'
      - 'device_authorization'
      - 'code_to_token'
  selection_success:
    outcome|contains:
      - 'success'
      - 'SUCCESS'
  selection_acr:
    acr|contains:
      - 'sfa'
      - 'level0'
      - 'urn:keycloak:acr:0'
  filter_mfa:
    acr|contains:
      - 'mfa'
      - 'urn:keycloak:acr:mfa'
  condition: selection_flow and selection_success and (selection_acr) and not filter_mfa
falsepositives:
  - Clients legitimately configured without a minimum authentication level
  - Flows that record authentication level under a nonstandard ACR value
level: high

YARA Rule

rule CVE_2026_105305_Keycloak_DeviceAuth_MFA_Bypass
{
    meta:
        description = "Detects Keycloak log/audit strings indicating a device authorization grant token exchange that completed without satisfying a required authentication level (CVE-2026-105305)"
        author = "threat-intel"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-105305"
        cve = "CVE-2026-105305"
        date = "2026-01-01"

    strings:
        $device1 = "device_code" ascii nocase
        $device2 = "device_authorization" ascii nocase
        $token1  = "code_to_token" ascii nocase
        $acr1    = "urn:keycloak:acr" ascii nocase
        $acr2    = "acr_values" ascii nocase
        $sfa1    = "sfa" ascii nocase
        $mfa1    = "mfa" ascii nocase
        $cred1   = "grant_type" ascii nocase
        $cred2   = "urn:ietf:params:oauth:grant-type:device_code" ascii nocase

    condition:
        (uint16(0) == 0x7b7b or uint16(0) == 0x7b0a or uint16(0) == 0x7b0d or filesize > 0) and
        ($device1 or $device2 or $cred2) and
        ($token1 or $cred1) and
        ($acr1 or $acr2) and
        $sfa1 and not $mfa1
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-105305 Keycloak OIDC Device Authorization Grant token exchange without required authentication level"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"token"; http.content_type; content:"application/x-www-form-urlencoded"; http.request_body; content:"grant_type=urn:ietf:params:oauth:grant-type:device_code"; http.request_body; content:"device_code="; http.request_body; pcre:"/(?i)acr_values=(?!.*mfa)/"; reference:cve,2026-105305; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-105305; classtype:attempted-user; sid:2026105305; rev:1;)

Elastic Detection

// Keycloak device-flow token issuance where required auth level was not enforced
sequence by user.name with maxspan=5m
  [ authentication where event.action == "device_authorization" ]
  [ authentication where event.action in ("code_to_token","token_exchange")
      and event.outcome == "success"
      and user.authentication.factor in ("1","single_factor","sfa")
      and not user.authentication.factor in ("2","multi_factor","mfa") ]

Splunk SPL Query

index=keycloak_sourcetype (event_type="DEVICE_CODE_TO_EXCHANGE" OR event_type="code_to_token" OR action="device_authorization")
| where match(lower(outcome), "success")
| eval auth_level=coalesce(acr, authentication_level, mfa_used)
| where (isnull(auth_level) OR match(lower(auth_level),"sfa|single|level0|0"))
| stats count min(_time) as first_seen max(_time) as last_seen values(client_id) as clients values(username) as users by src_ip
| where count > 0
| convert ctime(first_seen) ctime(last_seen)
| table first_seen last_seen src_ip users clients count

Wazuh OSSEC Rule

<group name="keycloak,oidc,cve-2026-105305,">
  <rule id="100105" level="12">
    <decoded_as>json</decoded_as>
    <field name="event_type">\.+</field>
    <regex type="pcre2">(?i)device_code|device_authorization|code_to_token</regex>
    <regex type="pcre2">(?i)"outcome"\s*:\s*"success"</regex>
    <regex type="pcre2">(?i)"acr"\s*:\s*"(sfa|single|level0|urn:keycloak:acr:0)"</regex>
    <description>Keycloak device authorization grant token issued with single-factor authentication only - possible CVE-2026-105305 MFA bypass</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>authentication_bypass,</group>
  </rule>

  <rule id="100106" level="10">
    <decoded_as>json</decoded_as>
    <field name="event_type">\.+</field>
    <regex type="pcre2">(?i)device_code|code_to_token</regex>
    <regex type="pcre2">(?i)admin|admin-cli|admin-rest</regex>
    <description>Keycloak device flow interaction involving an administrative client - investigate for CVE-2026-105305</description>
    <group>authentication_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected-version range has been published in the data available for this CVE. Treat all guidance below as compensating controls rather than a remediation.

1. Immediate mitigations

• Disable the OIDC Device Authorization Grant flow for clients that are not strictly required to use it, and absolutely for any client that can reach the Keycloak Admin REST API. Removing the exposed flow removes the vulnerable code path.
• Enforce a strong Conditional Access / authentication-flow policy at the realm level so that high-value clients cannot be satisfied by single-factor authentication through any flow. Audit authentication flows for any path that permits SFA for administrative clients.
• Treat administrative credentials as compromised-prone and enforce phishing-resistant MFA independently of the client-level ACR configuration, so that a single missing enforcement check does not equal loss of the admin plane.
• Monitor and alert (see Detection Guidance) on device-flow token issuance that completes with SFA for clients configured to require MFA.
• Restrict network reachability of the Keycloak admin endpoints (Admin Console and Admin REST API) to trusted management networks/VPNs, and apply rate limiting and alerting to device authorization and token endpoints.

2. Patch/upgrade steps

• No patch is currently identified from tracked sources. Monitor the Keycloak project's security advisories and release notes for an official fix and an affected-version statement before upgrading.
• Until an advisory is issued, pin to a known-good Keycloak release and do not assume any currently deployed version is correct; re-evaluate immediately when the vendor publishes the affected range.
• Maintain a rollback-capable upgrade process so that a fix can be applied quickly once released, and re-test the device flow's ACR enforcement as part of that change.

3. Long-term hardening

• Do not rely on the OIDC device flow for administrative or otherwise privileged access; centralize privileged authentication on flows that enforce step-up and phishing-resistant factors.
• Adopt continuous validation of authentication-level (ACR) enforcement across all OIDC flows for high-value clients, and include SFA-through-device-flow as a standing detection use case.
• Reduce the standing privilege of identities that can reach the Admin REST API and apply least-privilege role mapping, so a single token issuance cannot expose the full administrative surface.
• Where feasible, enforce MFA at the identity-external layer (reverse proxy / IdP federation) in addition to Keycloak's per-client configuration, providing defense in depth against missing enforcement checks.

References

• NVD — CVE-2026-105305: https://nvd.nist.gov/vuln/detail/CVE-2026-105305
• CWE-287 — Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• RFC 8628 — OAuth 2.0 Device Authorization Grant: https://www.rfc-editor.org/rfc/rfc8628
• Keycloak project security advisories and release notes: https://www.keycloak.org/ (monitor for the CVE-specific advisory; none published in the data available for this report)
• CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-105305 is NOT listed as of this writing)

Threat activity note: no public PoC, exploit code, or Nuclei template exists for this CVE, and there is no known exploit-in-the-wild or named threat-actor campaign associated with it in the available data. CISA KEV status is NO. Exploitation cannot be confirmed to be occurring; detection and mitigation above are preventive and hunt-oriented.