Bug 2430835 (CVE-2026-1190)

Summary:	CVE-2026-1190 org.keycloak/keycloak-services: Keycloak SAML brokering: Response delay due to unchecked NotOnOrAfter in SubjectConfirmationData
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	aschwart, asoldano, bbaranow, bmaxwell, boliveir, brian.stansberry, darran.lofthouse, dosoudil, fjuma, istudens, ivassile, iweiss, mosmerov, mposolda, msvehla, nwallace, pberan, pesilva, pjindal, pmackay, rmartinc, rstancel, smaestri, ssilvert, sthorger, tom.jenkinson, vmuzikar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in Keycloak's SAML brokering functionality. When Keycloak is configured as a client in a Security Assertion Markup Language (SAML) setup, it fails to validate the `NotOnOrAfter` timestamp within the `SubjectConfirmationData`. This allows an attacker to delay the expiration of SAML responses, potentially extending the time a response is considered valid and leading to unexpected session durations or resource consumption.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-01-19 13:42:25 UTC

When SAML is configured to act as a client (SAML brokering) it does not check the NotOnOrAfter tat is defined inside the SubjectConfirmationData. This just affects in the sense that an attacker can delay the response for more of the expected time. The response cannot be tampered because SAML should configured to be signed and, therefore, the same response cannot be used twice or to respond another request (the id should be modified and therefore the signature validation fails).

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="http://localhost:8080/realms/master/broker/saml/endpoint" ID="ID_9e3417cd-0c39-449b-bdaa-50876264d109" InResponseTo="ID_b99bc864-e89c-4243-adbb-56898a2143b7" IssueInstant="2026-01-12T17:17:13.922Z" Version="2.0">
    <saml:Issuer>http://localhost:8080/realms/saml</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="ID_479728b1-b612-46c4-8a3a-f0dbff4409af" IssueInstant="2026-01-12T17:17:13.919Z" Version="2.0">
        <saml:Issuer>http://localhost:8080/realms/saml</saml:Issuer>
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">samluser</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData InResponseTo="ID_b99bc864-e89c-4243-adbb-56898a2143b7" NotOnOrAfter="2026-01-12T17:22:11.919Z" Recipient="http://localhost:8080/realms/master/broker/saml/endpoint"/>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2026-01-12T17:17:11.919Z" NotOnOrAfter="2026-01-12T17:18:11.919Z">
            <saml:AudienceRestriction>
                <saml:Audience>http://localhost:8080/realms/master</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2026-01-12T17:17:13.922Z" SessionIndex="9RdZsk9oqv5JK9aWfX5d1saN::9ad854a5-b6fc-4402-9e2c-7b96411af415" SessionNotOnOrAfter="2026-01-13T03:17:13.922Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
        <saml:AttributeStatement>
            <saml:Attribute FriendlyName="email" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">samluser</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute FriendlyName="firstName" Name="firstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">samluser</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute FriendlyName="lastName" Name="lastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">samluser</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The NotOnOrAfter in the conditions are checked OK but the one in SubjectConfirmationData is not checked. The idea is that keycloak should also check the NotBefore and NotOnOrAfter in that element too just in case (maybe the IdP just use that data).