プリザンターのLDAP認証で認証回避｜1.5.9.1への更新と構成確認

国産のWebデータベース・ローコード開発基盤「プリザンター」をLDAP認証で運用している場合は、設置OS、Authentication.jsonの設定、接続先LDAPサーバーの3点を組み合わせて影響を判断する必要があります。株式会社インプリムとJVNは2026年10月23日、特定構成でパスワードを正しく検証しないままログインを許可する認証回避の脆弱性を公表しました。CVEはCVE-2026-113438、修正版は同日公開の1.5.9.1です。

この問題は通常のログイン画面操作だけで発生するものではありません。しかし、ログイン画面へ到達できる第三者が細工したリクエストを送れば、特別な権限を持たなくても、有効なログインIDを使って正しいパスワードなしにログインできる可能性があります。侵入後にできることは、その利用者へ与えられた権限に左右されます。登録情報の閲覧だけでなく、改ざんや削除へ至るおそれもあるため、LDAP利用環境は構成確認と更新を優先してください。

最初に確認したい結論

• プリザンター1.1.0.0から1.5.9.0までが対象で、1.5.9.1以降に修正が含まれる
• LDAP認証を使うすべての環境が同じ条件で影響するわけではなく、OS・DsProvider・LDAPサーバーの組み合わせを確認する
• Linux環境はDocker版を含み、Active Directoryまたは匿名バインドを許可するLDAPサーバーとの組み合わせが該当する
• WindowsでもDsProviderにNovellを明示した環境は同じ条件で該当する
• 更新後は正しいパスワードで入れることだけでなく、誤ったパスワードや不正な入力が拒否される「負の試験」を行う

影響は三つの設定の組み合わせで決まる

JVN#82312317による対象バージョンは1.1.0.0から1.5.9.0までです。ただし、バージョンだけで該当と断定するのではなく、LDAP認証を実際に使っているか、その実装経路と接続先の設定が条件に合うかを確認します。

開発元のプリザンターのLDAP認証における認証回避の脆弱性では、Authentication.jsonのProviderが「LDAP」または「LDAP+Local」の環境をLDAP利用環境として確認するよう案内しています。「LDAP+Local」の場合、影響を受けるのはLDAP認証でログインする利用者です。

プリザンターの構成	接続先	判定
LinuxまたはDocker	Active Directory	影響あり
LinuxまたはDocker	匿名バインドを許可するOpenLDAP等	影響あり
WindowsでDsProviderがNovell	Active Directoryまたは匿名バインドを許可するLDAP	影響あり
上記構成	匿名バインドを拒否するOpenLDAP等	対象外
WindowsでDsProviderが既定値のnull	開発元の表に示された接続先	対象外

ローカル認証、SAML認証、パスキー認証、メールまたはTOTPによる二段階認証、統合Windows認証は、開発元資料では本脆弱性の影響を受けない認証方式として示されています。ただし「二段階認証を使っているからLDAP構成の確認は不要」と自己判断せず、実際にどのProviderとログイン経路が利用者へ提供されているかを設定から確認してください。

通常のログイン試験では問題を見つけられない

開発元の説明では、通常のログイン画面操作では問題は発生せず、通常は送信されない形に細工したリクエストを認証処理へ送った場合に、サーバー側の検証不備とLDAPサーバー側の動作が重なって認証成功と判定されます。つまり、正しいIDとパスワードでログインできることだけを確認する正常系試験では、脆弱性の有無や修正の反映を判断できません。

JVNはこの問題をCWE-304「認証処理内の重要な手順の欠如」に分類し、CVSS v4.0の基本値を6.9、CVSS v3.0の基本値を6.5としています。数値は最大ではありませんが、ネットワーク越しに認証前から成立し、利用者操作も不要という評価条件です。管理者や業務責任者など高い権限のログインIDが推測・把握されていれば、業務データへの影響は大きくなります。

対応は資産判定から更新後の否定試験まで行う

1 稼働版と認証設定を確定する

まず、管理画面の表示だけでなく、各ノードやコンテナで実際に稼働するプリザンターの版を確認します。ロードバランサー配下の複数ノード、待機系、検証環境、古いDockerイメージが別々の版を使っていないかも対象です。Authentication.jsonではProviderとDsProviderを確認し、接続先がActive Directoryか、OpenLDAPや389 Directory Serverで匿名バインドを許可しているかをLDAP管理者と照合します。

確認結果は「LDAPを使っている」と一行で残すのではなく、稼働版、OS、コンテナの有無、Provider、DsProvider、LDAP製品、匿名バインドの可否、公開入口を記録します。今回の脆弱性は組み合わせ依存なので、この記録が更新優先度と完了確認の根拠になります。

2 1.5.9.1以降へ更新する

該当環境は1.5.9.1以降へ更新します。1.5.9.0は2026年10月13日公開ですが、この修正を含まないと開発元が明記しています。「最新版に近い」「10月に更新した」という記録だけでは不十分で、末尾まで含めて1.5.9.1以上かを確認してください。Community EditionとEnterprise Editionの双方が対象です。

更新前には設定とデータベースのバックアップ、現在のアーティファクト、停止時間、切り戻し条件を用意します。複数台なら一台または少数系で先に更新し、ログイン、一覧、検索、更新、ファイル、通知、APIなど自社が使う主要経路を確認してから範囲を広げます。一般的な段階反映と完了記録は「緊急パッチを安全に適用する実務ランブック｜資産確認からロールバックまで」で整理しています。

3 認証の負の試験を固定する

• 有効なIDと正しいパスワードは成功する
• 有効なIDと誤ったパスワードは必ず失敗する
• 空値、欠落、想定外の形式を含む入力は失敗し、サーバーエラーや認証成功にならない
• 無効化済み・退職済み・ロック済みのLDAPアカウントはログインできない
• LDAP+Localでは、両方の経路で意図した利用者だけが認証される

試験は本番の実利用者パスワードを使わず、専用アカウントと隔離した環境で行います。脆弱性を再現する細工済みリクエストの作成方法は公式資料に公開されていないため、推測した攻撃手順を本番へ送らないでください。更新の確認は、修正版が全ノードで稼働していることと、認証失敗が期待どおり処理されることの両方で行います。

認証の正常系と異常系を分けて検証する考え方は、2026年10月21日に確認した「Apache Tomcatで認証回避と通信混在の脆弱性！9系から11系まで更新判断」でも扱っています。同記事はTomcat固有の別件であり、対象製品や修正版はプリザンターと異なりますが、誤った資格情報が確実に拒否されることを試験する点は共通します。

更新前後のログで何を確認するか

公表資料は実環境での悪用確認を説明していません。そのため、本記事では「悪用なし」とは断定せず、状況を不明として扱います。該当構成だった場合は、ログ保持期間の範囲で、普段使われない送信元からのログイン成功、短時間に多数の認証失敗と成功が混在する動き、管理者や高権限IDへのアクセス、ログイン後の大量閲覧・変更・削除、設定変更を確認します。

プリザンターのアプリケーションログだけでなく、リバースプロキシ、WAF、ロードバランサー、LDAPまたはActive Directoryの認証ログも同じ時刻軸で確認します。ただし、パスワード検証が省かれたことを過去ログだけで完全に証明できるとは限りません。成功ログに必要な項目が残っていない、プロキシで送信元が集約される、保持期間を過ぎている場合は、その限界を対応記録へ残します。

更新できない場合は開発元へ相談する

開発元は、運用上の事情で更新が難しい利用者に個別の対応方法を案内するとしています。公開資料に具体的なワークアラウンドは記載されていないため、推測で設定値を変更して対応済みにしないでください。公開入口の制限、LDAPログインの一時停止、影響する利用者の権限縮小などはリスクを下げる候補ですが、業務要件や認証経路へ影響します。開発元サポートとLDAP管理者を交えて判断し、期限付きの暫定措置として扱います。

開発元によれば、同社のプライベートクラウドとPleasanter.netはLDAP認証が未設定で、利用者側の対応は不要です。自己ホスト環境や個別構築環境とSaaSを混同せず、自社がどの提供形態を使っているかを契約・構成情報で確認してください。

確認日時と判断の限界

本稿は2026年10月23日16時台（日本時間）に、JVNと株式会社インプリムの公開情報を確認して作成しました。初回公表日と修正版1.5.9.1の公開日はともに10月23日です。実環境での悪用状況、具体的な攻撃リクエスト、公開資料にない暫定設定は推測していません。今後、悪用確認や追加の修正版、調査方法が公開された場合は、初回情報と区別して再評価する必要があります。

今回の要点は、製品名やLDAP利用の有無だけで一律判断しないことです。稼働版、OS、DsProvider、LDAPサーバーの組み合わせを確定し、該当すれば1.5.9.1以降へ更新し、正しい入力が通ることと不正な入力が拒否されることを両方確認してください。