CTIPilot

Red Hat Build of Keycloak

product · product:red-hat-build-of-keycloak single-source

Coverage timeline
2
first 2026-08-07 → last 2026-08-19
Peak priority
high
2 high
Sources cited
9
3 hosts
Sections touched
1
trending-vulnerabilities
Co-occurring entities
8
see Co-occurring entities below
ATT&CK techniques
7
pinned v19.2 · see below

ATT&CK techniques

7 techniques observed across 2 entries, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)

Initial Access TA0001

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

T1190Exploit Public-Facing Application×2

Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.

Evidence: 2026-08-19/cve-2026-18963-keycloak-reset-credentials-account-takeover · 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

Persistence TA0003

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

T1098Account Manipulation×1

Adversaries may manipulate accounts to maintain and/or elevate access to victim systems. Account manipulation may consist of any action that preserves or modifies adversary access to a compromised account, such as modifying credentials or permission groups. These actions could also include account activity designed to subvert security policies, such as performing iterative password updates to bypass password duration policies and preserve the life of compromised credentials.

Evidence: 2026-08-19/cve-2026-18963-keycloak-reset-credentials-account-takeover · ATT&CK page ↗

T1556Modify Authentication Process×1

Adversaries may modify authentication mechanisms and processes to access user credentials or enable otherwise unwarranted access to accounts. The authentication process is handled by mechanisms, such as the Local Security Authentication Server (LSASS) process and the Security Accounts Manager (SAM) on Windows, pluggable authentication modules (PAM) on Unix-based systems, and authorization plugins on MacOS systems, responsible for gathering, storing, and validating credentials. By modifying an authentication process, an adversary may be able to authenticate to a service or system without using Valid Accounts.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

Privilege Escalation TA0004

T1068Exploitation for Privilege Escalation×1

Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

T1098Account Manipulation×1

Adversaries may manipulate accounts to maintain and/or elevate access to victim systems. Account manipulation may consist of any action that preserves or modifies adversary access to a compromised account, such as modifying credentials or permission groups. These actions could also include account activity designed to subvert security policies, such as performing iterative password updates to bypass password duration policies and preserve the life of compromised credentials.

Evidence: 2026-08-19/cve-2026-18963-keycloak-reset-credentials-account-takeover · ATT&CK page ↗

Stealth TA0005

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

Defense Impairment TA0112

T1556Modify Authentication Process×1

Adversaries may modify authentication mechanisms and processes to access user credentials or enable otherwise unwarranted access to accounts. The authentication process is handled by mechanisms, such as the Local Security Authentication Server (LSASS) process and the Security Accounts Manager (SAM) on Windows, pluggable authentication modules (PAM) on Unix-based systems, and authorization plugins on MacOS systems, responsible for gathering, storing, and validating credentials. By modifying an authentication process, an adversary may be able to authenticate to a service or system without using Valid Accounts.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

Credential Access TA0006

T1556Modify Authentication Process×1

Adversaries may modify authentication mechanisms and processes to access user credentials or enable otherwise unwarranted access to accounts. The authentication process is handled by mechanisms, such as the Local Security Authentication Server (LSASS) process and the Security Accounts Manager (SAM) on Windows, pluggable authentication modules (PAM) on Unix-based systems, and authorization plugins on MacOS systems, responsible for gathering, storing, and validating credentials. By modifying an authentication process, an adversary may be able to authenticate to a service or system without using Valid Accounts.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

T1606.002Forge Web Credentials: SAML Tokens×1

An adversary may forge SAML tokens with any permissions claims and lifetimes if they possess a valid SAML token-signing certificate. The default lifetime of a SAML token is one hour, but the validity period can be specified in the <code>NotOnOrAfter</code> value of the <code>conditions ...</code> element in a token. This value can be changed using the <code>AccessTokenLifetime</code> in a <code>LifetimeTokenPolicy</code>. Forged SAML tokens enable adversaries to authenticate across services that use SAML 2.0 as an SSO (single sign-on) mechanism.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

Impact TA0040

T1499.004Endpoint Denial of Service: Application or System Exploitation×1

Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users. Some systems may automatically restart critical applications and services when crashes occur, but they can likely be re-exploited to cause a persistent denial of service (DoS) condition.

Evidence: 2026-08-07/keycloak-saml-broker-signature-bypass-cve-2026-16443 · ATT&CK page ↗

Story timeline

  1. 2026-08-19CVE-2026-18963; Keycloak's password-reset flow can be driven to completion without the verification email being clicked, handing an unauthenticated attacker any account including administrators (CVSS 9.1)
    trending-vulnerabilitiesAn identity provider's account-recovery path is the account-takeover path, and one affected Red Hat product has no fix at all
  2. 2026-08-07CVE-2026-16443, Keycloak: importing SAML metadata without key-usage attributes silently disables response signature validation, so an unauthenticated attacker forges a login as any known user
    trending-vulnerabilitiesKeycloak's identity broker stopped checking SAML signatures on a metadata-import edge case, one of seven CVEs fixed in 26.4.14 / 26.6.5 / 26.7.1

Where this entity is cited

  • trending-vulnerabilities2

Source distribution

  • access.redhat.com7 (78%)
  • cert.ssi.gouv.fr1 (11%)
  • euvd.enisa.europa.eu1 (11%)

Co-occurring entities

Derived: referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

Entries about Red Hat Build of Keycloak (2)

2026-08-19 · view entry permalink →

HIGHCVE-2026-18963updatedNATOA2

CVE-2026-18963; Keycloak's password-reset flow can be driven to completion without the verification email being clicked, handing an unauthenticated attacker any account including administrators (CVSS 9.1)

Red Hat published CVE-2026-18963 on 2026-08-18 against the reset-credentials flow in keycloak-services, the component it describes as the core engine for identity and access management in its Keycloak build. The flaw "allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link" (Red Hat Product Security, 2026-08-18), after which the attacker sets new credentials directly and holds the account. Red Hat's own assessment rates it Critical, exploitable by a remote unauthenticated attacker with no user interaction, and names the cause: "The vulnerability's root cause is improper state validation within the reset-credentials authentication flow" (Red Hat Product Security, 2026-08-18). ENISA's database carries the record with the same CVSS 9.1 and the same vector (ENISA EUVD, 2026-08-18).

What makes this worse than its score is where it sits. Keycloak is not an application; it is the thing applications delegate authentication to, so an account taken over here is taken over everywhere that realm fronts. The email-verification click is the entire control standing between an anonymous request and a credential change, and the flaw is that the flow's state is not validated well enough to require it. That also means the usual compensating controls sit on the wrong side of the problem: multi-factor policies and password strength rules govern authentication, while this path rewrites the credential before authentication happens, and an administrator account reachable through the same realm's recovery flow is exposed on exactly the same terms as an ordinary user.

The remediation detail matters more than usual, and in three separate ways. First, there are two supported streams, not one: Red Hat's errata fix the keycloak-services package in Red Hat build of Keycloak 26.4.15 (RHSA-2026:56520) and 26.6.6 (RHSA-2026:56523), with the RHEL 9 and OpenShift container images and the operator bundles carried in separate errata for each stream, RHSA-2026:56519 for 26.4 and RHSA-2026:56524 for 26.6, all released on 2026-08-18 (Red Hat Product Security, 2026-08-18). A containerised or operator-managed deployment that updates only the package and keeps its existing image is not fixed.

Second, and absent from the headline advisory view, one affected product has no fix at all. Red Hat's structured product state records the same keycloak-services component as Affected in the Red Hat JBoss Enterprise Application Platform Expansion Pack with no erratum attached, while Red Hat Single Sign-On 7 is recorded Not affected (Red Hat Product Security, 2026-08-18). An estate running the Expansion Pack therefore carries an unauthenticated account-takeover path with no vendor update available, which is a different operational position from "upgrade to 26.4.15 or 26.6.6" and needs the compensating control below rather than a patch ticket.

Third, the two streams are not equivalent upgrades. The 26.4.15 erratum closes this flaw alone; the 26.6.6 erratum closes five, and two of the other four sit on the same identity surface, a predictable account-linking hash that enables account takeover via a malicious OIDC client (CVE-2026-15571), and vault-resolved rotated client secrets leaked through the Admin REST API (CVE-2026-17048), alongside a hidden-group-metadata disclosure through the fine-grained-admin role-groups endpoint (CVE-2026-14613) and a time-of-check-to-time-of-use privilege escalation (CVE-2026-9796) (Red Hat, RHSA-2026:56523, 2026-08-18). For a 26.6 operator the upgrade is therefore a five-flaw identity-surface fix, two of which are themselves account-takeover or credential-disclosure paths; for a 26.4 operator it is one. Red Hat's advisory speaks for Red Hat's builds; it establishes nothing either way about the upstream community distribution, and no source read as of 2026-08-24 does, so operators on the community build have no vendor statement to act on rather than a confirmed exposure or a confirmed exemption.

No exploitation is reported, there is no public proof-of-concept, and Red Hat publishes no exploitation detail. The flaw nonetheless demands attention ahead of the normal cycle on its own mechanics: an anonymous, single-flow path to administrative control of an internet-facing identity provider is trivially rediscoverable once the fix diff is compared, and the fix is public as of 2026-08-18.

Detection concentrates on the credential-reset trail, which is the one place the attack must leave a record. In identity-provider audit telemetry, the durable signals are UPDATE_PASSWORD and reset-credentials events for an account with no preceding verification-email event in the same flow, credential resets for accounts that never requested one, resets for administrator or service accounts in realms where those accounts are not managed through self-service recovery at all, and a burst of reset-flow initiations from a single source against many usernames. In web-tier telemetry the reachable surface is the realm's login-actions/reset-credentials path. Triage: genuine forgotten-password traffic produces the same endpoints and the same event types all day, so volume is not the signal; the discriminators are the missing verification step inside a completed flow, the target being an account class that has no business using self-service recovery, and a successful authentication from a new source immediately following the reset. Session revocation is worth pairing with the upgrade: a credential rotated after a takeover does not by itself invalidate a session the attacker already holds.

The issue allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link.

The vulnerability's root cause is improper state validation within the reset-credentials authentication flow.

Red Hat Product Security 2026-08-18

disabling the "Forgot password" functionality across all realms can be used as a temporary mitigation

Red Hat Product Security (structured security data) 2026-08-18
Correctionrun 2026-08-23T1311Z-auditactionscvesevidencesourcesbody

The earlier entry read Red Hat's product-state table for CVE-2026-18963 as recording the Red Hat JBoss Enterprise Application Platform Expansion Pack as Affected with no erratum, and built a paragraph, a summary sentence and an action item on the conclusion that part of the affected estate had no patch available. That reading was wrong. Red Hat's structured security data records exactly two products under package_state, and both are "fix_state" : "Not affected", the Expansion Pack's keycloak-services package, and Red Hat Single Sign-On 7 (Red Hat Product Security, 2026-08-18). Every other product Red Hat lists for this flaw appears under the shipped errata instead. The customer-portal page for the CVE embeds the same product-state data, "state":"Not affected", with the justifications "Component not Present" for the Expansion Pack and "Vulnerable Code not Present" for Red Hat Single Sign-On 7 (Red Hat Product Security, 2026-08-18). No Red Hat product is recorded as affected by CVE-2026-18963 and left without a fix.

The practical consequence is narrower than the original entry implied and points the other way. An operator running the Expansion Pack has nothing to remediate for this CVE, rather than an unpatchable unauthenticated account-takeover path, so a risk item raised on the strength of the earlier entry can be closed, and any compensating control applied to that product line specifically can be withdrawn. Nothing else about the flaw changes: the reset-credentials weakness in Red Hat build of Keycloak, its Critical rating, its CVSS 9.1 and the two fixed streams all stand exactly as previously reported, and an unpatched 26.4 or 26.6 deployment remains the priority.

The same record also carries an official interim step the earlier entry did not have. Red Hat states that where an immediate upgrade is not possible, "disabling the \"Forgot password\" functionality across all realms can be used as a temporary mitigation", reached in the administration console under Realm settings, Login, Forgot password, Off, and applied to every realm (Red Hat Product Security, 2026-08-18). This supersedes the reverse-proxy suggestion carried previously: turning the flow off in the product removes the vulnerable path for every client of that realm, where a proxy rule only covers traffic that traverses the proxy.

The reading error is worth naming because the shape recurs. Red Hat's package_state block enumerates the products Red Hat has assessed, not the products that are vulnerable; each row carries its own fix_state, and membership in the list says only that the product was evaluated. The same holds for the CSAF product_status groups other vendors publish and for the per-product build lists in Microsoft's Security Update Guide. Triage: a product named on a vendor advisory page is not thereby in scope; the verdict field beside it is the claim, and a product absent from the errata list may simply have been ruled out rather than left unpatched.

vulnerability19 Aug 04:52Zsingle-sourceOpen finding ↗

2026-08-07 · view entry permalink →

CVE-2026-16443, Keycloak: importing SAML metadata without key-usage attributes silently disables response signature validation, so an unauthenticated attacker forges a login as any known user

Keycloak's SAML identity-brokering path stopped enforcing the one guarantee that makes federated login trustworthy. In CVE-2026-16443, when Keycloak imports an upstream identity provider's SAML metadata that lacks specific usage attributes for its keys, it disables signature validation for SAML responses even though a signing certificate was supplied, and Red Hat's own record states the consequence plainly: "This issue allows an unauthenticated attacker to forge a SAML response and gain unauthorized access to a user account by knowing their external identifier" (Red Hat Product Security, 2026-08-05). The external identifier is not a secret (it is typically a username or email address as the upstream IdP renders it) so the practical precondition is knowing who you want to be. Red Hat rates the flaw Important at CVSS 7.4, with the score held down by attack complexity rather than by any authentication requirement (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).

A sibling flaw in the same broker, CVE-2026-16442 (also CVSS 7.4), lets the IdP-initiated single-sign-on endpoint skip the check for whether a provider is restricted to account linking only, so an attacker controlling a linked upstream identity bypasses that restriction and reaches full access to the local account (Red Hat Product Security, 2026-08-05). The two Dynamic Client Registration flaws are the privilege-escalation half of the batch: CVE-2026-15572 (CVSS 8.8) exploits the "Allowed Protocol Mapper Types" policy failing to re-validate a mapper's type on client update when its configuration is unchanged, so an attacker registers a permitted mapper and then swaps it for a restricted one that hardcodes administrative roles (Red Hat Product Security, 2026-08-05); CVE-2026-16102 (CVSS 8.1) abuses the default DCR policy's mis-validated claim path for User Property mappers to write into sensitive internal claim locations and forge administrative roles into the attacker's own access token, which Red Hat says "allows the attacker to take over other clients, steal confidential secrets, and potentially gain full administrative control over the realm" (Red Hat Product Security, 2026-08-05). The remaining three are CVE-2026-15573 (CVSS 8.1), where PathMatcher compares request paths to authorization policies without normalising the URI, so a trailing slash or a matrix parameter selects a weaker policy; CVE-2026-16071 (CVSS 5.4), where a delegated administrator's LDAP entry-DN search escapes the configured users-DN boundary and imports directory entries from outside it; and CVE-2026-16100 (CVSS 6.5), where raw error text from failed account operations becomes an unbounded Prometheus metric label and exhausts memory.

CERT-FR carried the batch to European constituents on 2026-08-06, a day after disclosure, and records the affected range as Keycloak before 26.4.14, 26.6.x before 26.6.5, and 26.7.x before 26.7.1 (CERT-FR, 2026-08-06). No party reports exploitation or public exploit code. The reason this batch matters more than its scores suggest is placement: Keycloak is the identity broker in front of a large share of European public-sector federated-login and e-government portal estates, so a forged assertion is not one application's problem but every application behind that realm. Detection concepts, telemetry class first: in identity-provider audit records, a forged SAML response has no counterpart in the upstream IdP's own authentication log, so correlating broker-login successes against the upstream provider's sign-in events for the same principal and interval surfaces assertions nobody upstream issued; and because Dynamic Client Registration happens over the registration API rather than the admin console, mapper or claim-path changes on DCR-managed clients that carry no matching administrative session are the signal for the privilege-escalation pair. Triage: routine Keycloak upgrades and scheduled IdP metadata refreshes both touch these same code paths, so the discriminator is not the configuration change itself but its provenance, a broker-login success with no upstream authentication behind it, or a protocol-mapper type that changed on a client no administrator touched.

This issue allows an unauthenticated attacker to forge a SAML response and gain unauthorized access to a user account by knowing their external identifier.

Red Hat Product Security 2026-08-05

Keycloak versions 26.6.x antérieures à 26.6.5

CERT-FR (ANSSI) 2026-08-06
vulnerability07 Aug 04:41Zmulti-sourceOpen finding ↗