GYM One CVE-2026-55872

Exploitation requires (1) an attacker who can store values in the firstname, lastname, or email profile fields of a GYM One user record prior to version 1.4.1 - i.e. an account or registration path with write access to those fields (consistent with CVSS PR:L), and (2) an administrator subsequently visiting the user-management list at /admin/users/, which renders those fields without HTML output encoding (CVSS UI:R). The payload persists and re-triggers on every admin view until the offending record is deleted. Limiting factors: it is not fire-and-forget - it depends on administrator interaction with that specific page, on some level of prior access to store the data, and on the instance running a version below 1.4.1; upgrading to 1.4.1 removes the condition entirely.

This is a stored (persistent) cross-site scripting flaw (CWE-79) in GYM One's admin/users/index.php, which renders attacker-controllable firstname, lastname, and email profile fields into the administrator user list without HTML output encoding. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, base 8.7) is internally consistent with the description: network-reachable, low attack complexity, requires some privilege (PR:L - an account able to store those profile values), requires the administrator to visit /admin/users/ (UI:R), and crosses a scope boundary (S:C) because the payload executes in the privileged administrator's browser context yielding high confidentiality and integrity impact. No EPSS score, KEV listing, or public POC was supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the 8.7 rating reflects potential technical impact, not demonstrated real-world weaponization. Realistic priority is tempered by two factors the signals make explicit: exploitation depends on an administrator actually opening the user-management page (UI:R), and on the product being a niche open-source gym-management application with a very small deployment footprint. SSVC-style reasoning: exploitation status is 'none observed', the attack is not automatable (it hinges on administrator interaction and prior data storage), and technical impact is total for the admin session - netting a moderate, patch-when-practical priority rather than an emergency. Missing data to note: no EPSS, no KEV, and no independent POC confirmation.

A low-privileged user (or a self-registered member, depending on deployment) sets their firstname, lastname, or email profile field to a value containing an HTML/script payload. The payload is stored and later rendered unescaped when an administrator opens the user list at /admin/users/, executing in the admin's authenticated session to steal session data or perform actions with administrator privileges. No public exploit code was identified at time of analysis; exploitation requires the administrator to view the affected page.