Hinemosの管理者パスワード変更に脆弱性：修正版のリリース番号とALL_USERSを確認

Hinemosは、ITシステムの監視や定期ジョブなどの運用をまとめて管理するソフトウェアです。業務アプリの一般利用者向けというより、サーバー運用、監視、バッチ処理を担当するチームに関係します。今回の更新先はマネージャです。エージェントの版だけを見て対応済みとは判定できません。

本件は、誰でも未認証で管理者になれるという説明ではありません。JVNが示す条件は、一般ユーザーへ割り当て可能な特定権限を持ち、パスワード変更APIへアクセスできることです。開発元はその権限を「アカウント－変更権限」と説明しています。従来の初期設定では全ユーザーが所属するALL_USERSロールにも付いていたため、「一般ユーザーだから管理者操作はできないはず」という思い込みを点検する必要があります。開発元の告知

編集上は、対象版を利用し、運用委託先や複数部門の一般アカウントがある環境を優先して棚卸しすることを勧めます。これは構成に基づく優先順位であり、そうした環境で被害が発生したと確認できたわけではありません。

重大度と対象条件の出典はJVN、修正提供日は開発元告知です。今朝の記事化は公表翌日の解説です。一般アカウントから管理者への境界に関わるため、CVSSの数字だけで対応を先送りせず、自社のアカウントと到達範囲を合わせて判断してください。

上の影響範囲はJVNの列挙です。それより古いサポート終了版も影響する可能性があるため、表にないことを安全の証拠にはしません。パッチの前提版・適用順序は同梱READMEで確認し、たとえば7.1.0に7.1.2用の累積パッチを無条件で直接適用できるとは考えないでください。

パッチ名は開発元告知、OSS資材は7.2.0_2・7.1.2_2・7.0.4_2で確認できます。表はEL8向けの例で、OSに合わないRPMを選んではいけません。7.2にはEL8・9・10、7.1と7.0にはEL7・8・9向けが公開されています。Windowsなど表にない配布形態は、対応資材を契約窓口へ確認してください。

今回の見落としやすい点は、製品表示の7.2.0という数字が変わらなくても、RPMのリリース番号が「2」になることです。パッチ方式では製品版だけでなく適用履歴が根拠になります。更新資材をダウンロードした事実と、稼働マネージャに修正が入った事実を分けて記録しましょう。

認証は「誰か」を確認すること、認可は「その人が、その相手に、その操作をしてよいか」を判定することです。今回の問題は後者にあります。「アカウントを変更できる」という権限だけで、より強い管理者のパスワードまで変更できる状態だった、と考えると分かりやすくなります。

この区別は公式告知の修正後の仕様に基づきます。修正リリースには管理者ロールや所属ユーザーへの変更制限も含まれます。7.2のリリースノートなどで、自社のアカウント管理手順に関わる変更を確認してください。ログインが成功しただけでは、権限境界の確認にはなりません。

11月4日の修正版パッケージで新規導入した場合、ALL_USERSの初期権限は「リポジトリ－参照」だけになります。必要な監視・ジョブなどの操作は役割に応じて別途付与する設計です。一方、既存環境を更新しても、設定済みのロール権限は自動的には書き換わりません。公式の初期権限変更案内

運用上は「修正を入れる担当」と「どの役割に何を許可するか決める担当」を分けると、判断が整理できます。全員の権限を一括で外す前に、日常の監視やジョブ操作、アカウント管理に必要な操作を一覧化してください。権限を絞ることで通常業務を止めると、慌てて全員を管理者にするような逆効果の対処につながります。

1. 1稼働マネージャごとに、製品版、パッケージのリリース番号、OS、累積パッチ履歴、保守契約の有無を整理する。エージェントの情報と混ぜない。
2. 2公式告知から自分の系列の資材と適用手順へ進む。旧版からの前提更新、インストール先、停止・再起動条件を確認する。
3. 3設定と内部DBのバックアップ、復元方法、作業時間帯、監視停止中の代替確認を準備する。これは本記事の運用上の推奨であり、一律のコマンド手順ではない。
4. 4検証環境で適用する。累積パッチのREADME、または該当系列の公式アップデート手順に従い、初回インストールと更新を取り違えない。
5. 5本番へ適用後、対象マネージャの適用履歴・稼働状態を確認する。パッケージを置いただけで対応済みにしない。
6. 6監視・通知・ジョブの通常動作と、担当者による正規のアカウント管理を確認する。権限境界の検証は隔離した検証環境のテストアカウントで行い、本番管理者のパスワードを試しに変更しない。
7. 7完了記録に資材名、対象、確認者、日時、残件を残す。修正適用と、既存ロールを最小化する追加改善を別欄で管理する。

公式の7.2向けREADMEは、既存環境を同一バージョンのリリース番号2へ更新する手順と、インストール先の指定を示しています。7.1・7.0利用者は上記の各リリースページから該当手順へ進んでください。本記事は各環境の作業指示書を置き換えるものではありません。

開発元の軽減策は、「アカウント－変更権限」を業務上必要なユーザーだけが持つ状態にすることです。ALL_USERSだけでなく他のロールと所属者も確認します。別のロールから同じ権限を得ていれば、一か所の変更だけでは狙った状態になりません。通常保守終了版には修正資材を提供しないとされているため、軽減策と並行して移行の計画が必要です。公式の軽減策

ただし、権限の見直しは脆弱なプログラムを修正するものではありません。その権限を残す一般ユーザーについてリスクを認識し、管理APIへ接続できる範囲や、不要になったアカウントも合わせて確認することを勧めます。ネットワーク制限だけで修正の代わりになるとは扱わず、誰がどの権限を持つかを記録してください。

利用者側は、自分のアカウントへ管理者ロールを追加して解決しようとせず、パスワード変更や業務操作に問題があれば運用担当へ連絡してください。身に覚えのない管理者パスワード変更や権限変更がある場合、更新完了とは別に、社内のインシデント対応手順でログ保全と調査を進めます。これは一般的な調査観点であり、本件固有の攻撃痕跡や被害発生を示すものではありません。

Hinemos対応記録シート（TXT）に確認結果を残せます。空欄の記録用教材で、実環境の診断や自動判定は行いません。判断の基本は脆弱性の対象判定と修正確認も参照してください。

確認日：2026年11月5日朝JST。JVN、開発元告知、公式GitHubリリースと配布資材名を照合しました。Hinemos実機での適用・権限試験は未実施です。本文の確認手順は運用提案であり、成功結果の報告ではありません。