Emlog Pro EUVD-2025-33214

Exploitation requires an authenticated Emlog Pro account (≤ 2.5.21) that holds privileges to post a 'Twitter' feature message - the specific feature where unsanitized input is stored. The payload only fires when a second user (e.g., an administrator) actively clicks the malicious post to view it, so success depends on victim interaction (UI:P) rather than being fully automatic. Limiting factors: an attacker must first obtain a posting-capable account (PR:L, so not anonymous), the target must run the vulnerable 'Twitter' feature, and a victim must be socially/operationally induced to open the post. There is no vendor fix, so mitigation relies on restricting who can post and on administrators avoiding untrusted posts.

This is a genuine-but-moderate issue, not a top-tier emergency. The CVSS 4.0 base score is 5.1 (medium), and the signals are internally consistent: network vector (AV:N) but requiring low privileges (PR:L - an authenticated account able to post 'Twitter' messages) and passive user interaction (UI:P - a victim must click the malicious post), with only low confidentiality/integrity impact and a limited scope change (SC:L/SI:L). EPSS is very low at 0.03% (7th percentile), indicating no meaningful mass-exploitation signal. The vulnerability is NOT in CISA KEV, so there is no public evidence of active exploitation; however, publicly available exploit code exists (per the GitHub Security Advisory reference), which lowers the barrier to opportunistic abuse. The signals do not conflict, but two caveats matter: (1) EPSS is low despite POC availability, which is expected for a stored XSS in niche software - POC availability and active exploitation are distinct, and nothing here indicates widespread exploitation; (2) crucially, there is NO vendor fix available ('This issue does not currently have a fix'), so defenders cannot remediate by patching and must rely on compensating controls. Net: a real priority for anyone actually running Emlog Pro, but low broad-ecosystem risk given the small deployment footprint and the authentication + user-interaction prerequisites.

A low-privileged but authenticated Emlog Pro user posts a 'Twitter' micro-post containing a malicious JavaScript payload, which is stored server-side. When an administrator or other user later clicks the post to view it, the script executes in their browser session, potentially stealing session cookies or performing actions as the admin. Public exploit code exists, and no vendor patch is available, so exploitation only requires a posting-capable account and a victim who views the post.