Keycloak: omisión de autenticación SAML, corregida en 26.8.2 (CVE-2026-117691)

Resumen

• Un fallo en el enlace SAML de Keycloak permite a un atacante iniciar sesión como cualquier federado. Basta con enviar un mensaje sin firmar junto a uno firmado. Red Hat publicó CVE-2026-117691 el 5 de noviembre de 2026.
• Los reinos que intermedian un proveedor de identidad SAML externo quedan expuestos cuando la validación de firma está activa y no se exigen aserciones firmadas. Red Hat Build of Keycloak está afectado; Red Hat Single Sign-On 7 no lo está.
• Red Hat asigna una puntuación CVSS v3.1 de 9.1 y un impacto Important. No existía ningún exploit público ni entrada KEV (Known Exploited Vulnerabilities) de la CISA (agencia estadounidense de ciberseguridad) a fecha de 5 de noviembre de 2026.
• Actualice a Keycloak 26.8.2, publicado el 5 de noviembre de 2026. Red Hat no había publicado ningún errata cuando se comprobó; consulte «¿Cómo lo corrijo?» para las soluciones alternativas y sus límites.

¿Estoy afectado?

Usted se ve afectado si su reino intermedia un proveedor de identidad SAML externo mediante el enlace HTTP-Redirect y ejecuta una versión de Keycloak que contiene la comprobación vulnerable.

• El reino tiene un proveedor de identidad SAML configurado para la intermediación de identidades, y ese proveedor devuelve sus respuestas mediante el enlace HTTP-Redirect.
• La validación de firma está activa para ese proveedor de identidad. Keycloak la activa cuando importa el certificado de firma del proveedor desde los metadatos, y la omisión solo importa cuando Keycloak verifica realmente una firma.
• El proveedor de identidad no exige aserciones firmadas. Con «Want Assertions Signed» activado, Keycloak rechaza la aserción fabricada sin firmar.
• La versión de Keycloak está afectada según la tabla de versiones.

Red Hat clasifica Red Hat Single Sign-On 7 como no afectado porque el código vulnerable no está presente. Red Hat Build of Keycloak está afectado, y Red Hat no había publicado ningún errata cuando se comprobó, el 5 de noviembre de 2026. La rama main (nightly) de keycloak/keycloak todavía contenía la comprobación antigua en esa fecha; 26.8.2 es la versión corregida.

Red Hat, como autoridad de numeración de CVE, asigna al fallo una puntuación CVSS v3.1 de 9.1. El vector es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.

La severidad base es Crítica, mientras que la calificación de impacto propia de Red Hat para sus productos es Important. NVD no había analizado el registro cuando se comprobó, el 5 de noviembre de 2026.

Keycloak mantiene tres ramas de mantenimiento. Una rama tiene un correctivo publicado, y las otras dos tienen correctivos etiquetados para 26.6.8 y 26.4.17, pero no publicados el 5 de noviembre de 2026.

Compruebe qué se ejecuta, en el host y dentro de cada contenedor:

/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 utiliza el mismo binario kc.sh dentro de su imagen, así que la comprobación con docker exec también se aplica a registry.redhat.io/rhbk/keycloak-rhel9.

¿Cómo lo corrijo?

Actualice a Keycloak 26.8.2, la primera versión upstream con la corrección, o a la versión retroportada de su rama en cuanto se publique. Para un despliegue en contenedores, descargue primero la imagen corregida:

docker pull quay.io/keycloak/keycloak:26.8.2

1. Vuelva a crear el contenedor. Un contenedor en ejecución conserva la imagen antigua hasta que se vuelve a crear.
2. Para una instalación ZIP, descargue keycloak-26.8.2.zip desde la página de la versión. Haga una copia de seguridad de la configuración y de la base de datos, y después sustituya la instalación.
3. Para Red Hat Build of Keycloak, Red Hat no había publicado ningún errata el 5 de noviembre de 2026. Siga el aviso de Red Hat y actualice rhbk/keycloak-rhel9 cuando aparezca una compilación corregida.
4. Red Hat Single Sign-On 7 no requiere ninguna acción para este CVE.

Red Hat no indica ninguna mitigación que cumpla sus criterios de seguridad de producto. Si no puede actualizar, dos opciones reducen la exposición. Ninguna es una corrección compatible.

• Exigir aserciones firmadas: active «Want Assertions Signed» para el proveedor de identidad cuando ese proveedor firma las aserciones. Keycloak rechaza entonces la aserción fabricada sin firmar. Esto cubre CVE-2026-117691 para ese proveedor, pero cambia el contrato de confianza y no sirve de nada si el proveedor no firma las aserciones.
• Rechazar parámetros ambiguos en el perímetro. En el proxy inverso delante de Keycloak, rechace las solicitudes al punto de conexión del intermediario que contengan un nombre de parámetro codificado en porcentaje. Rechace también una solicitud que repita uno de los parámetros firmados:
  • SAMLResponse
  • SAMLRequest
  • RelayState
  • SigAlg
  • Signature

Esta regla reproduce la corrección, pero el proxy debe decodificar los nombres antes de compararlos y puede romper clientes que usan codificaciones poco habituales. Pruébela primero en modo de solo registro.

¿Cuál es la causa raíz?

El fallo es una discrepancia entre el nombre de parámetro que Keycloak utiliza para procesar un mensaje SAML y el que utiliza para verificar la firma de ese mensaje.

El intermediario SAML de Keycloak acepta una respuesta de autenticación de un proveedor de identidad externo mediante el enlace HTTP-Redirect. En ese enlace, todo el mensaje SAML viaja en un parámetro de consulta, y el proveedor de identidad firma la cadena de consulta en lugar del documento XML.

El punto de entrada del intermediario es SAMLEndpoint.redirectBinding. Declara samlResponse como un @QueryParam de JAX-RS, así que el framework decodifica los nombres de parámetro antes de compararlos. Cuando una solicitud contiene tanto %53AMLResponse como SAMLResponse, ambos se decodifican como SAMLResponse, y el método recibe el primer valor en el orden de la solicitud.

// 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);
}

El verificador lee la consulta mediante otra API. KeycloakUriInfo.getQueryParameters(false) debería devolver la consulta sin procesar. En 26.8.1 llama a parseQueryParameters(rawQuery, false), y ese false desactiva la decodificación tanto de los nombres como de los valores.

// 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 divide la consulta sin procesar por & y solo decodifica un nombre cuando su argumento decode es true. Con false, %53AMLResponse sigue siendo %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 busca paramKey, que es SAMLResponse, en ese mapa sin procesar. La copia codificada en porcentaje es invisible bajo esa clave, así que getFirst devuelve el mensaje literal firmado. El método reconstruye la cadena firmada a partir de ese valor, RelayState y SigAlg, y verifica la firma del proveedor de identidad sobre ella.

// 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 firma es válida, pero cubre un mensaje que el servidor no va a procesar. redirectBinding ya ha pasado el primer valor fabricado a execute, y handleLoginResponse considera después que el mensaje está totalmente firmado porque SigAlg y Signature están presentes. La aserción fabricada nunca está firmada.

// 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);

Para el enlace redirect, isMessageFullySigned devuelve containsUnencryptedSignature, que solo comprueba que SigAlg y Signature estén presentes en la consulta.

// 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;
}

El verificador y el código de procesamiento no coinciden en qué parámetro de consulta es SAMLResponse, así que la firma valida un mensaje mientras el intermediario analiza otro.

¿Cómo se explota?

El atacante necesita un mensaje de enlace redirect firmado por el proveedor de identidad y una sesión de inicio de sesión que haya iniciado él mismo. Después envía los dos mensajes en el orden que separa la verificación del procesamiento.

1. El atacante tiene una cuenta en el proveedor de identidad SAML externo que intermedia el reino de Keycloak.
2. El atacante inicia un inicio de sesión a través del intermediario y captura un mensaje de enlace redirect válido y firmado que el proveedor de identidad emite para esa cuenta. La descripción de Red Hat da una respuesta de cierre de sesión como ejemplo.
3. El atacante fabrica una respuesta SAML sin firmar que afirma la identidad de la víctima, con el Destination y el InResponseTo de la sesión de inicio de sesión que inició.
4. El atacante envía una solicitud GET al punto de conexión del intermediario. La respuesta fabricada va primero, bajo %53AMLResponse. El mensaje firmado legítimo va segundo, bajo el literal SAMLResponse. La solicitud conserva el RelayState, el SigAlg y la Signature del mensaje firmado.
5. JAX-RS decodifica ambos nombres de parámetro como SAMLResponse y pasa el primer valor, la respuesta fabricada, a execute.
6. verifyRedirectSignature lee la consulta sin procesar sin decodificar los nombres, encuentra solo el literal SAMLResponse y valida la firma sobre el mensaje firmado.
7. La respuesta fabricada se analiza. La aserción sin firmar supera la comprobación de «mensaje totalmente firmado» porque la consulta lleva SigAlg y Signature. Keycloak inicia la sesión del atacante como la víctima.

No se conocía ninguna prueba de concepto pública cuando se comprobó, el 5 de noviembre de 2026. Estos pasos proceden de la descripción de Bugzilla de Red Hat y de las rutas de código de «¿Cuál es la causa raíz?».

¿Cómo se desarrolla el ataque?

El atacante empareja una aserción sin firmar con un mensaje firmado para que Keycloak verifique el mensaje firmado pero procese el mensaje sin firmar.

¿Qué puede hacer un atacante?

Un atacante que completa la omisión inicia sesión como el usuario federado nombrado en la aserción fabricada, con los roles y los datos de ese usuario.

La omisión requiere todas estas condiciones:

• Una cuenta en el proveedor de identidad externo, que el atacante utiliza para obtener un mensaje de enlace redirect válido y firmado.
• Una sesión de inicio de sesión a través del intermediario que el atacante haya iniciado, para que la respuesta fabricada lleve el Destination y el InResponseTo correspondientes.
• Un reino que intermedie ese proveedor de identidad mediante el enlace HTTP-Redirect.
• La validación de firma activa y «Want Assertions Signed» desactivado, la configuración habitual.
• Acceso de red al punto de conexión del intermediario de Keycloak.

La declaración de Red Hat indica que la explotación permite a un atacante «iniciar sesión como cualquier usuario» y «acceder a sus roles y datos sin autorización».

El impacto sigue los roles de la víctima, así que una víctima con acceso administrativo en una aplicación conectada transmite ese acceso. El vector CVSS fija el impacto en la disponibilidad en None, y el aviso no describe ejecución de código ni denegación de servicio.

¿Por qué funciona la corrección?

La corrección hace tres cosas. Alinea la comprobación de firma con los nombres de parámetro decodificados del procesamiento. Rechaza los parámetros SAML duplicados. Compara el valor firmado con el valor procesado.

El analizador de URI compartido ahora decodifica los nombres de parámetro y deja los valores codificados:

--- 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()) {

Con los nombres decodificados, %53AMLResponse y SAMLResponse aparecen ambos bajo SAMLResponse en la vista sin procesar, y la nueva comprobación de duplicados rechaza la solicitud:

--- 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");
+        }
+    }

El punto de conexión ahora pasa al verificador el mensaje que está procesando:

--- 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 decodifica el valor firmado y lo compara con el valor pasado a execute. Un mensaje firmado que difiere del mensaje procesado falla aunque se omita la comprobación de duplicados. RelayState recibe la misma comparación. rejectRepeatedRedirectParameters también se llama desde basicChecks y desde el enlace redirect de SamlService, así que ambos puntos de conexión de redirección rechazan los duplicados antes de procesar.

El commit corrige las dos copias de la comprobación del enlace redirect que toca. Se trata del punto de conexión del intermediario en SAMLEndpoint y del punto de conexión del proveedor de identidad en SamlService. Los enlaces POST y artifact no leen la cadena de consulta de esta forma y no cambian.

¿Cómo compruebo si estuve comprometido?

No se ha publicado ningún indicador de compromiso público para CVE-2026-117691 a fecha de 5 de noviembre de 2026.

La descripción pública ofrece una pista: un nombre de parámetro SAML codificado en porcentaje en una solicitud al punto de conexión del intermediario. Si su proxy inverso conserva las cadenas de consulta, busque en su registro de acceso:

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

Si sus registros almacenan las cadenas de consulta decodificadas, busque dos parámetros SAMLResponse en una misma solicitud:

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

Un resultado es una pista, no una prueba: un cliente legítimo podría codificar un nombre en porcentaje o enviar un parámetro duplicado. Confírmelo con la solicitud completa y los registros del proveedor de identidad. Un intento fallido puede no dejar rastro si no se registran las cadenas de consulta, así que la ausencia de resultados no demuestra que no se haya intentado.

Cronología

• 2026-10-26: notificado a Red Hat.
• 2026-11-05: publicado CVE-2026-117691.
• 2026-11-05: el commit de la corrección cbda2bfd35 llega a keycloak/keycloak.
• 2026-11-05: publicado Keycloak 26.8.2.
• 2026-11-05: ninguna prueba de concepto pública y ninguna entrada en KEV de CISA cuando se comprobó.

Transcurrieron diez días entre la notificación y la divulgación pública. El commit de la corrección llegó 1 hora y 52 minutos después de la publicación del registro CVE, y la versión 26.8.2 la siguió 41 minutos más tarde.

Preguntas frecuentes

¿Afecta esto a Keycloak cuando actúa como proveedor de identidad SAML en lugar de intermediario?

El impacto de toma de control de cuenta está en la ruta del intermediario, donde Keycloak consume una respuesta de un proveedor de identidad externo. El mismo commit también refuerza la comprobación del enlace redirect en SamlService, el punto de conexión del proveedor de identidad, así que la corrección cubre ambas rutas.

¿Necesita el atacante una cuenta de Keycloak?

No. Red Hat puntúa el ataque sin privilegios requeridos porque no se necesita ninguna cuenta de Keycloak. El atacante sí necesita una cuenta en el proveedor de identidad externo para obtener un mensaje de enlace redirect válido y firmado.

¿Es «Want Assertions Signed» una corrección?

Bloquea la aserción fabricada sin firmar, así que reduce la exposición. No sustituye a 26.8.2 porque cambia el contrato con el proveedor de identidad y solo funciona cuando ese proveedor firma las aserciones.

¿Existe un exploit público?

No se conocía ninguna prueba de concepto pública ni explotación en entornos reales a fecha de 5 de noviembre de 2026. El registro Authorized Data Publisher (ADP) de CISA indica Exploitation: none, y el CVE no está en el catálogo KEV.

¿Qué versión lo corrige?

Keycloak 26.8.2, publicado el 5 de noviembre de 2026. Las versiones retroportadas 26.6.8 y 26.4.17 estaban etiquetados pero no publicados cuando se comprobó, y Red Hat Build of Keycloak no tenía ningún errata.

¿Está afectado Red Hat Single Sign-On 7?

No. Red Hat lo clasifica como no afectado porque el código vulnerable no está presente.

Referencias

• Red Hat, aviso «CVE-2026-117691», https://access.redhat.com/security/cve/CVE-2026-117691 (comprobado el 5 de noviembre de 2026).
• CVE Program, registro «CVE-2026-117691», https://www.cve.org/CVERecord?id=CVE-2026-117691 (comprobado el 5 de noviembre de 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 (comprobado el 5 de noviembre de 2026).
• keycloak/keycloak, «Verify the SAML redirect binding message that is processed», commit cbda2bfd35e2eb182942996832b819c35780b121, https://github.com/keycloak/keycloak/commit/cbda2bfd35e2eb182942996832b819c35780b121 (comprobado el 5 de noviembre de 2026).
• keycloak/keycloak, versión «26.8.2», https://github.com/keycloak/keycloak/releases/tag/26.8.2 (comprobado el 5 de noviembre de 2026).
• keycloak/keycloak, SamlProtocolUtils.java en 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/services/src/main/java/org/keycloak/protocol/saml/SamlProtocolUtils.java (comprobado el 5 de noviembre de 2026).
• keycloak/keycloak, SAMLEndpoint.java en 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java (comprobado el 5 de noviembre de 2026).
• keycloak/keycloak, KeycloakUriInfo.java en 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/server-spi/src/main/java/org/keycloak/models/KeycloakUriInfo.java (comprobado el 5 de noviembre de 2026).
• keycloak/keycloak, UriUtils.java en 26.8.1, https://github.com/keycloak/keycloak/blob/26.8.1/common/src/main/java/org/keycloak/common/util/UriUtils.java (comprobado el 5 de noviembre de 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 (comprobado el 5 de noviembre de 2026).
• Keycloak, «Configuring a SAML identity provider», guía de administración del servidor, https://www.keycloak.org/docs/26.8.1/server_admin/#_identity_broker_saml (comprobado el 5 de noviembre de 2026).
• Cybersecurity and Infrastructure Security Agency, catálogo Known Exploited Vulnerabilities, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (comprobado el 5 de noviembre de 2026).
• National Vulnerability Database, «CVE-2026-117691», https://nvd.nist.gov/vuln/detail/CVE-2026-117691 (comprobado el 5 de noviembre de 2026).