Keycloak : contournement SAML corrigé en 26.8.2 (CVE-2026-117691)

En bref

• Une faille de la liaison SAML de Keycloak permet à un attaquant de se connecter comme tout fédéré. Il envoie un message non signé à côté d'un message signé. Red Hat a publié CVE-2026-117691 le 5 novembre 2026.
• Les royaumes fédérant un fournisseur SAML externe sont exposés si la validation de signature est active et que les assertions signées ne sont pas exigées. Red Hat Build of Keycloak est concerné ; Red Hat Single Sign-On 7 ne l'est pas.
• Red Hat attribue un score CVSS v3.1 de 9,1 et un impact Important à la faille. Aucun exploit public ni entrée KEV (Known Exploited Vulnerabilities) de la CISA (autorité américaine de cybersécurité) n'existait au 5 novembre 2026.
• Mettez à niveau vers Keycloak 26.8.2, publié le 5 novembre 2026. Red Hat n'avait publié aucun errata au moment de la vérification ; voir « Comment corriger ? » pour les solutions de contournement et leurs limites.

Suis-je concerné ?

Vous êtes concerné si votre royaume fédère un fournisseur d'identité SAML externe via la liaison HTTP-Redirect et exécute une version de Keycloak qui contient la vérification vulnérable.

• Le royaume dispose d'un fournisseur d'identité SAML configuré pour le courtage d'identités, et ce fournisseur renvoie ses réponses via la liaison HTTP-Redirect.
• La validation de signature est active pour ce fournisseur d'identité. Keycloak l'active lorsqu'il importe le certificat de signature du fournisseur depuis les métadonnées, et le contournement n'a d'effet que lorsque Keycloak vérifie réellement une signature.
• Le fournisseur d'identité n'exige pas d'assertions signées. Avec « Want Assertions Signed » activé, Keycloak rejette l'assertion fabriquée non signée.
• La version de Keycloak est concernée selon le tableau des versions.

Red Hat classe Red Hat Single Sign-On 7 comme non concerné, car le code vulnérable n'est pas présent. Red Hat Build of Keycloak est concerné, et Red Hat n'avait publié aucun errata au moment de la vérification, le 5 novembre 2026. La branche main (nightly) de keycloak/keycloak contenait encore l'ancienne vérification à cette date ; 26.8.2 est la version corrigée.

Red Hat, en tant qu'autorité de numérotation des CVE, attribue à la faille un score CVSS v3.1 de 9,1. Le vecteur est CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.

La sévérité de base est Critique, tandis que le niveau d'impact propre aux produits Red Hat est Important. NVD n'avait pas analysé l'enregistrement au moment de la vérification, le 5 novembre 2026.

Keycloak maintient trois branches de maintenance. Une branche dispose d'un correctif publié, et les deux autres ont des correctifs étiquetés pour 26.6.8 et 26.4.17, mais non publiés le 5 novembre 2026.

Vérifiez ce qui s'exécute, sur l'hôte et dans chaque conteneur :

/opt/keycloak/bin/kc.sh --version
docker ps --format '{{.Image}}' | grep -i keycloak
docker exec <container-name> /opt/keycloak/bin/kc.sh --version
kubectl get deploy -A -o jsonpath='{..image}' | tr ' ' '\n' | grep -i keycloak

Red Hat Build of Keycloak utilise le même binaire kc.sh dans son image, donc la vérification docker exec s'applique aussi à registry.redhat.io/rhbk/keycloak-rhel9.

Comment corriger ?

Mettez à niveau vers Keycloak 26.8.2, la première version upstream contenant le correctif, ou vers le rétroportage de votre branche dès sa publication. Pour un déploiement conteneurisé, récupérez d'abord l'image corrigée :

docker pull quay.io/keycloak/keycloak:26.8.2

1. Recréez le conteneur. Un conteneur en cours d'exécution conserve l'ancienne image jusqu'à sa recréation.
2. Pour une installation ZIP, téléchargez keycloak-26.8.2.zip depuis la page de publication. Sauvegardez la configuration et la base de données, puis remplacez l'installation.
3. Pour Red Hat Build of Keycloak, Red Hat n'avait publié aucun errata le 5 novembre 2026. Suivez l'avis Red Hat et mettez à jour rhbk/keycloak-rhel9 lorsqu'une version corrigée paraît.
4. Red Hat Single Sign-On 7 ne nécessite aucune action pour cette CVE.

Red Hat n'indique aucune mesure d'atténuation qui satisfasse ses critères de sécurité produit. Si vous ne pouvez pas mettre à niveau, deux options réduisent l'exposition. Aucune n'est un correctif pris en charge.

• Exiger des assertions signées : activez « Want Assertions Signed » pour le fournisseur d'identité lorsque celui-ci signe les assertions. Keycloak rejette alors l'assertion fabriquée non signée. Cela couvre CVE-2026-117691 pour ce fournisseur, mais modifie le contrat de confiance et ne sert à rien si le fournisseur ne signe pas les assertions.
• Rejeter les paramètres ambigus en périphérie. Sur le proxy inverse devant Keycloak, rejetez les requêtes vers le point de terminaison du courtier qui contiennent un nom de paramètre encodé en pourcentage. Rejetez aussi une requête qui répète l'un des paramètres signés :
  • SAMLResponse
  • SAMLRequest
  • RelayState
  • SigAlg
  • Signature

Cette règle reprend le correctif, mais le proxy doit décoder les noms avant de les comparer et elle peut casser des clients qui utilisent des encodages inhabituels. Testez-la d'abord en mode journalisation seule.

Quelle est la cause racine ?

Le bug est une divergence entre le nom de paramètre que Keycloak utilise pour traiter un message SAML et celui qu'il utilise pour vérifier la signature de ce message.

Le courtier SAML de Keycloak accepte une réponse d'authentification d'un fournisseur d'identité externe via la liaison HTTP-Redirect. Dans cette liaison, tout le message SAML circule dans un paramètre de requête, et le fournisseur d'identité signe la chaîne de requête plutôt que le document XML.

Le point d'entrée du courtier est SAMLEndpoint.redirectBinding. Il déclare samlResponse comme un @QueryParam JAX-RS, donc le framework décode les noms de paramètres avant de les comparer. Lorsqu'une requête contient à la fois %53AMLResponse et SAMLResponse, les deux se décodent en SAMLResponse, et la méthode reçoit la première valeur dans l'ordre de la requête.

// services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java, 26.8.1, lines 182-194
@GET
public Response redirectBinding(@QueryParam(GeneralConstants.SAML_REQUEST_KEY) String samlRequest,
                                @QueryParam(GeneralConstants.SAML_RESPONSE_KEY) String samlResponse,
                                @QueryParam(GeneralConstants.SAML_ARTIFACT_KEY) String samlArt,
                                @QueryParam(GeneralConstants.RELAY_STATE) String relayState)  {
    if (Objects.isNull(samlArt)) {
        return new RedirectBinding().execute(samlRequest, samlResponse, null, relayState, null);
    }
    return new ArtifactBinding().execute(samlRequest, samlResponse, samlArt, relayState, null);
}

Le vérificateur lit la requête via une autre API. KeycloakUriInfo.getQueryParameters(false) est censé renvoyer la requête brute. Dans 26.8.1, il appelle parseQueryParameters(rawQuery, false), et ce false désactive le décodage des noms comme des valeurs.

// server-spi/src/main/java/org/keycloak/models/KeycloakUriInfo.java, 26.8.1, lines 147-165
public MultivaluedMap<String, String> getQueryParameters(boolean decode) {
    if (decode) {
        return delegate.getQueryParameters(decode);
    }

    MultivaluedMap<String, String> result = new MultivaluedHashMap<>();
    String rawQuery = delegate.getRequestUri().getRawQuery();

    if (rawQuery == null) {
        return result;
    }

    for (Map.Entry<String, List<String>> entry : parseQueryParameters(rawQuery, false).entrySet()) {
        result.put(entry.getKey(), entry.getValue());
    }

    return result;
}

parseQueryParameters découpe la chaîne brute sur & et ne décode un nom que lorsque son argument decode vaut true. Avec false, %53AMLResponse reste %53AMLResponse.

// common/src/main/java/org/keycloak/common/util/UriUtils.java, 26.8.1, lines 61-90
String[] nv = param.split("=", 2);
try {
    String name = decode ? URLDecoder.decode(nv[0], "UTF-8") : nv[0];
    String val = nv.length > 1 ? nv[1] : "";
    map.add(name, decode ? URLDecoder.decode(val, "UTF-8") : val);
}

SamlProtocolUtils.verifyRedirectSignature recherche paramKey, qui vaut SAMLResponse, dans cette table brute. La copie encodée en pourcentage est invisible sous cette clé, donc getFirst renvoie le message littéral signé. La méthode reconstruit la chaîne signée à partir de cette valeur, de RelayState et de SigAlg, puis vérifie la signature du fournisseur d'identité sur cette chaîne.

// services/src/main/java/org/keycloak/protocol/saml/SamlProtocolUtils.java, 26.8.1, lines 216-251
public static void verifyRedirectSignature(SAMLDocumentHolder documentHolder, KeyLocator locator, UriInfo uriInformation, String paramKey) throws VerificationException {
    MultivaluedMap<String, String> encodedParams = uriInformation.getQueryParameters(false);
    verifyRedirectSignature(documentHolder, locator, encodedParams, paramKey);
}

public static void verifyRedirectSignature(SAMLDocumentHolder documentHolder, KeyLocator locator, MultivaluedMap<String, String> encodedParams, String paramKey) throws VerificationException {
    String request = encodedParams.getFirst(paramKey);
    String algorithm = encodedParams.getFirst(GeneralConstants.SAML_SIG_ALG_REQUEST_KEY);
    String signature = encodedParams.getFirst(GeneralConstants.SAML_SIGNATURE_REQUEST_KEY);
    String relayState = encodedParams.getFirst(GeneralConstants.RELAY_STATE);

    if (request == null) throw new VerificationException("SAM was null");
    if (algorithm == null) throw new VerificationException("SigAlg was null");
    if (signature == null) throw new VerificationException("Signature was null");

    String keyId = getMessageSigningKeyId(documentHolder.getSamlObject());

    StringBuilder rawQueryBuilder = new StringBuilder().append(paramKey).append("=").append(request);
    if (encodedParams.containsKey(GeneralConstants.RELAY_STATE)) {
        rawQueryBuilder.append("&" + GeneralConstants.RELAY_STATE + "=").append(relayState);
    }
    rawQueryBuilder.append("&" + GeneralConstants.SAML_SIG_ALG_REQUEST_KEY + "=").append(algorithm);
    String rawQuery = rawQueryBuilder.toString();

    try {
        byte[] decodedSignature = RedirectBindingUtil.urlBase64Decode(signature);
        String decodedAlgorithm = RedirectBindingUtil.urlDecode(encodedParams.getFirst(GeneralConstants.SAML_SIG_ALG_REQUEST_KEY));
        SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.getFromXmlMethod(decodedAlgorithm);
        if (!RedirectBindingSignatureUtil.validateRedirectBindingSignature(signatureAlgorithm,
                rawQuery.getBytes(StandardCharsets.UTF_8), decodedSignature, locator, keyId)) {
            throw new VerificationException("Invalid query param signature");
        }
    } catch (Exception e) {
        throw new VerificationException(e);
    }
}

La signature est valide, mais elle couvre un message que le serveur ne traitera pas. redirectBinding a déjà transmis la première valeur fabriquée à execute, et handleLoginResponse considère ensuite le message comme entièrement signé parce que SigAlg et Signature sont présents. L'assertion fabriquée elle-même n'est jamais signée.

// services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java, 26.8.1, lines 614-620
boolean signed = AssertionUtil.isSignedElement(assertionElement);
final boolean assertionSignatureNotExistsWhenRequired = config.isWantAssertionsSigned() && !signed;
final boolean signatureNotValid = signed && config.isValidateSignature() && !AssertionUtil.isSignatureValid(assertionElement, getIDPKeyLocator());
final boolean hasNoSignatureWhenRequired = !signed && config.isValidateSignature() && !isMessageFullySigned(holder);

Pour la liaison redirect, isMessageFullySigned renvoie containsUnencryptedSignature, qui vérifie seulement la présence de SigAlg et de Signature dans la requête.

// services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java, 26.8.1, lines 898-916
@Override
protected boolean isMessageFullySigned(SAMLDocumentHolder documentHolder) {
    return containsUnencryptedSignature(documentHolder);
}

@Override
protected boolean containsUnencryptedSignature(SAMLDocumentHolder documentHolder) {
    MultivaluedMap<String, String> encodedParams = session.getContext().getUri().getQueryParameters(false);
    String algorithm = encodedParams.getFirst(GeneralConstants.SAML_SIG_ALG_REQUEST_KEY);
    String signature = encodedParams.getFirst(GeneralConstants.SAML_SIGNATURE_REQUEST_KEY);
    return algorithm != null && signature != null;
}

Le vérificateur et le code de traitement ne sont pas d'accord sur le paramètre de requête qui correspond à SAMLResponse. La signature valide donc un message tandis que le courtier en analyse un autre.

Comment la faille est-elle exploitée ?

L'attaquant a besoin d'un message de liaison redirect signé par le fournisseur d'identité et d'une session de connexion qu'il a lui-même démarrée. Il envoie ensuite les deux messages dans l'ordre qui sépare la vérification du traitement.

1. L'attaquant possède un compte auprès du fournisseur d'identité SAML externe que le royaume Keycloak fédère.
2. L'attaquant démarre une connexion via le courtier et capture un message de liaison redirect valide et signé que le fournisseur d'identité émet pour ce compte. La description de Red Hat donne une réponse de déconnexion comme exemple.
3. L'attaquant fabrique une réponse SAML non signée qui affirme l'identité de la victime, avec le Destination et le InResponseTo de la session de connexion qu'il a démarrée.
4. L'attaquant envoie une requête GET au point de terminaison du courtier. La réponse fabriquée vient en premier, sous %53AMLResponse. Le message signé légitime vient en second, sous le nom littéral SAMLResponse. La requête conserve le RelayState, le SigAlg et la Signature du message signé.
5. JAX-RS décode les deux noms de paramètres en SAMLResponse et transmet la première valeur, la réponse fabriquée, à execute.
6. verifyRedirectSignature lit la requête brute sans décoder les noms, ne trouve que le littéral SAMLResponse et valide la signature sur le message signé.
7. La réponse fabriquée est analysée, l'assertion non signée passe la vérification « message entièrement signé » parce que la requête contient SigAlg et Signature, et Keycloak connecte l'attaquant en tant que victime.

Aucune preuve de concept publique n'était connue au moment de la vérification, le 5 novembre 2026. Ces étapes proviennent de la description Bugzilla de Red Hat et des chemins de code de la section « Quelle est la cause racine ? ».

Comment se déroule l'attaque ?

L'attaquant associe une assertion non signée à un message signé pour que Keycloak vérifie le message signé mais traite le message non signé.

Que peut faire un attaquant ?

Un attaquant qui réussit le contournement se connecte en tant qu'utilisateur fédéré nommé dans l'assertion fabriquée, avec les rôles et les données de cet utilisateur.

Le contournement exige toutes ces conditions :

• Un compte auprès du fournisseur d'identité externe, que l'attaquant utilise pour obtenir un message de liaison redirect valide et signé.
• Une session de connexion via le courtier que l'attaquant a démarrée, afin que la réponse fabriquée porte le Destination et le InResponseTo correspondants.
• Un royaume qui fédère ce fournisseur d'identité via la liaison HTTP-Redirect.
• La validation de signature active et « Want Assertions Signed » désactivé, la configuration courante.
• Un accès réseau au point de terminaison du courtier Keycloak.

Red Hat écrit que l'exploitation permet à un attaquant de « se connecter en tant que n'importe quel utilisateur ». Elle lui permet aussi d'« accéder à ses rôles et à ses données sans autorisation ».

L'impact suit les rôles de la victime, donc une victime disposant d'un accès administratif dans une application connectée transmet cet accès. Le vecteur CVSS fixe l'impact sur la disponibilité à None, et l'avis ne décrit ni exécution de code ni déni de service.

Pourquoi le correctif fonctionne-t-il ?

Le correctif fait trois choses. Il aligne la vérification de signature sur les noms de paramètres décodés du traitement. Il rejette les paramètres SAML en double. Il compare la valeur signée avec la valeur traitée.

L'analyseur d'URI partagé décode désormais les noms de paramètres tout en laissant les valeurs encodées :

--- a/server-spi/src/main/java/org/keycloak/models/KeycloakUriInfo.java
+++ b/server-spi/src/main/java/org/keycloak/models/KeycloakUriInfo.java
@@
-        for (Map.Entry<String, List<String>> entry : parseQueryParameters(rawQuery, false).entrySet()) {
+        for (Map.Entry<String, List<String>> entry : parseQueryParameters(rawQuery, true, false).entrySet()) {

Avec les noms décodés, %53AMLResponse et SAMLResponse apparaissent tous deux sous SAMLResponse dans la vue brute, et la nouvelle vérification des doublons rejette la requête :

--- a/services/src/main/java/org/keycloak/protocol/saml/SamlProtocolUtils.java
+++ b/services/src/main/java/org/keycloak/protocol/saml/SamlProtocolUtils.java
@@
+    public static void rejectRepeatedRedirectParameters(MultivaluedMap<String, String> encodedParams) throws VerificationException {
+        for (String name : REDIRECT_SIGNATURE_PARAMETERS) {
+            List<String> values = encodedParams.get(name);
+            if (values != null && values.size() > 1) {
+                throw new VerificationException("Query parameter " + name + " is present more than once");
+            }
+        }
+    }
+
+    private static void verifySignedValueIsProcessed(MultivaluedMap<String, String> encodedParams, String paramKey, String processedValue) throws VerificationException {
+        String signedValue = encodedParams.getFirst(paramKey);
+        String decodedSignedValue;
+        try {
+            decodedSignedValue = signedValue == null ? null : RedirectBindingUtil.urlDecode(signedValue);
+        } catch (IOException | IllegalArgumentException e) {
+            throw new VerificationException("Invalid encoding of query parameter " + paramKey, e);
+        }
+        if (!Objects.equals(decodedSignedValue, processedValue)) {
+            throw new VerificationException("Query parameter " + paramKey + " being processed is not the signed one");
+        }
+    }

Le point de terminaison transmet désormais le message qu'il traite au vérificateur :

--- a/services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java
+++ b/services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java
@@
-                    verifySignature(GeneralConstants.SAML_RESPONSE_KEY, holder);
+                    verifySignature(GeneralConstants.SAML_RESPONSE_KEY, holder, samlResponse, relayState);

verifySignedValueIsProcessed décode la valeur signée et la compare avec la valeur transmise à execute. Un message signé qui diffère du message traité échoue, même si la vérification des doublons est contournée. RelayState subit la même comparaison. rejectRepeatedRedirectParameters est aussi appelé depuis basicChecks et depuis la liaison redirect de SamlService, donc les deux points de terminaison de redirection rejettent les doublons avant le traitement.

Le commit corrige les deux copies de la vérification de liaison redirect qu'il touche. Il s'agit du point de terminaison du courtier dans SAMLEndpoint et du point de terminaison du fournisseur d'identité dans SamlService. Les liaisons POST et artifact ne lisent pas la chaîne de requête de cette manière et restent inchangées.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission public n'a été publié pour CVE-2026-117691 au 5 novembre 2026.

La description publique donne une piste : un nom de paramètre SAML encodé en pourcentage dans une requête vers le point de terminaison du courtier. Si votre proxy inverse conserve les chaînes de requête, cherchez dans son journal d'accès :

grep -iE '[?&](%[0-9a-f]{2})+(amlresponse|amlrequest|elaystate|igalg|ignature)=' /var/log/nginx/access.log

Si vos journaux stockent les chaînes de requête décodées, cherchez plutôt deux paramètres SAMLResponse dans une même requête :

grep -iE '[?&]samlresponse=[^&]*&.*[?&]samlresponse=' /var/log/nginx/access.log

Un résultat est une piste, pas une preuve : un client légitime peut encoder un nom en pourcentage ou envoyer un paramètre en double. Confirmez-le avec la requête complète et les journaux du fournisseur d'identité. Une tentative échouée peut ne laisser aucune trace si les chaînes de requête ne sont pas journalisées, donc l'absence de résultat ne prouve pas qu'aucune tentative n'a eu lieu.

Chronologie

• 2026-10-26 : signalement à Red Hat.
• 2026-11-05 : publication de CVE-2026-117691.
• 2026-11-05 : le commit de correctif cbda2bfd35 arrive dans keycloak/keycloak.
• 2026-11-05 : publication de Keycloak 26.8.2.
• 2026-11-05 : aucune preuve de concept publique et aucune entrée KEV de la CISA au moment de la vérification.

Dix jours se sont écoulés entre le signalement et la divulgation publique. Le commit de correctif est arrivé 1 heure 52 minutes après la publication de l'enregistrement CVE, et la version 26.8.2 a suivi 41 minutes plus tard.

FAQ

Cette faille concerne-t-elle Keycloak lorsqu'il agit comme fournisseur d'identité SAML plutôt que comme courtier ?

L'impact de prise de contrôle de compte se situe sur le chemin du courtier, où Keycloak consomme une réponse d'un fournisseur d'identité externe. Le même commit renforce aussi la vérification de la liaison redirect dans SamlService, le point de terminaison du fournisseur d'identité, donc le correctif couvre les deux chemins.

L'attaquant a-t-il besoin d'un compte Keycloak ?

Non. Red Hat évalue l'attaque sans privilèges requis, car aucun compte Keycloak n'est nécessaire. L'attaquant doit toutefois disposer d'un compte auprès du fournisseur d'identité externe pour obtenir un message de liaison redirect valide et signé.

« Want Assertions Signed » suffit-il comme correctif ?

Il bloque l'assertion fabriquée non signée, donc il réduit l'exposition. Ce n'est pas un substitut à 26.8.2, car il modifie le contrat avec le fournisseur d'identité et ne fonctionne que si celui-ci signe les assertions.

Existe-t-il un exploit public ?

Aucune preuve de concept publique ni exploitation en conditions réelles n'était connue au 5 novembre 2026. L'enregistrement Authorized Data Publisher (ADP) de la CISA indique Exploitation: none, et la CVE n'est pas dans le catalogue KEV.

Quelle version corrige la faille ?

Keycloak 26.8.2, publié le 5 novembre 2026. Les rétroportages 26.6.8 et 26.4.17 étaient étiquetés mais non publiés au moment de la vérification, et Red Hat Build of Keycloak n'avait aucun errata.

Red Hat Single Sign-On 7 est-il concerné ?

Non. Red Hat le classe comme non concerné, car le code vulnérable n'est pas présent.

Références

• Red Hat, avis « CVE-2026-117691 », https://access.redhat.com/security/cve/CVE-2026-117691 (vérifié le 5 novembre 2026).
• CVE Program, enregistrement « CVE-2026-117691 », https://www.cve.org/CVERecord?id=CVE-2026-117691 (vérifié le 5 novembre 2026).
• Red Hat Bugzilla, « CVE-2026-117691 keycloak-services: SAML redirect binding signature bypass via percent-encoded parameter names », https://bugzilla.redhat.com/show_bug.cgi?id=2561977 (vérifié le 5 novembre 2026).
• keycloak/keycloak, « Verify the SAML redirect binding message that is processed », commit cbda2bfd35e2eb182942996832b819c35780b121, https://github.com/keycloak/keycloak/commit/cbda2bfd35e2eb182942996832b819c35780b121 (vérifié le 5 novembre 2026).
• keycloak/keycloak, version « 26.8.2 », https://github.com/keycloak/keycloak/releases/tag/26.8.2 (vérifié le 5 novembre 2026).
• keycloak/keycloak, SamlProtocolUtils.java à 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/services/src/main/java/org/keycloak/protocol/saml/SamlProtocolUtils.java (vérifié le 5 novembre 2026).
• keycloak/keycloak, SAMLEndpoint.java à 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java (vérifié le 5 novembre 2026).
• keycloak/keycloak, KeycloakUriInfo.java à 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/server-spi/src/main/java/org/keycloak/models/KeycloakUriInfo.java (vérifié le 5 novembre 2026).
• keycloak/keycloak, UriUtils.java à 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/common/src/main/java/org/keycloak/common/util/UriUtils.java (vérifié le 5 novembre 2026).
• keycloak/keycloak, « CVE-2026-117691 SAML redirect binding signature bypass via percent-encoded parameter name », issue 54714, https://github.com/keycloak/keycloak/issues/54714 (vérifié le 5 novembre 2026).
• Keycloak, « Configuring a SAML identity provider », guide d'administration du serveur, https://www.keycloak.org/docs/26.8.1/server_admin/#_identity_broker_saml (vérifié le 5 novembre 2026).
• Cybersecurity and Infrastructure Security Agency, catalogue Known Exploited Vulnerabilities, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (vérifié le 5 novembre 2026).
• National Vulnerability Database, « CVE-2026-117691 », https://nvd.nist.gov/vuln/detail/CVE-2026-117691 (vérifié le 5 novembre 2026).