Jivejdon CVE-2026-107831

Exploitation requires that the victim already holds an authenticated Jivejdon session AND is lured into loading attacker-controlled content (UI:P), because the attack rides the victim's existing cookies. The concrete flaw is that the state-changing endpoints /account/protected/delAll, /account/protected/sub/delSub, and /message/updateAction accept GET requests and lack anti-CSRF tokens, so a simple link, image, or iframe triggers them. Limiting factors: the victim must be logged in, must interact with the malicious link, and the product must be Jivejdon at or below version 5.0; the attacker gains no direct access and cannot read data, only cause message/subscription deletion or thread renaming.

This is a genuine-but-low-priority issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N) scores 5.3 (Medium), and that score is honest: the attack is network-reachable and low-complexity, but it requires passive user interaction (UI:P) and its only impact is partial integrity (VI:L) - state-changing actions like deleting a victim's private messages/subscriptions or renaming threads, with no confidentiality (VC:N) or availability (VA:N) loss. No EPSS score was supplied, the CVE is not listed in CISA KEV, and no public exploit was referenced, so this reflects no public exploit identified at time of analysis - only the vendor advisory and source-code references from VulnCheck. Per the CVSS 4.0 PR:N metric the attacker needs no privileges, but the technique inherently depends on the VICTIM already holding an authenticated session, which meaningfully limits real-world impact. There is no conflicting signal here; rather, the key limiter is prevalence: Jivejdon is an obscure open-source forum, so even a trivially craftable CSRF has a very small real-world footprint. Treat as a routine-patch item, not an emergency.

An attacker hosts or emails a crafted link (or auto-loading image/iframe) pointing at a Jivejdon GET endpoint such as /account/protected/delAll. When an already-logged-in forum user visits the attacker's page, their browser silently issues the authenticated request, deleting the victim's private messages and subscriptions or renaming a thread. No public exploit code was referenced, but the attack is trivial to reproduce because the endpoints accept state-changing GET requests with no anti-CSRF token.