Chartbrewのジョブ管理画面に認証欠落 v5.2.3への更新と公開経路の点検

セルフホスト型のデータ可視化ツールChartbrewで、バックグラウンド処理の管理画面をログインせずに開ける問題が見つかっています。CVE-2026-86005です。RedisとBullMQを有効にした構成で、Chartbrewのバックエンドにある /apps/queues に到達できる場合、未認証の第三者がジョブの内容やログを読んだり、条件によっては処理の状態を変えたりできます。運用担当者はこの経路を遮断したうえで、修正済みのv5.2.3以降へ更新し、管理用の認証が実際に効くことを確認してください。

Chartbrew：BullMQ管理画面の認証欠落に関する勧告は9月6日付で、影響版として5.2.2を明記し、修正版を5.2.3としています。CVE Program：CVE-2026-86005の公式レコードは日本時間11月7日（UTCでは11月6日）に公開され、影響範囲を5.2.3未満、深刻度をCVSS v4.0で9.3（Critical）としています。CVEレコードの公開日は修正版が初めて配布された日ではありません。勧告は調査対象だった開発ブランチにも同じ問題があったとしています。古い版や独自ビルドを使っている場合は、勧告に列挙された版だけで安全と判断せず、管理ルートに同じ認証の欠落がないか確認します。開発元が公開した再現手順は、実際の運用環境で悪用されたことを示す報告とは区別します。

公開グラフとは別にバックエンドへの経路を調べる

ChartbrewはデータベースやAPIの情報をグラフにし、ダッシュボードにまとめます。問題の対象は、そのグラフを閲覧する画面ではなく、更新やスナップショット作成などのジョブを管理するBull Boardです。問題のある実装では、ChartbrewがExpressの管理ルーターを認証なしで登録していました。手前でContent Security Policyヘッダーを付けても、要求を送った人の本人確認や管理権限の確認は行われません。通常の画面でログインが求められることを確かめても、この経路の検査にはなりません。

影響を受けるかは、稼働版、RedisとBullMQの有効化、ネットワークからの到達性を組み合わせて判断します。インターネットからの接続だけでなく、管理用サブネット、別チームのワークロード、検証環境からアクセスできる経路も確認します。社内向けのホストでも、管理機能を使う必要のない端末やサービスから届けば、アクセスの前提を満たします。反対に、到達を独立した境界で止めていたなら、その境界を越えない位置から同じ操作はできません。

最初に調べるのは、Chartbrewのフロントエンドを公開しているホストと、APIを配信するホストが同じかどうかです。ロードバランサーがパスで振り分ける構成なら、公開URLのどの部分がバックエンドへ転送されるかを設定から追います。別ホストであれば、公開画面を通らずAPIホストに到達する経路も調べます。コンテナのポートをホストに公開している場合は、プロキシの制限を通らずに同じバックエンドへ着く可能性があります。TLSの有無と、どの利用者に到達を許すかは別々に確認します。

Redisが外部から直接見えなくても、ChartbrewがRedisに接続しており、Bull Boardだけが外部から見えるなら確認が必要です。要求を受けるのはRedisのポートではなく、ジョブ管理のWebルートだからです。運用台帳に「Redisは非公開」とだけ記録している環境では、ChartbrewのAPI側の入口も併記し、どこで管理機能の利用者を制限するかを特定します。

ジョブの入力と処理の状態で影響を分ける

開発元の勧告は、グラフやダッシュボードの更新、MongoDBのスキーマ情報更新、スナップショットに関係するキューを挙げています。閲覧で何が見えるかは、ジョブの入力、結果、エラーに何を格納しているかで変わります。内部のチームや接続先を識別する値、処理時刻、再試行回数が見えるケースと、利用者データが入力やログに入っているケースでは、調査対象を分けます。公開情報だけでは、すべての構成で接続先のパスワードやデータベースの中身が見えたとは言えません。

操作による影響も別に評価します。利用可能な管理操作はBull Boardの版やジョブの状態によって異なります。失敗ジョブの再試行や削除が可能なら、予定外の更新が発生したり、処理されるはずの更新が抜けたりします。キューの一時停止が可能な構成では、画面は正常に開けてもグラフが更新されないことがあります。監視では、フロントエンドの生存確認に加え、代表的なデータ更新の時刻とジョブが進んだ時刻を照合します。外部公開されたグラフの誤りや遅れを先に検知できる場合があります。

遮断してから修正版と管理用の認証を用意する

すぐに更新できない場合は、管理画面が不要な公開入口で /apps/queues とその配下をプロキシで拒否します。画面の入口だけを止め、関連するAPIが配下で通ったままにならないようにします。転送先へ直接接続できる場合は、到達元を絞るなど別の制御も必要です。これは運用上の一時策です。URLをメニューから隠すだけでは接続を止められず、管理機能だけのために業務用の公開画面やAPIをすべて停止する必要があるとも限りません。どの経路を止めたかを記録し、後で再確認します。

Chartbrew：v5.2.3のリリースノートではBullMQ管理画面にHTTP Basic認証を追加し、CB_BULLMQ_USERNAME と CB_BULLMQ_PASSWORD を新設しています。ローカルの .env を利用する導入では未設定時に認証情報を補う動作が示されています。コンテナや構成管理を使う本番では自動生成に依存せず、管理している設定から専用の値を渡し、稼働するプロセスへ反映されたことを確認します。パスワードをイメージや履歴へ記録せず、管理者だけに配布します。Basic認証を利用する入口では通信をTLSで保護します。

複数のレプリカを持つ場合は、稼働中のイメージやバイナリの版を一台ずつ確認します。配備の途中で旧版が振り分け先に残っていると、同じURLを確認しても結果が揺れます。また、設定を書き換えただけで旧プロセスが動き続ける場合は、実行環境の方法に従って置き換えます。更新で戻りが必要になった場合も、旧版への切り戻しと管理経路の遮断解除は連動させません。業務画面を戻す間も管理面の到達制限を残します。

リリースノートには、旧方式で署名されたセッショントークンの扱いを変更する記載もあります。ジョブ管理のBasic認証と通常のChartbrew利用者のログインは、更新後にそれぞれ確認します。もし管理画面だけが使えなければ、通常のログインが成功したことを復旧判定に使わず、管理側の認証情報やプロキシの設定を調べます。逆に、管理画面が開けても通常の利用者がダッシュボードを閲覧できなければ、利用者向けの復旧は終わっていません。

認証の失敗と成功を経路ごとに確認する

Chartbrew：管理画面の認証を追加した修正差分では認証情報が未設定の場合に503を返し、設定済みでも要求に有効な資格情報がない場合は401を返します。これはアプリの認証処理に届いた場合の挙動です。公開入口で先に拒否する運用では、そのプロキシ側の拒否結果で構いません。503が出た場合は管理画面を開けないという点では閉じていますが、認証設定が完了したことにはなりません。資格情報を設定しているはずなら、対象レプリカの実行環境を確認します。

検証は、アクセスを許可しない場所と管理用の場所の両方から行います。公開入口では資格情報を付けない要求で管理画面も配下の管理APIも表示されないこと、管理経路では資格情報なしと誤った資格情報が拒否されることを確認します。続いて正しい資格情報で管理画面が表示され、閲覧専用の確認ができることを確かめます。ブラウザーが直前のBasic認証を再送する場合があるので、未認証の確認は認証情報を持たない別のクライアントで行います。

認証が通らないときは、資格情報の入力ミスだけでなく、手前のプロキシが Authorization ヘッダーをバックエンドへ渡しているかも確認します。上流で別の認証を使う構成では、どの段で拒否されたかを応答とログから分けます。認証を通すために公開側の制限を外すのではなく、許可済みの管理経路で検証します。本番でジョブの削除やキューの停止を試す必要はありません。書き込み操作まで確かめる場合は、破棄できるジョブを置いた隔離環境で行います。

過去に開いていた時間帯を確認する

修正は今後のアクセスを止めますが、過去に未認証でアクセスできたかどうかは別の調査です。公開経路があった場合は、稼働版と設定の変更履歴から、RedisとBullMQが有効で管理ルートへ到達できた期間を絞ります。その範囲で、ロードバランサーやプロキシのアクセスログを保全し、管理画面と配下への要求を探します。バックエンドに直通できた構成では、公開プロキシのログだけでは足りません。アプリや接続元を記録する別のログがあるかを確認します。

アクセスが見つかった場合は、時刻、接続元、HTTPメソッド、パス、応答結果を記録し、既知の管理作業と照合します。表示が成功したことだけでは、どのデータが読まれたか、ジョブが変更されたかまでは確定しません。ジョブの履歴や再試行、削除、更新予定のずれが残っていれば、アクセス時刻と突き合わせます。メソッドだけで操作の成否を断定せず、アプリ側で観測できる状態の変化も確認します。未保存のログや保存期間を過ぎた区間は、調査できた範囲と分けて記録します。

機密値が入力やログに含まれていたと確認できた場合は、影響を受けた連携先や認証情報の範囲を絞り、失効や交換を検討します。ジョブの再実行が必要な場合も、欠けた処理を特定してから行い、正常に完了した処理を重複して実行しないようにします。運用上の完了条件は、全レプリカの更新、不要な経路からの拒否、許可済み管理者の閲覧、通常のデータ更新の確認です。過去のアクセス調査が必要な環境では、その結果も別に残します。