Jeebase CVE-2026-105180

Requires an authenticated session (PR:L) to the Jeebase application, as the vulnerable updateUser function in UserService sits behind the /user/update/info endpoint, which is an authenticated user-profile update operation. The specific condition is the ability to submit the user/tempUser object with attacker-added attributes that the server binds dynamically without an attribute allow-list (CWE-913 mass assignment). Limiting factors: exploitation is confined to Jeebase 0.0.1, requires valid low-privilege credentials, and each metric's impact is rated Low - there is no privilege-boundary scope change (SC/SI/SA:N), so impact is bounded to the vulnerable application's own data. No user interaction is required (UI:N).

This is a low-priority, high-noise issue typical of VulDB-sourced disclosures against tiny hobby projects. The CVSS 4.0 base score is only 2.1, consistent with the vector: network attack vector (AV:N) and low complexity (AC:L/AT:N) are offset by a required authenticated session (PR:L) and only Low impact to confidentiality, integrity, and availability (VC:L/VI:L/VA:L) with no subsequent-system scope impact. The E:P temporal metric confirms a proof-of-concept exploit rather than functional/weaponized code, which aligns with the description stating the exploit 'has been publicly disclosed.' There is no EPSS score, no CISA KEV listing, and no SSVC decision data in the input, so exploitation remains theoretical and un-prioritized by any authoritative framework. The CWE-913 classification (mass assignment / dynamically-determined object attributes) matches the 'Information Disclosure' tag only loosely - mass assignment typically enables privilege or attribute tampering rather than pure disclosure, so the tag may understate the true integrity angle. Net: a genuine but minor flaw in an obscure product; it is a low real-world risk, not a false 'high-CVSS' alarm since the CVSS itself is correctly low. Note the vendor has not responded to the advance issue report, so no patch is confirmed.

An authenticated low-privilege user sends a crafted request to the /user/update/info endpoint, injecting extra attributes into the user/tempUser object that the updateUser function binds dynamically without an allow-list (mass assignment). This lets the attacker set fields that were never meant to be client-controllable, potentially altering their own account attributes. A proof-of-concept exploit has been publicly disclosed (E:P).