Huly Platform CVE-2026-111606

Requires an authenticated account on the target Huly instance (CVSS PR:L) - the vulnerable mergeSpecifiedPersons account RPC performed no authorization or workspace-role check, so any logged-in user, not just a workspace Maintainer, could invoke it. The attacker must know or enumerate two person UUIDs: the victim's person UUID and an attacker-controlled person UUID that carries attacker-owned, unverified social identifiers. Account takeover is completed only if the grafted social id is login-capable and the victim account is reachable via the login or password-recovery flow. Limiting factors: attacker must already hold a valid account (so greatest exposure is on instances with open/self-service registration or many semi-trusted tenants), and must obtain the two UUIDs; no vulnerability exists once upgraded past 0.7.432 where Maintainer role and same-workspace/non-login-capable guards are enforced.

This is a genuine high-priority issue for anyone running Huly, but its real-world risk is bounded by an authentication prerequisite. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 8.6 and describes a low-complexity, network-reachable attack requiring no user interaction, with high confidentiality and integrity impact (VC:H/VI:H) consistent with full account takeover. The decisive mitigating signal is PR:L: exploitation requires an already-authenticated account on the instance, so this is an insider/registered-user privilege-escalation path rather than a fully pre-auth internet-wide bug - contradicting any treatment of it as remotely unauthenticated. No EPSS score, KEV listing, or SSVC decision data was supplied in the input, so exploitation probability and automatability cannot be quantified; absence of these is not evidence of low risk, only of missing data. No explicit POC flag was provided either, but a detailed third-party technical writeup (HackMD) and a VulnCheck advisory exist, which materially lower the barrier to weaponization even though working exploit code is not confirmed in the input. Net: a real priority to patch on multi-tenant or publicly-registerable Huly deployments, with somewhat reduced urgency on single-tenant/internal instances where all users are trusted.

A low-privileged but authenticated user of a Huly instance creates an attacker-controlled person carrying their own unverified social identifiers (e.g. an email they control), then calls the mergeSpecifiedPersons account RPC supplying the victim's person UUID and the attacker's person UUID. Because the RPC performs no authorization check, the attacker's social ids are grafted onto the victim person; the attacker then invokes the login or password-recovery flow against that email to seize the victim's account. A detailed technical writeup is publicly available, though no confirmed exploit code is noted in the input.