HuLa-Server CVE-2026-119650

The attacker must hold a valid authenticated account on the target HuLa-Server instance (PR:L); no admin or victim credentials are needed. Given that, exploitation requires only a GET or POST request to the /privacy endpoint with a target uid parameter - the PrivacyController performs no ownership/authorization check, so any authenticated user can both read and overwrite another user's UserPrivacy settings. Limiting factors: valid authentication is mandatory (not anonymous), impact is confined to privacy-setting data (low confidentiality and integrity, no availability or code execution), and it affects HuLa-Server versions through 3.0.7; no fixed version is listed in the available data.

This is a moderate-severity authorization flaw (IDOR, CWE-639) that is a real but bounded priority. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N) is internally consistent with the description: network-reachable, low complexity, but requiring an authenticated account (PR:L), with only low confidentiality and integrity impact and no availability impact. The vuln.today decision label is 'this_month' (not act_now/emergency), which aligns with the mid-range 5.3 score. There is no CISA KEV listing and no EPSS score in the supplied data, so there is no signal of active or widespread exploitation; however, a public write-up and source-line references are provided, lowering the barrier to reproduction. The key tension is that the attack is network-facing and trivially scripted once authenticated, yet the impact is limited to other users' privacy settings rather than full account or system compromise, and it requires a valid account on the target instance - so this is a genuine authorization defect worth patching promptly but not a critical, mass-exploitable issue. Note the 'Authentication Bypass' tag is misleading: the flaw requires authentication and bypasses authorization (object-level access control), not authentication.

An attacker registers or uses any valid HuLa-Server account, then sends a GET or POST request to the /privacy endpoint supplying another user's uid instead of their own. Because PrivacyController performs no ownership check, the attacker reads and can overwrite that victim's UserPrivacy settings. A public PoC reference (hackmd write-up and pinned source lines) exists but is not verified as working exploit code; low attack complexity means it can be scripted across enumerated uids.