社内の業務アプリを、会社のアカウントで使っている。そのログイン連携が今回の点検対象です。2026年10月23日、プリザンターの特定のLDAP認証構成で、正しいパスワードを知らない第三者が利用者になりすませる脆弱性CVE-2026-113438が公表されました。すべての利用環境が対象ではないため、認証方式、動作環境、接続先を順に確認します。
影響版は1.1.0.0〜1.5.9.0です。LDAP認証を使い、対象のOS・ライブラリとLDAPサーバーの組み合わせに該当する場合は、運用担当へ早急に更新を依頼してください。「今月更新した」「ログイン画面ではパスワード必須だった」だけでは、修正確認になりません。
開発元インプリムの告知とJVNを2026年10月23日16時前後（日本時間）に確認しました。JVNの新着一覧での公表時刻は同日15時。修正版1.5.9.1のGitHubリリースの公開時刻は14時08分44秒です。脆弱性を再現する攻撃試験や、利用者の本番設定の変更は行っていません。
プリザンターとは。なぜ業務データの確認が必要なのか
プリザンターは、表形式の情報管理などをWebアプリにする国産のノーコード・ローコード開発ツールです。ExcelやAccessで扱っていた業務を移す用途もあり、組織によって管理するデータは異なります。製品名だけでなく、「どの部署のどの台帳が入っているか」まで確認すると、影響する情報と担当者を把握できます。
LDAPは、組織の利用者情報を管理するディレクトリーとやり取りするための仕組みです。プリザンター自身に登録したパスワードで認証するローカル認証とは違い、Active Directoryなどと連携して本人確認を行います。今回の問題は、こうした連携の一部の構成にあります。
何が起こる？ 強いパスワードだけでは防げない理由
JVNが示す影響は、有効なログインIDを知る第三者が、パスワードなしでその利用者としてログインできる可能性です。その利用者の権限で、登録情報の閲覧・改ざん・削除につながり得ます。すべてのアカウントが自動的に管理者になる、という説明ではありません。
開発元は、通常のログイン画面操作ではなく、細工されたリクエストに対するサーバー側の検証に不備があると説明しています。画面側で入力を必須にしていても、サーバーが受け取った内容を正しく検証しなければ本人確認は成立しません。パスワードの長さを増やすだけでは、この認証処理の欠陥を修正できません。
LDAPの「バインド」は接続時に認証状態を確立する操作です。匿名バインドを受け入れたことと、指定された利用者の正しいパスワードを検証できたことは同じではありません。ここは仕組みを理解するための説明で、攻撃用のリクエスト形式や再現コードは掲載しません。
| 確認項目 | 今回の情報 |
|---|---|
| 識別子・分類 | CVE-2026-113438／CWE-304（認証処理内の重要な手順の欠如） |
| 深刻度 | JVN掲載のCVSS v4.0は6.9、v3.0は6.5。版の違うスコアを混同しない |
| 悪用の前提 | 対象構成のログイン機能へ到達でき、有効なログインIDを知ること |
| 実悪用の状況 | 確認した開発元告知とJVNには、実悪用の確認に関する記載なし。未発生と断定しない |
| 編集上の優先順位 | 条件が合い、外部から到達できる環境や、重要情報にアクセスできるアカウントがある環境を優先して対応 |
CVSSは技術的な深刻度を表す共通指標で、被害が起きる確率ではありません。スコアの数字だけで更新を後回しにせず、実際の公開範囲とアカウント権限を合わせて判断します。
対象判定は3段階。Linuxだから全件対象、ではない
まずAuthentication.jsonの公式マニュアルと運用中の設定を照合します。ProviderがLDAPまたはLDAP+Localなら、LDAP認証の経路を調べます。LDAP+Localでは、今回の対象はLDAP認証でログインする利用者です。設定ファイルには接続先や同期用資格情報も含まれ得るため、ファイル全体を外部のLLMへ渡さないでください。
| 段階 | 見るもの | 判断 |
|---|---|---|
| 1. 版 | 稼働しているプリザンターの製品版 | 1.1.0.0〜1.5.9.0か。1.5.9.1は修正版 |
| 2. 認証経路 | Providerと、実際に利用者が通るログイン方式 | LDAP／LDAP+Localなら次の組み合わせ表を確認 |
| 3. 構成 | OS、WindowsのDsProvider、LDAPサーバー種別・匿名バインド設定 | 次の表で判定。不明な設定を「対象外」に置き換えない |
以下は開発元が公開した組み合わせを整理した表です。影響版でLDAP認証を利用していることが前提です。Community EditionとEnterprise Editionの双方が告知の対象です。
| プリザンターの環境 | Active Directory | 匿名バインドを許可するOpenLDAP等 | 匿名バインドを拒否するOpenLDAP等 |
|---|---|---|---|
| Linux（Docker版を含む） | 対象 | 対象 | 対象外 |
| Windows／DsProvider=Novell | 対象 | 対象 | 対象外 |
| Windows／DsProviderが既定値null | 対象外 | 対象外 | 対象外 |
Active Directoryは表の独立した列で判定してください。「匿名アクセスを止めたはずだからActive Directoryも対象外」と読み替えてはいけません。DsProviderは、Windowsで使うLDAPライブラリを選ぶ項目で、公式告知では1.3.41.0以降に追加、未指定時は既定値nullとされています。
開発元は、ローカル認証、SAML、パスキー、二段階認証（メール・TOTP）、統合Windows認証を影響を受けない認証方式として挙げています。ただし自社で複数経路を併用している場合は、方式名を1つ確認するだけで全利用者を対象外とせず、稼働中のログイン経路を確認してください。同告知では開発元のプライベートクラウドおよびPleasanter.netも、LDAP未設定を確認済みとして対象外としています。一般の自社クラウド上の構成まで対象外という意味ではありません。
修正版と日付。10月13日の更新では足りない
| 製品版 | 位置付け | 行動 |
|---|---|---|
| 1.1.0.0〜1.5.9.0 | 今回の影響版。構成条件を併せて判定 | 該当環境は1.5.9.1以降の対応版へ更新 |
| 1.5.9.0 | 2026年10月13日公開。本件の修正を含まない | 最近更新していても再確認 |
| 1.5.9.1 | 2026年10月23日公開。本件を修正 | 配布元と利用環境に合う更新手順を選ぶ |
上表はプリザンターの製品版です。.NETの版やコンテナの作成日時では判定できません。独自ビルドや販売元による修正の取り込みを使う場合も、バージョン文字列だけで修正済みとせず、配布元の証拠を保存します。今回、通常のOSパッケージのような修正バックポート提供は確認していません。
運用担当の手順：棚卸しから更新後確認まで
- 1所有者を決める：利用部署、運用担当、委託先、緊急連絡先をひも付ける。サービスが複数ある場合は環境ごとに記録する。
- 2読み取り専用で棚卸しする：稼働版、認証経路、OS、DsProvider、LDAP接続先の種別、匿名バインドの設定を確認する。秘密値は記録しない。
- 3更新を準備する：現行DB、パラメータ、拡張機能などの復元可能なバックアップを取り、利用者への案内、検証環境、作業時間、戻し方を決める。
- 4対応する公式手順で更新する：Windows・Linux・Dockerなどの違いを確認し、設定の引き継ぎと必要なDB更新を含めて実施する。
- 5更新後の実体を確認する：稼働版が修正版になったことを確認する。コンテナは取得したイメージと、動いているコンテナが対応していることも確認する。
- 6通常機能を確認する：許可されたテストアカウントで正しい認証が成功し、誤った認証が拒否されること、権限や業務画面が維持されていることを確認し、時刻と証拠を残す。
更新の実行手順は公式のバージョンアップ案内から、現在の版と環境に合うものを選びます。Dockerの手順ではパラメータや拡張機能の引き継ぎ、CodeDefinerの実行なども説明されています。「新しいイメージをpullした」だけで更新完了とはしません。なお、公式Docker手順のサンプル構成は試用向けで、本番運用を想定した構成ではないという注意があります。既存の本番構成を無条件に置き換えないでください。
正常・異常の通常ログイン試験は業務上の回帰確認です。今回の不備は通常の画面操作では発生しないと開発元が説明しています。修正の判定には、修正版の稼働と配布元の修正情報を併せて確認してください。
すぐ更新できないとき。暫定対策の限界
開発元は、更新が難しい場合には個別に相談するよう案内しています。JVNにもワークアラウンドへの言及はありますが、参照した公開資料には、その具体的な適用手順は示されていません。この記事から推測したLDAP設定の変更を、公式の回避策として紹介することはしません。
編集上の暫定提案としては、運用担当の承認のもとでログイン画面への不要な外部到達を減らす、必要な接続元だけに制限する、該当経路を一時的に止められるか検討する、といった対応があります。いずれも停止影響や代替ログインを確認してから実施するもので、ソフトウェアの不備自体を修正するものではありません。パスワード変更だけを更新の代わりにしないでください。
利用者がすること、運用担当が調べること
一般の利用者は、独自に認証回避を試さず、サービス名と普段のログイン方法を運用担当へ伝えます。パスワードをメールやチャットに添付する必要はありません。普段と違う更新通知や、心当たりのないデータ変更があれば、その時刻と画面を組織の所定の窓口へ報告します。
運用担当は、必要なログを保全したうえで、見覚えのないログインや情報の大量閲覧・改変、権限変更などを調査します。これは一般的な侵害点検であり、本CVEに特有の検知指標として確認されたものではありません。不審な記録があっても、それだけで今回の脆弱性が原因だとは断定せず、時刻、アカウント、アクセス元、操作内容を突き合わせます。
LLMに依頼するなら、秘密値を除いた棚卸しから
LLMには、判断に使える公開資料と、機密値を除いた台帳だけを渡します。LDAPのURL、組織の識別名、パスワード、Cookie、トークン、生の認証ログは貼り付けません。設定が取得できなければ、推測で安全と判定させず、確認先を出させます。
あなたは社内システムの防御点検を支援します。対象は許可を受けたプリザンター環境だけです。外部スキャン、攻撃再現、設定変更、更新の実行はしないでください。
参照資料：
https://pleasanter.org/news/vulnerability-update-20261023/
https://jvn.jp/jp/JVN82312317/index.html
https://pleasanter.org/ja/manual/setup/parameters/authentication-json/
渡す台帳は、環境の匿名ラベル、稼働製品版、OS、Provider、DsProvider、LDAPサーバー種別、匿名バインド可否、実際の認証経路、到達範囲、管理権限の有無、確認日時だけです。秘密値を求めないでください。
1. 影響版・認証方式・OS/ライブラリ・接続先の条件を別々に判定してください。
2. 各環境を「対象」「確認した条件では対象外」「未確認」に分け、判断根拠と出典を記載してください。不明は推測で埋めないでください。
3. LDAP+Localは利用者の認証経路を区別し、Active DirectoryをOpenLDAPの設定条件と混同しないでください。
4. 複数認証方式や独自ビルドなど資料だけで確定しない条件は、ベンダーへの確認事項として残してください。
5. 更新担当、バックアップ、停止影響、公式の環境別手順、稼働版の確認、通常ログインの回帰確認、戻し方を計画表にしてください。
6. 証拠が不足する場合は「更新確認未完了」としてください。通常ログイン試験だけで本脆弱性の不存在を保証しないでください。最後の承認と確認は運用担当が行います。LLMの表が埋まったことではなく、対象条件が分かり、修正版が稼働し、必要な確認結果が残ったことを完了条件にします。ほかの製品も含む管理の進め方は、脆弱性対応の基本記事を参照してください。