Cronicle EUVD-2026-98908

Requires a multi-user Cronicle deployment where (a) the attacker can control their own account's full_name - either as an authenticated non-administrator via /api/user/update with a valid session and current password, or, only when the non-default 'free_accounts' option is enabled, as an anonymous user via self-registration - and (b) an administrator subsequently opens the admin Activity Log (htdocs/js/pages/admin/Activity.js), which is the UI:R trigger that executes the stored payload. The payload must contain a line break to bypass the bundled pixl-server-user input filter whose regular expression does not match newlines. Limiting factors: exploitation is impossible on single-admin installs with no other users and free_accounts disabled, and the payload only fires when/if an admin views the Activity Log; affected versions are all releases prior to 0.9.119.

This is a genuinely high-priority stored XSS (CWE-79) in a cross-site-scripting-to-privilege-escalation chain, and the signals are internally consistent rather than inflated. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H, base 9.0) is well-grounded: network-reachable, low complexity, and a scope change (S:C) that is fully justified because a low-privileged user's stored name executes JavaScript inside a higher-privileged administrator's authenticated session, crossing a security boundary into full admin takeover and command execution via Cronicle's privileged job/plugin features. The one tension worth flagging is PR and UI: the base vector uses PR:L (authenticated non-admin) and UI:R (an admin must open the Activity Log), but the description notes that when the non-default 'free_accounts' option is enabled, an unauthenticated attacker can plant the payload during self-registration - effectively PR:N in that configuration, which would raise real-world risk further. EPSS is NOT provided in the input and the vulnerability is NOT listed in CISA KEV, so there is no evidence of active or widespread exploitation. No weaponized public exploit is referenced - only a vendor advisory, fixing commit, and release - so this is a credible, clearly-described, patchable flaw rather than a confirmed in-the-wild threat. Net: treat as a high priority to patch for anyone running Cronicle with multiple users (especially with free_accounts enabled), but recognize exploitation requires a specific multi-user deployment and an admin viewing the log, which limits opportunistic mass exploitation.

A low-privileged Cronicle user (or, if free_accounts is enabled, an anonymous self-registrant) sets their account's full name to a payload containing a line break that bypasses the pixl-server-user input filter, submitting it via /api/user/update with a valid session and current password. The malicious name is stored and later rendered unencoded in the administrator's Activity Log; when an admin opens that page, the script runs in their session, allowing account takeover and arbitrary command execution through Cronicle's privileged scheduling/plugin features. No standalone public exploit is referenced, but the fixing commit diff publicly reveals the exact unencoded sink (item.user.full_name) and the filter-bypass technique.