Jivejdon EUVD-2026-95307

Requires a low-privileged authenticated account on the Jivejdon instance that is permitted to upload attachments, and the attachment-handling path (UploadShowAction) must serve the attacker-supplied Content-Type inline - the CVSS PR:L reflects this authentication requirement. Exploitation additionally depends on victim interaction (CVSS UI:P): a logged-in user must open the shared attachment link for the text/html payload to execute on the application origin. Limiting factors are therefore the need for an upload-capable account and the dependence on victims actively viewing the crafted link; there is no unauthenticated or zero-interaction path.

This is a medium-severity stored XSS (CVSS 4.0 base 5.1; CWE-79) whose signals are internally consistent and point to a real-but-bounded risk rather than an urgent priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N) confirms network reach and low complexity but requires PR:L (an authenticated forum account) and UI:P (a victim must view the malicious attachment link), both of which cap impact to Low confidentiality and integrity with no availability effect. There is no CISA KEV listing and no public exploit code referenced in the inputs, so exploitation status is 'no public exploit identified at time of analysis'; the finding originates from a VulnCheck advisory and GitHub issue #28 with specific source-line references, which makes the technical claim credible even without a weaponized PoC. EPSS and SSVC data were not supplied, so probabilistic and decision-framework signals cannot be weighed here - state explicitly: no EPSS, KEV, or SSVC values were provided. The practical risk is further dampened by the product itself: Jivejdon (banq/jivejdon) is an obscure open-source Java forum with negligible production deployment, so even a straightforward XSS has a very small real-world blast radius. Net: a legitimate, verifiable defect worth patching for anyone running it, but not a broad-impact emergency.

An attacker who holds (or registers) a low-privileged forum account uploads a file whose Content-Type is declared as text/html containing a JavaScript payload. Because UploadShowAction serves the attacker-controlled Content-Type inline rather than forcing a download, the attacker shares the attachment link, and any logged-in user who opens it executes the script on the application's origin, enabling session/cookie theft or actions in the victim's context. No public exploit code is referenced, but the vulnerable code paths are documented in the advisory and GitHub issue.