FlyCMS CVE-2026-125082

Requires an authenticated account with privilege to submit/author article content (PR:L) - not anonymous: the attacker injects a payload into the rich-text content argument handled by ModelDataService.insertData (articles/detail.html, Content Rendering component), which is stored without sanitization. Execution additionally requires victim interaction (UI:P): a reviewer or administrator must view the stored content in the backend, where the template renders ${info.content} raw in the same session domain, as the patch comments explicitly describe. Limiting factors: exploitation is bounded by the need for a submission-capable account AND a privileged user opening the malicious content; the payload does not fire against anonymous visitors on its own, and the pre-patch render-side filtering in the review drawer may partially blunt some vectors though it does not clean the stored value.

This is a stored (persistent) cross-site scripting flaw (CWE-79) in sunkaifei FlyCMS, rated moderate at CVSS 5.1 under the vendor-supplied CVSS 4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. The signals are internally consistent and point to a real-but-bounded issue rather than a mass-exploitation emergency: network attack vector and low complexity make the injection easy to deliver, but PR:L means the attacker must already hold a (low-privilege) authenticated account able to submit article content, and UI:P means a victim - per the patch's own code comments, a reviewer or administrator viewing the submission in the backend - must open the poisoned content for the payload to fire. The vendor/VulDB decision label is 'this_month' (not act_now/emergency), which matches the picture. KEV status is NOT listed and no EPSS score was provided, so there is no evidence of active or automated exploitation; the only exploitation signal is a public PoC reference (a GitHub issue) that is not verified as working exploit code. The source-code evidence corroborates the mechanism strongly: the fix adds a server-side Jsoup ContentSanitizer because the front-end template emits ${info.content} raw, confirming a genuine stored-XSS channel into the same session domain used by reviewers and admins. Net: a legitimate flaw worth patching on a normal cycle, not a drop-everything priority, and its impact (admin/reviewer session in the CMS backend) can be more serious than the modest base score implies if a high-privilege user is the one who views the content.

A user with a low-privilege authoring account submits an article whose rich-text content embeds a malicious payload (e.g. a <script>, an onerror handler, or a javascript: pseudo-protocol), which ModelDataService.insertData stores unsanitized. When a reviewer or administrator later opens that content in the backend - which renders ${info.content} raw in articles/detail.html - the script executes in their authenticated session. A public PoC reference exists (GitHub issue #18); it is not verified as working exploit code.