Hinemosの脆弱性：管理者のパスワードを一般ユーザーが変えられる権限不備と対処

2026年11月4日、NTTデータ先端技術の統合運用管理ソフトHinemosに、管理者のパスワードを一般ユーザーが変更できてしまう脆弱性が公表されました。CVE-2026-109849（JVN#46901199）です。原因は、全ユーザーが所属するALL_USERSロールに、初期状態で「アカウント－変更」権限が付いていたことにあります。この記事では、影響する版と修正版の対応、自社のHinemosが該当するかをrpmとREST APIで確かめる方法、更新しても自動では直らない権限設定の見直し方、保守が終わった6.x系の扱いを、2026年11月4日時点の公開情報で整理します。

まとめ：修正版の適用とALL_USERSロールの権限見直しを同時に行う

対応は2つで1組です。1つは、マネージャを修正版へ上げることです。7.2.0・7.1.2・7.0.4にはリリース番号2のRPMと、保守契約者向けの累積パッチが出ています。もう1つは、ALL_USERSロールから「アカウント－変更」権限を外すことです。

2つ目を忘れやすい理由があります。修正版は「管理者以外が管理者を変更する操作」を止めますが、既存環境のALL_USERSの権限は書き換えません。権限が残ったままだと、一般ユーザー同士で互いのパスワードを変えられる状態は続きます。

修正版が出ない6.x系は、権限の見直しだけが手段です。運用管理基盤は管理対象の全サーバーへ届く位置にあるため、今回を機に、Hinemosを含む社内の管理系システムの権限設計を点検するのも一案です。範囲の決め方に迷う場合は、脆弱性診断・セキュリティ診断で相談を受け付けています。

CVE-2026-109849の中身：パスワード変更APIとアカウント－変更権限の関係

Hinemos公式のお知らせとJVN#46901199の記述を、ソースコードと突き合わせて読みます。

一般ユーザーが管理者のパスワードを書き換えられた仕組みとAPIの権限

Hinemos 7.x系のマネージャはREST APIを持ち、クライアントの操作もこのAPIを通ります。AccessRestEndpoints.javaを見ると、他のユーザーのパスワードを変えるPUT /access/user_password/{userId}に求められる権限は、システム権限のAccessControl（画面上の「アカウント」）のMODIFYだけでした。操作する人が管理者かどうかは見ていません。

そしてALL_USERSロールには、初期状態でこの「アカウント－変更」が付いていました。ALL_USERSは全ユーザーが所属するロールです。結果として、ログインできる人なら誰でも、ADMINISTRATORSに所属する管理者のパスワードを書き換え、そのまま管理者としてログインできました。JVNの分類はCWE-266（不適切な権限の割り当て）です。

APIの実装そのものより、初期設定の権限の付け方に穴があった、と読むのが正確です。認可を「機能単位の権限」だけで判定し、「誰が誰を操作するか」を見ていない設計は、他の業務システムでも起きます。仕組みは認可バイパス（IDOR・権限昇格）の仕組みとサーバ側の実装対策で詳しく扱っています。

CVSS v3.0で6.5・v4.0で7.1となる評価の内訳と被害の広がり方

JVNのCVSS v3.0はAV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:Nで基本値6.5、v4.0は7.1です。ネットワーク越しに、低い権限（一般ユーザーのログイン）で、利用者の操作なしに成立し、完全性への影響が大きいという評価です。

数字は中程度ですが、私たちは急ぎの案件として扱います。Hinemosの管理者は、監視設定だけでなく、ジョブ機能で管理対象のノードにコマンドを流せる立場にあります。管理者を奪われることは、Hinemosが届く全サーバーへの足掛かりを渡すことに近いからです。逆に、元の管理者はパスワードを変えられた時点でログインできなくなるので、気付く手掛かりにもなります。スコアの各指標の読み方はCVSSv3のスコアの目安と計算式で確認できます。

修正版で追加された管理者ロールの境界チェックとソースコード上の変更点

GitHubの7.2.0_2のソース統合コミット（2026年10月31日）では、AccessControllerBean.javaのchangePassword・modifyUserInfo・deleteUserInfo・assignUserRoleに、新しいAccessTrustBoundaryValidatorの呼び出しが加わりました。操作者がADMINISTRATORSに属さないのに、対象がADMINISTRATORSのユーザーかロールなら拒否する、という判定です。

リリースノートの仕様変更（#7222433）の言い方では、ADMINISTRATORSに属さないユーザーは「アカウント－変更」権限があっても、ADMINISTRATORSのユーザーの変更・削除・パスワード変更と、ロールへの割り当て・解除ができません。一般ユーザーの変更と、本人による自分のパスワード変更は従来どおりです。

影響を受けるHinemosの版と修正版パッケージ・累積パッチの対応表

公式とJVNが挙げる影響範囲は、7.2.0、7.1.0〜7.1.2、7.0.0〜7.0.4、通常保守が終わった6.2.0〜6.2.2・6.1.0〜6.1.2・6.0.0〜6.0.3です。6.0より前の保守終了版も影響を受ける可能性がある、と開発元は説明しています。

7.0〜7.2系の修正版RPMと保守契約者向け累積パッチのファイル名一覧

公式のお知らせに載っている修正版を、系列ごとに並べました。チケット番号は#7022433・#7122433・#7222433です。

ファイル名は、累積パッチがpatch_manager_for7.2.0_20261104.zip、RPMがhinemos-7.2-manager-7.2.0-2.el9.x86_64.rpmの形です（7.2系・RHEL 9の例）。どれも末尾の「-2」がリリース番号で、同じ版のままリリース番号だけが上がる更新です。OSS版RPMはGitHubのv7.1.2_2やv7.0.4_2のリリースから入手します。Windows版とAmazon Linux 2023版のマネージャは、GitHubのリリースページによるとHinemosポータルの相談・見積依頼フォームからの問い合わせになります。

7.1.0・7.1.1と6.x系以前が置かれる状況と急ぎ度の違い

修正版が用意されているのは各系列の最終版（7.1.2・7.0.4）向けだけです。7.1.0や7.1.1、7.0.3以前で動かしている環境は、公開情報を読む限り、まず系列の最終版へ上げる段取りが要ります。具体的な順序は累積パッチ同梱のREADMEで確かめてください。

6.2・6.1・6.0系は修正版が出ず、権限の見直しによる軽減策だけが示されています。急ぎ度は「一般ユーザーのアカウントが何人分あるか」で決まります。管理者1人だけが使うHinemosなら、パスワードを奪う相手がいません。運用担当や協力会社など複数人のアカウントがある環境ほど、今週中に手を打つ対象です。

自社環境の確認手順：RPMの版とアカウント－変更を持つロールの洗い出し

確認は2段です。版が修正済みか、そして権限がどのロールに付いているかを見ます。

rpmコマンドでHinemosマネージャの版とリリース番号を確かめる方法

RHEL系にRPMで入れたマネージャは、パッケージ名とリリース番号で判定できます。

# Hinemosマネージャのパッケージ名・版・リリース番号を表示する
rpm -qa 'hinemos-*-manager*' --qf '%{NAME} %{VERSION}-%{RELEASE}\n'
# 出力例：hinemos-7.2-manager 7.2.0-2.el9 なら修正版
#         hinemos-7.2-manager 7.2.0-1.el9 なら未修正

パッケージ名は公式READMEのファイル名の形に合わせています。私たちは手元にRPM版のマネージャが無く、このコマンドは実機では未実行です。版が7.2.0・7.1.2・7.0.4でリリース番号が2以上なら修正済み、それ以外は未修正と判定します。累積パッチで直した環境はリリース番号が変わらない可能性があるため、パッチ適用の記録とあわせて確かめてください。

REST APIでアカウント－変更を持つロールと所属ユーザーを一覧にする

ロールの権限は画面でも確かめられますが、ロールが多いとAPIの方が速く済みます。マネージャのREST APIの場所は、Hinemos公式の技術記事にあるhttp://[マネージャ]:8080/HinemosWeb/api/AccessRestEndpoints/access/...の形です。次のスクリプトは、ログインしてロール一覧を取り、システム権限にAccessControlのMODIFYを含むロールと、その所属ユーザーを表示します。読み取りの呼び出しだけで、設定は変えません。

# list_account_modify.py：「アカウント－変更」を持つロールと所属ユーザーを一覧にする（読み取りのみ）
import json, os, sys, urllib.request

BASE = os.environ.get("HINEMOS_URL", "http://127.0.0.1:8080") + "/HinemosWeb/api/AccessRestEndpoints/access"

def call(method, path, token=None, body=None):
    req = urllib.request.Request(BASE + path, method=method,
                                 data=json.dumps(body).encode() if body else None,
                                 headers={"Content-Type": "application/json"})
    if token:
        req.add_header("Authorization", "Bearer " + token)
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)

token = call("POST", "/login", body={"userId": os.environ["HINEMOS_USER"],
                                     "password": os.environ["HINEMOS_PASSWORD"]})["token"]["tokenId"]
try:
    for role in call("GET", "/role", token):
        rid = role["roleId"]
        privs = call("GET", "/systemPrivilegeRole_systemPrevilige/" + rid, token)
        if not any(p["systemFunction"] == "AccessControl" and p["systemPrivilege"] == "MODIFY" for p in privs):
            continue
        users = [u["userId"] for u in (call("GET", "/role/" + rid, token).get("userInfoList") or [])]
        mark = "  <- 全ユーザーが所属" if rid == "ALL_USERS" else ""
        print(f"{rid}\t{','.join(users) or '(所属なし)'}{mark}")
finally:
    call("GET", "/logout", token)

パスと項目名は、ソースのAccessRestEndpoints.javaと応答用のDTO（tokenId・systemFunction・systemPrivilege）に合わせました。パス中の「Previlige」の綴りもソースどおりです。2026年11月4日に、同じ応答形を返すローカルのモックAPIに対して実行し、ADMINISTRATORSとALL_USERSの2行だけが出ることを確かめています。実際のHinemosマネージャでは未実行です。ロール一覧を読むには「アカウント－参照」が要るので、管理者のアカウントで実行します。

出力にALL_USERSが出たら、権限が初期値のまま残っています。ADMINISTRATORS以外の個別ロールが出た場合は、そのロールの所属者が本当にユーザー管理を担う人かを確かめます。

修正版の適用手順と、更新後も残る既存ALL_USERSの権限設定の直し方

パッケージの更新と権限の変更は、別々の作業として計画します。

RHELのRPM版を同一版のリリース番号2へ上げるコマンドと注意点

READMEに載っている更新コマンドは、インストール先を--prefixで指定するrpm -Uvhです。RHEL 9の7.2.0なら次の形になります。

# 既存のインストール先（例：/opt/hinemos）を指定して、7.2.0-2 へ更新する
rpm -Uvh --prefix=/opt/hinemos https://github.com/hinemos/hinemos/releases/download/v7.2.0_2/hinemos-7.2-manager-7.2.0-2.el9.x86_64.rpm

このコマンドもREADMEからの転記で、私たちは未実行です。READMEはサービスの停止・起動や事前のバックアップに触れておらず、基本機能マニュアルを参照するよう案内しています。注意したいのは、今回の7.2.0_2でエクスポート用スクリプトhinemos_export.shの出力先の指定が必須になった点です。バックアップを同じスクリプトで取っている場合は、更新後に引数を足さないと失敗します。

既存ALL_USERSからアカウント－変更を外す前に確かめる運用への影響

公式のお知らせには、修正版で新規に導入した場合、ALL_USERSの初期権限は「リポジトリ－参照」だけになると書かれています。既存環境の権限は、パッチやRPMの更新では自動で変わりません。ここは手で直します。

外す前に、ユーザーの追加や変更を誰が担っているかを確かめてください。一般の運用担当が新メンバーのアカウントを作っている運用なら、外した日から作れなくなります。その場合は「アカウント管理」用のロールを作って「アカウント－変更」を付け、担当者だけを所属させてから、ALL_USERSの権限を外します。お知らせによると、この権限はアカウントのパースペクティブ全般の変更権限で、他のパースペクティブの参照・変更には影響しません。設定画面は、7.x系なら基本機能マニュアルの4.3.3「アカウント機能の詳細」と4.3.5「アカウント機能の操作手順」で案内されています。ロールに権限を寄せる設計の考え方はRBAC（ロールベースアクセス制御）の仕組みと実装手順で整理しています。

ADMINISTRATORS所属ユーザーのパスワードが変更されていないかの点検

更新とあわせて、すでに悪用されていないかを確認してください。まず、ADMINISTRATORSに所属する全員に、今のパスワードでログインできるかを確かめてもらいます。ログインできない管理者がいれば、パスワードが書き換えられた可能性を疑います。

ユーザー情報の応答（UserInfoResponse）には更新者modifyUserIdと更新日時modifyDateの項目があります。ただし、パスワード変更でこの欄が更新されるかは公開情報では確かめられないため、手掛かりの1つに留めてください。疑わしい形跡があれば、管理者のパスワードを入れ替えたうえで、Hinemosのジョブ設定や通知設定に見覚えのない変更が無いかを確かめます。

保守終了の6.x系を使い続ける環境の軽減策と移行を決める判断基準

6.x系は修正版が出ないので、権限の設定だけで影響を狭めます。

6.x系で修正版が出ない場合にロールの権限だけで影響を狭める手順

1. ユーザーマニュアル12.6「ロールの設定」の画面で、ALL_USERSを含む各ロールのシステム権限を開き、「アカウント－変更」が付いたロールを書き出す
2. 12.2「ユーザとロールの管理」で、それぞれのロールの所属ユーザーを確かめる
3. ALL_USERSから「アカウント－変更」を外し、ユーザー管理を担う人だけの専用ロールへ移す
4. 一般ユーザーのアカウントで、他のユーザーのパスワード変更が拒否されることを確かめる

この方法では、専用ロールに入れた人は引き続き管理者のパスワードを変えられます。修正版のような「管理者以外は管理者を操作できない」という境界は作れません。専用ロールには、ADMINISTRATORSと同じくらい信頼できる人だけを入れてください。

運用管理基盤を6.x系のまま使うか7.2へ移行するかを決める判断基準

私たちの判断はこうです。6.x系で一般ユーザーのアカウントが管理者以外に1つでもあるなら、軽減策で当座をしのぎつつ、7.2系への移行を計画に載せます。今回のように「修正は最新の系列だけ」という対応は、次の脆弱性でも同じになる見込みが高いからです。7.2系のマネージャは6.x系のエージェントと互換性があり、管理対象のノード側を一度に入れ替えなくて済む点は移行の負担を下げます。

反対に、管理者1人だけが使い、ネットワーク上も運用端末からしか届かない6.x系なら、軽減策だけで当面の運用を続けることも判断の選択肢です。その場合も、Hinemosが届く範囲のサーバーを洗い出しておくと、次に何か起きたときの影響範囲の把握が早くなるので、この作業は省かないでください。他の監視ツールへ乗り換えるかを比べる場合は、Zabbixの仕組みと他ツールとの違いが材料になります。管理系システム全体の弱点を外部の目で洗い出したいときは、脆弱性診断の種類と外注時の判断基準で進め方を確認できます。

Hinemosの脆弱性対応でよく受ける質問と運用担当者向けの回答

今回の更新を進める中で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

修正版を当てればALL_USERSの権限も自動で直りますか？

直りません。公式のお知らせは、累積パッチや修正版での更新では既存環境の権限は変更されないと明記しています。ALL_USERSの初期権限が「リポジトリ－参照」だけになるのは、修正版で新規に導入した場合だけです。更新後も、一般ユーザー同士で互いのパスワードを変えられる状態は残るので、権限は手で見直してください。

Hinemosエージェントも更新が必要ですか？

公表されている修正版は、いずれもマネージャのパッケージ（patch_manager_〜とhinemos-〜-manager）です。今回の欠陥はマネージャのREST APIの権限判定にあり、エージェントの更新は案内されていません。7.2系のマネージャは6.x系や7.0・7.1系のエージェントと互換性があるとリリースノートに書かれています。

本人が自分のパスワードを変える操作は制限されますか？

制限されません。修正後も、本人による自分のパスワード変更は従来どおりです。ソース上も、本人用のPUT /access/user_me_passwordは他人のパスワードを変えるAPIとは別に用意されています。止められるのは、ADMINISTRATORSに属さない人による管理者のパスワード変更や、管理者ロールへの割り当て・解除です。

Windows版のHinemosマネージャはどこで修正版を入手できますか？

GitHubのリリースページでは、Windows版とAmazon Linux 2023版のマネージャは、Hinemosポータルの相談・見積依頼フォームから問い合わせる形と案内されています。保守契約がある場合は、カスタマーポータルから累積パッチの扱いを確かめてください。入手までの間は、ALL_USERSから「アカウント－変更」を外す軽減策を先に済ませます。

社外に公開していないHinemosでも急ぐ必要がありますか？

急ぐ必要があります。この脆弱性の攻撃者は、Hinemosにログインできる一般ユーザーです。社外から届かない構成でも、協力会社や退職予定者を含む社内のアカウントが起点になります。ログインできる人が管理者だけの環境なら急ぎ度は下がりますが、API経由で外部の不正アクセスを受けた場合の守り方はAPI不正アクセス対策の実装手順も参考になります。

関連記事

• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：今回の欠陥と同じ「誰が誰を操作するか」を見ない認可の問題を、作る側から防ぐ方法です。
• API不正アクセス対策の実装手順：REST APIに認可・トークン失効・レート制限を入れる実装の手順です。
• RBAC（ロールベースアクセス制御）とは？仕組みと実装手順：ALL_USERSのような全員所属ロールに何を持たせるかの設計の考え方です。
• CVSSv3とは？スコアの目安と計算式：CVSS 6.5という値を、自社の環境に置き換えて読むための解説です。
• Zabbixとは？仕組み・監視できること・他ツールとの違い：運用管理基盤の乗り換えを比べるときの材料です。