How do I check whether I am affected by CVE-2026-109849?

In the Hinemos client, open the Account perspective and check each role (especially ALL_USERS) for the system permission 'Account - Modify', and list which users belong to those roles. Any non-ADMINISTRATORS user holding it can reset admin passwords. Check the manager version: affected are 7.2.0, 7.1.0-7.1.2, 7.0.0-7.0.4 and 6.0.0-6.2.2 unless the fixed build (-2 release) or cumulative patch is installed (e.g. rpm -q hinemos-7.2-manager shows 7.2.0-2).

What is the fix for CVE-2026-109849?

Install the vendor's fixed build: OSS users update to hinemos-7.2-manager-7.2.0-2, hinemos-7.1-manager-7.1.2-2 or hinemos-7.0-manager-7.0.4-2 (GitHub releases v7.2.0_2, v7.1.2_2, v7.0.4_2); subscribers apply patch_manager_for7.2.0_20261104.zip, patch_manager_for7.1.2_20261104.zip or patch_manager_for7.0.4_20261104.zip. The update does not change existing role permissions: also remove Account-Modify from ALL_USERS and other roles that do not need it. 6.x (end of standard support) gets no patch; for it, remove the permission.

Post Share

HIGH7.1CVSS · vultures@jpcert.or.jp

NO KNOWN
EXPLOIT

HINEMOS-MANAGER · CVE-2026-109849 · Other

Hinemos: any user with Account-Modify permission can change administrator passwords (ALL_USERS has it by default)

Q: Who is not affected by CVE-2026-109849?

Not affected if: account-modify-permission-removed, fixed-build-installed, no-non-admin-users.

FIX → 7.2.0-2 · 7.1.2-2 · 7.0.4-2 ✓ verified

In Hinemos, the password-change function let any non-administrator whose role holds the system permission Account-Modify change an administrator's password and gain admin rights. The ALL_USERS role, which every user belongs to, had that permission by default. NTT DATA INTELLILINK fixed it on 2026-11-04 by requiring the caller to be in the ADMINISTRATORS role to change an admin's password.

Full story ↓Less ↑

first public Nov 5, 2026 · 2 sources

Check it with your coding agent

It checks your repository and tells you if you’re affected, with the fix.

01 · Who is affected

✓ Verified Nov 5

Teams running the Hinemos manager (7.0-7.2, and unsupported 6.x) where non-administrator accounts exist and belong to a role with the Account-Modify system permission. ALL_USERS had it by default, so by default any logged-in user qualifies. Installs with only administrator accounts, or where Account-Modify was removed from every role non-admins belong to, can skip it. Updating alone does not remove the permission from existing roles.

hinemos-manager7.2.0, >= 7.1.0, <= 7.1.2, >= 7.0.0, <= 7.0.4 (before the -2 release), 6.0.0 - 6.2.2 (unsupported, no fix)fixed in 7.2.0-2, 7.1.2-2, 7.0.4-2

Not affected if account-modify-permission-removed, fixed-build-installed, no-non-admin-users

Who cares hinemos, privilege-escalation, self-hosted

02 · How to check

✓ Verified Nov 5

In the Hinemos client, open the Account perspective and check each role (especially ALL_USERS) for the system permission Account - Modify, and list which users belong to those roles
Any non-ADMINISTRATORS user holding it can reset admin passwords
Check the manager version: affected are 7.2.0, , and unless the fixed build (-2 release) or cumulative patch is installed (e.g. )

Exploited: No reports yet
Public exploit: None on GitHub
EPSS: Not scored
Last updated: Nov 5, 2026

How it unfolded

2 events · Nov 5, 2026 → Nov 5, 2026

Nov 5, 202601:30 UTCNVD CVE-2026-109849
Nov 5, 202601:33 UTCInfraStack Analyst Read Hinemos vendor notice (2026-11-04) and JVN#46901199. Root cause: any user in a role with system permission Account-Modify could change admin passwords; ALL_USERS had it by default. Fixed builds 7.2.0-2, 7.1.2-2, 7.0.4-2 (OSS RPMs / subscriber cumulative patches); 6.x unpatched, mitigation only. No exploitation or PoC seen.moreless

What the sources say, verbatim

268 characters

Incorrect privilege assignment issue exists in Hinemos. If this vulnerability is exploited, an attacker who can access the password change API with specific permissions that can be assigned to non-administrative users may change the password of an administrative user.

Sources and references

NVD: CVE-2026-109849Nov 5, 2026
Hinemos vendor notice: password change vulnerability and ALL_USERS initial permissions (2026-11-04)Advisory · hinemos.info
JVN#46901199 Hinemos vulnerable to incorrect privilege assignmentAdvisory · jvn.jp
Hinemos vendor notice: password change vulnerability and ALL_USERS initial permissions (2026-11-04)Fix · hinemos.info
Hinemos vendor notice: password change vulnerability and ALL_USERS initial permissions (2026-11-04)

Are you affected?

Tell InfraStack what you run. It checks this one, and every next one, against your stack.

Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.

InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.

In Slack

Run the check

Get the next Hinemos-manager threat the day it hits your stack.

Start watching free

Post Share

HIGH7.1CVSS · vultures@jpcert.or.jp

NO KNOWN
EXPLOIT

HINEMOS-MANAGER · CVE-2026-109849 · Other

Hinemos: any user with Account-Modify permission can change administrator passwords (ALL_USERS has it by default)

FIX → 7.2.0-2 · 7.1.2-2 · 7.0.4-2 ✓ verified

Full story ↓Less ↑

first public Nov 5, 2026 · 2 sources

Check it with your coding agent

It checks your repository and tells you if you’re affected, with the fix.

01 · Who is affected

✓ Verified Nov 5

hinemos-manager7.2.0, >= 7.1.0, <= 7.1.2, >= 7.0.0, <= 7.0.4 (before the -2 release), 6.0.0 - 6.2.2 (unsupported, no fix)fixed in 7.2.0-2, 7.1.2-2, 7.0.4-2

Not affected if account-modify-permission-removed, fixed-build-installed, no-non-admin-users

Who cares hinemos, privilege-escalation, self-hosted

02 · How to check

✓ Verified Nov 5

In the Hinemos client, open the Account perspective and check each role (especially ALL_USERS) for the system permission Account - Modify, and list which users belong to those roles
Any non-ADMINISTRATORS user holding it can reset admin passwords
Check the manager version: affected are 7.2.0, , and unless the fixed build (-2 release) or cumulative patch is installed (e.g. )

Exploited: No reports yet
Public exploit: None on GitHub
EPSS: Not scored
Last updated: Nov 5, 2026

How it unfolded

2 events · Nov 5, 2026 → Nov 5, 2026

Nov 5, 202601:30 UTCNVD CVE-2026-109849
Nov 5, 202601:33 UTCInfraStack Analyst Read Hinemos vendor notice (2026-11-04) and JVN#46901199. Root cause: any user in a role with system permission Account-Modify could change admin passwords; ALL_USERS had it by default. Fixed builds 7.2.0-2, 7.1.2-2, 7.0.4-2 (OSS RPMs / subscriber cumulative patches); 6.x unpatched, mitigation only. No exploitation or PoC seen.moreless

What the sources say, verbatim

268 characters

Sources and references

NVD: CVE-2026-109849Nov 5, 2026
Hinemos vendor notice: password change vulnerability and ALL_USERS initial permissions (2026-11-04)Advisory · hinemos.info
JVN#46901199 Hinemos vulnerable to incorrect privilege assignmentAdvisory · jvn.jp
Hinemos vendor notice: password change vulnerability and ALL_USERS initial permissions (2026-11-04)Fix · hinemos.info
Hinemos vendor notice: password change vulnerability and ALL_USERS initial permissions (2026-11-04)

Are you affected?

Tell InfraStack what you run. It checks this one, and every next one, against your stack.

Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.

InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.

In Slack

Run the check

Get the next Hinemos-manager threat the day it hits your stack.

Start watching free

Hinemos: any user with Account-Modify permission can change administrator passwords (ALL_USERS has it by default)

01 · Who is affected

02 · How to check

How it unfolded

What the sources say, verbatim

Sources and references

Read next

Get the next Hinemos-manager threat the day it hits your stack.

Hinemos: any user with Account-Modify permission can change administrator passwords (ALL_USERS has it by default)

01 · Who is affected

02 · How to check

How it unfolded

What the sources say, verbatim

Sources and references

Read next

Get the next Hinemos-manager threat the day it hits your stack.

03 · The fix