KeycloakのSAML認証バイパス、26.8.2で修正（CVE-2026-117691）

要点

• KeycloakのSAML HTTP-Redirectバインディングの欠陥により、攻撃者は未署名のメッセージを署名済みメッセージと並べて送信し、任意のフェデレーションユーザーとしてログインできます。Red Hatは2026年11月5日にCVE-2026-117691を公開しました。
• 外部のSAML IDプロバイダーをIDブローカリング（identity brokering）し、署名検証が有効で、署名済みアサーションを必須にしていないレルムが影響を受けます。Red Hat Build of Keycloakは影響を受け、Red Hat Single Sign-On 7は影響を受けません。
• Red HatはCVE番号発行機関としてCVSS v3.1 9.1を割り当て、自社製品への影響度をImportantと評価しています。2026年11月5日時点で、公開エクスプロイトも、Cybersecurity and Infrastructure Security Agency（CISA）のKnown Exploited Vulnerabilities（KEV）カタログへの登録もありませんでした。
• Keycloak 26.8.2（2026年11月5日公開）にアップグレードしてください。確認時点でRed Hatのエラータは未公開でした。回避策とその限界は「修正方法」を参照してください。

影響を受けますか？

レルムが外部のSAML IDプロバイダーをHTTP-RedirectバインディングでIDブローカリングし、脆弱なチェックを含むKeycloakリリースを実行している場合に影響を受けます。

• レルムにIDブローカリング用のSAML IDプロバイダーが設定されており、そのプロバイダーがHTTP-Redirectバインディングで応答を返します。
• そのIDプロバイダーの署名検証が有効です。Keycloakはメタデータからプロバイダーの署名証明書をインポートするときに署名検証を有効にし、Keycloakが実際に署名を検証する場合にのみこのバイパスが意味を持ちます。
• IDプロバイダーが署名済みアサーションを必須にしていません。「Want Assertions Signed」を有効にすると、Keycloakは未署名の細工されたアサーションを拒否します。
• Keycloakのバージョンがバージョン表の影響範囲に含まれます。

Red Hatは、脆弱なコードが存在しないため、Red Hat Single Sign-On 7を影響なしとしています。Red Hat Build of Keycloakは影響を受け、2026年11月5日の確認時点でRed Hatのエラータは未公開でした。keycloak/keycloakのmainブランチ（nightly）には同日時点で古いチェックが残っていました。修正済みリリースは26.8.2です。

Red HatはCVE番号発行機関として、この欠陥にCVSS v3.1 9.1を割り当てています。ベクトルはCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Nです。基本重大度はCriticalですが、Red Hatの自社製品に対する影響度評価はImportantです。NVDは2026年11月5日の確認時点でレコードを分析していませんでした。

Keycloakは3つのリリースブランチを維持しています。1つは修正版が公開され、残る2つは26.6.8と26.4.17向けの修正がラベル付けされているものの、2026年11月5日時点では未公開です。

ホスト上と各コンテナ内で、実行中のものを確認してください。

/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のイメージにも同じkc.shバイナリが含まれるため、docker execによる確認はregistry.redhat.io/rhbk/keycloak-rhel9にも当てはまります。

修正方法

Keycloak 26.8.2（修正を含む最初のアップストリームリリース）へ、または各ブランチのバックポートが公開され次第そちらへアップグレードしてください。コンテナで運用している場合は、先に修正済みイメージを取得します。

docker pull quay.io/keycloak/keycloak:26.8.2

1. コンテナを再作成します。実行中のコンテナは、再作成するまで古いイメージを使い続けます。
2. ZIPインストールの場合は、リリースページからkeycloak-26.8.2.zipをダウンロードします。設定とデータベースをバックアップしてから、インストールを置き換えます。
3. Red Hat Build of Keycloakの場合、Red Hatは2026年11月5日時点でエラータを公開していませんでした。Red Hatのアドバイザリを追跡し、修正版が公開されたらrhbk/keycloak-rhel9を更新してください。
4. Red Hat Single Sign-On 7は、このCVEに対する対応は不要です。

Red Hatは、製品セキュリティの基準を満たす緩和策を示していません。アップグレードできない場合、影響を減らす選択肢は2つあります。どちらもサポートされた修正ではありません。

• 署名済みアサーションを必須にする：IDプロバイダーがアサーションに署名する場合、「Want Assertions Signed」を有効にします。Keycloakは未署名の細工されたアサーションを拒否します。これはそのプロバイダーに対してCVE-2026-117691を防ぎますが、信頼の取り決めを変えるため、プロバイダーがアサーションに署名しない場合は効果がありません。
• 境界で曖昧なパラメーターを拒否する。Keycloakの前段のリバースプロキシで、ブローカーのエンドポイントへのリクエストのうち、パーセントエンコードされたパラメーター名を含むものを拒否します。署名対象のパラメーターのいずれかを繰り返すリクエストも拒否します。
  • SAMLResponse
  • SAMLRequest
  • RelayState
  • SigAlg
  • Signature

このルールは修正を反映したものですが、プロキシは比較前に名前をデコードする必要があり、特殊なエンコーディングを使うクライアントを壊す可能性があります。まずログのみのモードで試してください。

根本原因は何ですか？

この不具合は、KeycloakがSAMLメッセージの処理に使うパラメーター名と、そのメッセージの署名検証に使うパラメーター名の不一致です。

KeycloakのSAMLブローカーは、外部IDプロバイダーからの認証応答をHTTP-Redirectバインディングで受け取ります。このバインディングではSAMLメッセージ全体がクエリパラメーターで運ばれ、IDプロバイダーはXML文書ではなくクエリ文字列に署名します。

ブローカーの入口はSAMLEndpoint.redirectBindingです。samlResponseをJAX-RSの@QueryParamとして宣言するため、フレームワークは照合前にパラメーター名をデコードします。リクエストが%53AMLResponseとSAMLResponseの両方を含む場合、どちらもSAMLResponseにデコードされ、メソッドはクエリ順で最初の値を受け取ります。

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

検証側は別のAPIでクエリを読みます。KeycloakUriInfo.getQueryParameters(false)は生のクエリを返すためのものです。26.8.1ではparseQueryParameters(rawQuery, false)を呼び出し、このfalseが名前と値の両方のデコードを無効にします。

// 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は生のクエリを&で分割し、decode引数がtrueのときだけ名前をデコードします。falseの場合、%53AMLResponseは%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は、SAMLResponseであるparamKeyをこの生のマップから検索します。パーセントエンコードされたコピーはそのキーでは見えないため、getFirstはリテラルの署名済みメッセージを返します。メソッドはその値、RelayState、SigAlgから署名対象の文字列を再構築し、IDプロバイダーの署名を検証します。

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

署名は有効ですが、サーバーが処理しないメッセージを対象にしています。redirectBindingはすでに細工された最初の値をexecuteに渡しており、handleLoginResponseはSigAlgとSignatureが存在するため、メッセージを完全に署名済みとみなします。細工されたアサーション自体には署名がありません。

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

リダイレクトバインディングでは、isMessageFullySignedはcontainsUnencryptedSignatureを返し、クエリにSigAlgとSignatureがあるかだけを確認します。

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

検証側と処理側で、どのクエリパラメーターがSAMLResponseかという認識が一致しないため、署名は一方のメッセージを検証し、ブローカーはもう一方を解析します。

どのように悪用されますか？

攻撃者は、IDプロバイダーが発行した有効な署名済みリダイレクトバインディングメッセージと、自分が開始したログインセッションを用意します。その後、検証と処理を分離する順序で2つのメッセージを送信します。

1. 攻撃者は、KeycloakのレルムがIDブローカリングする外部SAML IDプロバイダーのアカウントを持っています。
2. 攻撃者はブローカーログインを開始し、そのアカウントに対してIDプロバイダーが発行する有効な署名済みリダイレクトバインディングメッセージを1つ取得します。Red Hatの説明では、ログアウト応答を例に挙げています。
3. 攻撃者は、開始したログインセッションのDestinationとInResponseToを持つ、被害者のIDを主張する未署名のSAML応答を作成します。
4. 攻撃者はブローカーのエンドポイントにGETリクエストを送信します。細工した応答を%53AMLResponseとして最初に置き、正規の署名済みメッセージをリテラルのSAMLResponseとして次に置きます。リクエストは署名済みメッセージのRelayState、SigAlg、Signatureを保持します。
5. JAX-RSは両方のパラメーター名をSAMLResponseにデコードし、最初の値である細工した応答をexecuteに渡します。
6. verifyRedirectSignatureは名前をデコードせずに生のクエリを読み、リテラルのSAMLResponseだけを見つけて、署名済みメッセージに対して署名を検証します。
7. 細工した応答が解析され、未署名のアサーションはクエリにSigAlgとSignatureがあるため「完全に署名済み」のチェックを通過し、Keycloakは攻撃者を被害者としてログインさせます。

2026年11月5日の確認時点で、公開された概念実証はありませんでした。これらの手順は、Red HatのBugzillaの説明と「根本原因は何ですか？」で示したコード経路に基づいています。

攻撃の流れは？

攻撃者は未署名のアサーションを署名済みメッセージと組み合わせ、Keycloakが署名済みメッセージを検証しながら未署名メッセージを処理するようにします。

攻撃者に何ができますか？

バイパスを完了した攻撃者は、細工したアサーションに記載されたフェデレーションユーザーとしてログインし、そのユーザーのロールとデータを利用できます。

バイパスには次の条件がすべて必要です。

• 外部IDプロバイダーのアカウント。攻撃者はこれを使って、有効な署名済みリダイレクトバインディングメッセージを1つ取得します。
• 攻撃者が開始したブローカーログインセッション。細工した応答が対応するDestinationとInResponseToを持つために必要です。
• そのIDプロバイダーをHTTP-RedirectバインディングでIDブローカリングするレルム。
• 署名検証が有効で、「Want Assertions Signed」が無効という一般的な設定。
• Keycloakのブローカーエンドポイントへのネットワークアクセス。

Red Hatの声明は、悪用に成功すると攻撃者が「任意のユーザーとしてログインし、そのロールとデータに権限なくアクセスできる」と述べています。影響は被害者のロールに従うため、接続先アプリケーションで管理者権限を持つ被害者なら、その権限も引き継がれます。CVSSベクトルは可用性への影響をNoneに設定しており、アドバイザリはコード実行やサービス拒否について述べていません。

修正が機能する理由

修正は3つのことを行います。署名検証を処理側と同じデコード済みパラメーター名に合わせます。重複したSAMLパラメーターを拒否します。署名済みの値と処理される値を比較します。

共有URIパーサーは、値をエンコードしたままパラメーター名をデコードするようになりました。

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

名前がデコードされると、%53AMLResponseとSAMLResponseはどちらも生のビューでSAMLResponseの下に現れ、新しい重複チェックがリクエストを拒否します。

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

エンドポイントは処理中のメッセージを検証側に渡すようになりました。

--- 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は署名済みの値をデコードし、executeに渡された値と比較します。処理される値と異なる署名済みメッセージは、重複チェックを回避しても失敗します。RelayStateも同じ比較を受けます。rejectRepeatedRedirectParametersはbasicChecksとSamlServiceのリダイレクトバインディングからも呼ばれるため、両方のリダイレクトエンドポイントが処理前に重複を拒否します。

このコミットは、変更対象のリダイレクトバインディングのチェックを2か所とも修正します。SAMLEndpointのブローカーエンドポイントと、SamlServiceのIDプロバイダーエンドポイントです。POSTバインディングとartifactバインディングはこの方法でクエリ文字列を読まないため、変更されていません。

侵害されたかどうかを確認するには？

2026年11月5日時点で、CVE-2026-117691に関する公開された侵害指標はありません。

公開された説明から得られる手がかりは1つです。ブローカーエンドポイントへのリクエストに、パーセントエンコードされたSAMLパラメーター名が含まれる場合です。リバースプロキシがクエリ文字列を保存している場合は、アクセスログを検索してください。

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

ログがクエリ文字列をデコードして保存している場合は、代わりに1つのリクエストにSAMLResponseが2つあるものを探してください。

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

ヒットは手がかりであり、証明ではありません。正規のクライアントが名前をパーセントエンコードしたり、パラメーターを重複させたりする可能性があります。リクエスト全体とIDプロバイダーのログで確認してください。クエリ文字列が記録されていない場合、失敗した試行は痕跡を残さないことがあるため、ヒットがないことは試行がなかったことを証明しません。

年表

• 2026-10-26: Red Hatへの報告。
• 2026-11-05: CVE-2026-117691の公開。
• 2026-11-05: 修正コミットcbda2bfd35がkeycloak/keycloakに到達。
• 2026-11-05: Keycloak 26.8.2の公開。
• 2026-11-05: 確認時点で公開された概念実証もCISA KEVへの登録もなし。

報告から公開までの間に10日が経過しました。修正コミットはCVEレコードの公開から1時間52分後に到達し、26.8.2リリースはその41分後に続きました。

よくある質問

これはKeycloakがブローカーではなくSAML IDプロバイダーとして動作する場合にも影響しますか？

アカウント乗っ取りの影響は、Keycloakが外部IDプロバイダーからの応答を消費するブローカーの経路にあります。同じコミットはSamlServiceのIDプロバイダーエンドポイントにあるリダイレクトバインディングのチェックも強化するため、修正は両方の経路を対象にします。

攻撃者にKeycloakアカウントは必要ですか？

いいえ。Keycloakアカウントが不要なため、Red Hatはこの攻撃を特権不要と評価しています。ただし攻撃者は、有効な署名済みリダイレクトバインディングメッセージを1つ取得するために、外部IDプロバイダーのアカウントを必要とします。

「Want Assertions Signed」は修正になりますか？

未署名の細工されたアサーションを拒否するため、露出は減ります。ただしIDプロバイダーとの信頼の取り決めを変え、プロバイダーがアサーションに署名する場合にしか機能しないため、26.8.2の代替にはなりません。

公開エクスプロイトはありますか？

2026年11月5日時点で、公開された概念実証も実際の悪用も確認されていません。CISAのAuthorized Data Publisher（ADP）レコードはExploitation: noneと記載しており、このCVEはKEVカタログにありません。

どのリリースで修正されますか？

Keycloak 26.8.2（2026年11月5日公開）です。26.6.8と26.4.17のバックポートはラベル付けされていますが確認時点で未公開で、Red Hat Build of Keycloakにはエラータがありませんでした。

Red Hat Single Sign-On 7は影響を受けますか？

いいえ。脆弱なコードが存在しないため、Red Hatは影響なしとしています。

参考資料

• Red Hat、「CVE-2026-117691」アドバイザリ、https://access.redhat.com/security/cve/CVE-2026-117691（2026年11月5日確認）。
• CVE Program、「CVE-2026-117691」レコード、https://www.cve.org/CVERecord?id=CVE-2026-117691（2026年11月5日確認）。
• 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（2026年11月5日確認）。
• keycloak/keycloak、「Verify the SAML redirect binding message that is processed」、コミットcbda2bfd35e2eb182942996832b819c35780b121、https://github.com/keycloak/keycloak/commit/cbda2bfd35e2eb182942996832b819c35780b121（2026年11月5日確認）。
• keycloak/keycloak、リリース「26.8.2」、https://github.com/keycloak/keycloak/releases/tag/26.8.2（2026年11月5日確認）。
• keycloak/keycloak、26.8.1のSamlProtocolUtils.java、https://github.com/keycloak/keycloak/blob/26.8.1/services/src/main/java/org/keycloak/protocol/saml/SamlProtocolUtils.java（2026年11月5日確認）。
• keycloak/keycloak、26.8.1のSAMLEndpoint.java、https://github.com/keycloak/keycloak/blob/26.8.1/services/src/main/java/org/keycloak/broker/saml/SAMLEndpoint.java（2026年11月5日確認）。
• keycloak/keycloak、26.8.1のKeycloakUriInfo.java、https://github.com/keycloak/keycloak/blob/26.8.1/server-spi/src/main/java/org/keycloak/models/KeycloakUriInfo.java（2026年11月5日確認）。
• keycloak/keycloak、26.8.1のUriUtils.java、https://github.com/keycloak/keycloak/blob/26.8.1/common/src/main/java/org/keycloak/common/util/UriUtils.java（2026年11月5日確認）。
• keycloak/keycloak、「CVE-2026-117691 SAML redirect binding signature bypass via percent-encoded parameter name」、issue 54714、https://github.com/keycloak/keycloak/issues/54714（2026年11月5日確認）。
• Keycloak、「Configuring a SAML identity provider」、サーバー管理ガイド、https://www.keycloak.org/docs/26.8.1/server_admin/#_identity_broker_saml（2026年11月5日確認）。
• Cybersecurity and Infrastructure Security Agency、Known Exploited Vulnerabilitiesカタログ、https://www.cisa.gov/known-exploited-vulnerabilities-catalog（2026年11月5日確認）。
• National Vulnerability Database、「CVE-2026-117691」、https://nvd.nist.gov/vuln/detail/CVE-2026-117691（2026年11月5日確認）。