2026年10月23日、国産のローコード開発ツール「プリザンター」のLDAP認証に、パスワードを正しく検証しないままログインを許す脆弱性CVE-2026-113438が公表されました。有効なログインIDを知っていれば、パスワード無しでそのユーザーとして入れるおそれがあります。対象は1.1.0.0から1.5.9.0までで、修正版は1.5.9.1です。本記事では、対象になる構成の見分け方、Authentication.jsonと稼働中の版を確かめるコマンド、Docker版とLinux版の更新手順を実装者の目線で整理します。記載内容は2026年10月27日時点の公開情報にもとづきます。
まとめ：LDAP認証のプリザンターは構成を確かめて1.5.9.1へ上げる
LDAP認証を使っていないプリザンターは対象外です。ローカル認証、SAML認証、パスキー認証、統合Windows認証、二段階認証は影響を受けないと開発元が明記しています。
対象になるのは、Authentication.jsonのProviderが「LDAP」か「LDAP+Local」の環境です。Linux版とDocker版でActive Directoryにつないでいるなら、真っ先に1.5.9.1へ更新してください。Windows版はDsProviderに「Novell」を指定している場合だけが対象です。
開発元はバージョンアップ以外の回避策を公開していません。すぐに上げられない場合は開発元へ問い合わせたうえで、ログイン画面に届く経路を社内に絞ってしのぎます。
10月23日公表のプリザンターLDAP認証回避の内容と影響を受ける範囲
開発元の株式会社インプリムは「プリザンターのLDAP認証における認証回避の脆弱性」の告知を出し、同じ日にJVNでも公表されました。修正はGitHubのPleasanter_1.5.9.1として配布されています。
CVE-2026-113438で起きることとCVSS v4.0基本値6.9の読み方
JVN#82312317では、CWE-304（認証処理内の重要な手順の欠如）に分類されています。特定の構成で細工されたリクエストを処理するとき、パスワードの検証が行われないという内容です。
通常のログイン操作では起きません。一方で、ログイン画面に到達できる第三者なら、特別な権限も準備も要らないと開発元は説明しています。乗っ取られたユーザーの権限で、登録された情報の閲覧・改ざん・削除が行われるおそれがあります。
CVSS v4.0の基本値は6.9、v3.0では6.5です。ベクトルは AV:N/AC:L/PR:N/UI:N で始まり、機密性と完全性への影響はどちらも「低」とされています。点数は中程度でも、ネットワーク越しにログイン不要で成立する点は見落とせません。ベクトルの読み方はCVSSv3のスコアの目安と計算式で確認できます。
2026年10月27日時点で、JVNと開発元の告知のどちらにも悪用の報告は載っていません。
1.1.0.0〜1.5.9.0で対象になる認証方式とLDAPサーバーの組み合わせ
対象の版はCommunity EditionとEnterprise Editionの両方です。1.5.9.0には修正が入っていないため、10月13日公開の最新版に上げたばかりの環境も対象に含まれます。開発元の告知をもとに、構成ごとの扱いを並べます。
| 動作環境 | DsProvider | 接続先のLDAPサーバー | 扱い |
|---|---|---|---|
| Linux（Docker版を含む） | Novellのみ指定可 | Active Directory | 対象 |
| Linux（Docker版を含む） | Novellのみ指定可 | 匿名バインドを許すOpenLDAP等 | 対象 |
| Linux（Docker版を含む） | Novellのみ指定可 | 匿名バインドを拒むOpenLDAP等 | 対象外 |
| Windows | Novell | Active Directory／匿名バインド可 | 対象 |
| Windows | null（既定値） | 種類を問わない | 対象外 |
Providerが「LDAP+Local」の場合、影響を受けるのはLDAP認証でログインするユーザーだけです。インプリムが運営するプライベートクラウドとPleasanter.netは、LDAP認証を設定していないため対象外とされています。
Linux・Docker・Windows版でDsProviderにより対象が分かれる理由
分かれ目は、LDAPとの通信に使うライブラリです。Authentication.jsonのマニュアルによると、DsProviderの既定値はnullで、「Novell」を指定するとNovell.Directory.Ldapを使います。Linux環境ではNovellしか指定できません。
つまりLinux版とDocker版のLDAP認証では、必ずNovellの経路を通る仕組みです。1.5.9.1のプロジェクトファイルには、Novell.Directory.Ldap.NETStandardの3.6.0が依存として書かれています。Windows版で既定のnullのまま動かしている環境が対象外なのは、この経路を通らないためと読めます。
JVNの記載は「Linux環境またはWindows環境でDsProviderにNovellを指定」とまとめていますが、意味は開発元の表と同じです。Linuxでは指定の有無にかかわらずNovellで動く、と押さえておけば読み違えません。
自社のプリザンターが対象かをAuthentication.jsonと版で確かめる手順
判断に要る情報は、認証方式の設定、稼働中の版、接続先LDAPサーバーの匿名バインドの扱いの3つです。どれも読み取りだけで確かめられます。
ProviderとDsProviderを設定ファイルから読み取るコマンド
LDAP認証の設定はLDAP認証を利用するのマニュアルのとおり、Authentication.jsonに書かれています。インストール先は環境に合わせて置き換えてください。
# Linux 版（公式手順の配置先 /web/pleasanter の例）：ファイルを探してから2項目を読む
sudo find /web/pleasanter -name Authentication.json -path "*Parameters*"
sudo grep -nE '"(Provider|DsProvider)"' /web/pleasanter/Implem.Pleasanter/App_Data/Parameters/Authentication.json
# Docker 版：アプリは /app に置かれる
docker compose exec pleasanter grep -nE '"(Provider|DsProvider)"' /app/App_Data/Parameters/Authentication.json
# Windows 版（PowerShell）
Select-String -Path C:\web\pleasanter\Implem.Pleasanter\App_Data\Parameters\Authentication.json -Pattern '"(Provider|DsProvider)"'
Providerがnullなら、この脆弱性の対象ではありません。「LDAP」か「LDAP+Local」なら次の版の確認へ進みます。Windows版でDsProviderが「Novell」でなければ対象外です。
deps.jsonやDLLのファイルバージョンで稼働中の版を確かめる方法
画面からは「ヘルプ」から「バージョン」を開けば版が表示されます。台数が多い場合や、画面に入れない運用担当が確かめる場合は、次のコマンドで版を読み取れます。根拠は1.5.9.1のプロジェクトファイルで、VersionとFileVersionがどちらも1.5.9.1という設定です。
# Linux 版：deps.json に "Implem.Pleasanter/版番号" が載る
grep -o '"Implem.Pleasanter/[0-9.]*"' /web/pleasanter/Implem.Pleasanter/Implem.Pleasanter.deps.json | head -1
# Docker 版：動いているコンテナのイメージとタグ
docker compose images pleasanter
# Windows 版（PowerShell）：DLL のファイルバージョン
(Get-Item C:\web\pleasanter\Implem.Pleasanter\Implem.Pleasanter.dll).VersionInfo.FileVersion
1.1.0.0以上かつ1.5.9.0以下なら対象です。Docker版でタグをlatestにしている場合、タグ名からは版が読めません。画面の版表示と突き合わせてください。
ldapwhoamiで接続先LDAPサーバーの匿名バインドの可否を確かめる
接続先がActive Directoryなら、この確認をせずに対象と判断して構いません。OpenLDAPや389 Directory Serverの場合は、匿名バインドを受け付けるかどうかで扱いが変わります。ldapwhoamiでバインドDNを付けずに単純認証を試します。
# -D を付けない単純認証＝匿名バインド。"anonymous" と返れば受け付けている
ldapwhoami -x -H ldap://ldap.example.local
# LDAPS の場合
ldapwhoami -x -H ldaps://ldap.example.local:636
「anonymous」と返った場合は、表の「匿名バインドを許すOpenLDAP等」に当たります。エラーで終わるなら匿名バインドは拒否されています。OpenLDAPではslapd.confのdisallow bind_anonで匿名バインドを止められますが、同じサーバーを参照する他のシステムが匿名で検索していると止まるので、影響範囲を洗ってから変えてください。
LDAPの仕様であるRFC 4513は、名前だけでパスワードが空のバインドを「無認証」の扱いとし、クライアントは空のパスワード入力を許すべきでないとしています。開発元は今回の原因を公表していないため本件と同じとは言えませんが、LDAP認証を自作するときに必ず押さえる仕様です。仕組みはLDAPの仕組みとActive Directoryとの違いで整理しています。
1.5.9.1への更新手順と更新できない間に取れる接続制限の手当て
更新の手順は、Docker版とサーバーへ直接配置した版で分かれます。どちらもデータベースとパラメータファイルの退避を先に済ませてから進めます。
Docker版はイメージを1.5.9.1に替えてCodeDefinerを流し直す
Docker版の更新手順は、停止、パラメータ用ボリュームの削除、CodeDefinerの実行、起動の順です。Docker Hubのimplem/pleasanterには1.5.9.1のタグが出ています。
# 0. app_data_parameters 内の json（拡張機能を使うならそのサブフォルダも）を退避しておく
docker compose down
# 1. compose が参照する版（.env の PLEASANTER_VERSION など）を 1.5.9.1 にしてから取得
docker compose pull
# 2. パラメータ用ボリュームを消す（プロジェクトディレクトリ名が pleasanter の例）
docker volume rm pleasanter_codedefiner_params_volume
# 3. CodeDefiner を実行（license の確認が出たら Y）
docker compose run --rm codedefiner _rds /l "ja" /z "Asia/Tokyo"
# 4. 起動
docker compose up -d pleasanter
起動後に前章の版確認を流し、1.5.9.1になったことと、LDAPユーザーでログインできることを確かめます。1.4.5以前から上げる場合はCodeDefinerのコマンドが変わるため、公式の別手順に従ってください。
Linux版とWindows版で直接配置した環境を1.5.9.1へ上げる流れ
Linux版の更新手順では、サービスを止め、既存の/web/pleasanterを/web/pleasanter_bkへ退避し、新しい版を展開します。パラメータはCodeDefinerのmergeで旧版から引き継ぎます。
sudo systemctl stop pleasanterで停止し、データベースをバックアップする- 新しい版を/web/配下に展開し、同じ版のParametersPatch.zipを解凍せずに置く
- Implem.CodeDefinerの中で
merge /b /web/pleasanter_bk /i /web/pleasanterを実行してパラメータを引き継ぐ - 続けて
_rdsを実行し、確認に「y」と答える sudo systemctl start pleasanterで起動し、ヘルプの「バージョン」で版を確かめる
Windows版はWindows版の更新手順に沿います。mergeでAuthentication.jsonが引き継がれたかは、更新後に前章のコマンドでProviderの値を読んで確かめると確実です。
更新までの間にログイン画面への経路を絞る手当てと更新後のログ確認
開発元は、バージョンアップが難しい場合は問い合わせるよう案内しています。JVNにも、開発元がワークアラウンドの適用を勧めており詳細は開発元に問い合わせる、と書かれています。手順が公開されていない以上、自己判断の設定変更より問い合わせを先にしてください。
開発元の回答を待つ間に取れるのは、攻撃の前提である「ログイン画面に到達できること」を崩す手当てです。インターネットに公開しているプリザンターなら、リバースプロキシやファイアウォールで接続元をVPNや社内のIPアドレスに限ります。社外からの利用が止まるため、期間を区切って周知してから行います。
更新後は、対象の期間にLDAPユーザーが見慣れない接続元や時間帯でログインしていないかを、Webサーバーのアクセスログで確かめます。個人データの閲覧や持ち出しが疑われる場合は、個人情報保護委員会への報告義務と速報の期限に当たるかの判断に進みます。
プリザンターの脆弱性対応で優先順位と1.4系からの移行を決める基準
同じプリザンターでも、構成によって急ぐべき度合いは大きく違います。ここでは対応の順番と、古い系列を使っている場合の判断を言い切ります。
Linux・Docker版でActive Directory連携かつ外部公開なら即日更新
最優先は、Linux版かDocker版でActive Directoryにつなぎ、ログイン画面をインターネットに出している環境です。対象の条件を全部満たすうえ、攻撃に要るログインIDは秘密の値ではなく、社内の多くの人が知っているからです。この組み合わせは当日中に1.5.9.1へ上げるか、上げられないなら当日中に接続元を絞ってください。
社内ネットワークからしか届かない環境は、次の定期作業を待たず週内に更新します。Windows版で既定のDsProviderのまま動かしている環境と、LDAP認証を使っていない環境は今回の対象外です。それでも1.5.9.0ではサイトの移動で権限が検証されない問題も直っているため、通常の更新の周期で1.5.9.1へ揃えるのが妥当です。
1.4系から上げるなら.NET 10への切り替えと合わせて計画する
1.4系を使っている環境は、修正版の1.5.9.1へ上げると実行環境も変わります。1.5.9.1は.NET 10向けにビルドされており、公式の手順書は、1.4系のDockerイメージに含まれる.NET 8のサポートが2026年11月10日に終わると注意しています。
つまり1.4系にとどまる選択は、今回の修正を受けられないうえ、11月10日以降は土台の.NETの保守も切れます。1.4系のまま様子を見るのは勧めません。サーバーへ直接配置した環境では、.NET 10のランタイムを入れる作業と検証環境での動作確認を、今回の更新と同じ計画に入れてください。
プリザンターのようなローコードツールは、現場が自前で立てたまま、版の管理者が決まっていないことがよくあります。ローコード開発のセキュリティリスクと対策で挙げている権限設計や野良アプリの棚卸しと合わせて、誰が版を上げるのかを決めておくと次の脆弱性で慌てません。外から届くサービスと導入製品の版をまとめて洗い出すなら、脆弱性診断・セキュリティ診断で公開範囲と版を点検すると、更新の順番を付けやすくなります。
プリザンターの脆弱性CVE-2026-113438対応でよく受ける質問と回答
今回の脆弱性の対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。
LDAP+Localで運用している場合、ローカルユーザーも危ないですか？
開発元の告知では、影響を受けるのはLDAP認証でログインするユーザーだけとされています。LDAP+Localは、LDAP認証に失敗したときにローカルユーザーとしてのログインを試す設定です。ローカルユーザーのパスワード検証は今回の対象外ですが、管理者権限を持つアカウントがLDAP側にあるなら、その権限で操作されるおそれがあります。構成にかかわらず、LDAPを使っている以上は1.5.9.1へ上げてください。
1.5.9.0に上げたばかりですが、もう一度更新が必要ですか？
必要です。開発元は1.5.9.0には修正が含まれていないと明記しています。1.5.9.0は10月13日、1.5.9.1は10月23日の公開で、1.5.9.1の変更点はLDAP認証の修正1件だけです。1.5.9.0からの更新なら機能面の差は小さいため、Docker版ならイメージの差し替えとCodeDefinerの実行で済みます。
二段階認証を有効にしていれば防げますか？
開発元は、メールやTOTPによる二段階認証は影響を受けない認証方式として挙げています。ただし、それはLDAP認証の代わりに二段階認証を使う場合の話ではなく、認証方式としての扱いです。LDAP認証と組み合わせた場合に今回の回避が防げるかは告知に書かれていません。二段階認証を頼りに更新を遅らせる判断はせず、1.5.9.1へ上げてください。
SaaSのPleasanter.netを使っていますが、何かする必要はありますか？
開発元の告知では、Pleasanter.netとプライベートクラウドはLDAP認証を設定していないため対象外とされています。利用者側で版を上げる作業はありません。自社サーバーに立てたプリザンターを別に持っている部署がないかは、この機会に確かめておくと安心です。
プリザンターから他のツールへ乗り換えるべきでしょうか？
今回の脆弱性だけを理由に乗り換える必要はありません。開発元は公表と同時に修正版を出しており、告知、JVN、GitHubのリリースで同じ内容を確かめられます。乗り換えを考えるなら、脆弱性の有無より、更新を誰がどの周期で行えるかで決めるべきです。ツールの比較はローコードツールの比較と選定基準で整理しています。
関連記事
- ローコード開発のセキュリティリスクと対策｜権限設計・野良アプリ・発注時の確認項目：ローコードツールを安全に運用するための体制と確認項目です。
- ローコードツールとは？用途別の比較と選定基準・スクラッチ開発との使い分けを解説：プリザンターを含むツールの選び方を整理しています。
- LDAPとは？仕組み・Active Directoryとの違いと認証実装をコード付きで解説：バインドの仕組みとLDAP認証の実装を確認できます。
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：認証を突破された後の被害を抑える実装の手順です。
- 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：社内で動くツールをまとめて点検する際の進め方です。
