vBulletin CVE-2026-9357

Requires attacker to possess authenticated vBulletin account with low privileges (standard forum member access). Victim must interact with the manipulated login component-either by clicking a crafted link (reflected XSS scenario) or by naturally accessing a login page where malicious payload has been stored (stored XSS scenario). The UI:R (Required user interaction) constraint means exploitation cannot be fully automated and depends on social engineering success. Attack is remotely executable (AV:N) against any internet-accessible vBulletin 6.x installation without requiring additional network positioning. Exploitation is limited to vBulletin application scope (S:U)-cannot directly compromise underlying server or adjacent systems, though stolen administrative credentials could enable subsequent privilege escalation. No special server configuration or non-default feature enablement is required; the login component is core functionality present in all standard deployments.

Real-world risk is moderate-low despite network accessibility. The CVSS base score of 3.5 reflects significant exploitation constraints: requires authenticated attacker (PR:L), victim user interaction (UI:R), and produces only low integrity impact (I:L) with no confidentiality or availability consequences. The CVSS temporal score with E:P (Proof-of-Concept) confirms exploit code exists but is not fully automated. Absence from CISA KEV and the S:U (Unchanged scope) indicate attacks remain confined to the vulnerable application context-cannot pivot to backend systems. However, XSS in authentication flows poses session hijacking and credential theft risks that CVSS I:L may understate. Primary risk factors: public POC increases attacker accessibility, vendor non-responsiveness means no official patch timeline, and vBulletin's wide deployment in internet-facing forums creates large attack surface. Mitigating factors: attack complexity is low (AC:L) but multi-step prerequisites (authenticate, craft payload, social engineer victim) reduce automated exploitation likelihood. Organizations should prioritize based on whether their vBulletin instance has untrusted authenticated users and how sensitive the forum content/user base is.

An attacker with a standard vBulletin forum account (low privilege) identifies the login component XSS vulnerability and crafts a malicious payload embedded in a login-related parameter-potentially a stored XSS via profile field or redirect URL, or reflected XSS in an error message. The attacker distributes a crafted link via forum private messages or embeds it in forum posts, socially engineering victims (other authenticated users or administrators) to click. When a victim interacts with the manipulated login function, the injected JavaScript executes in their browser context, enabling the attacker to steal session cookies, capture credentials entered into the login form, perform actions as the victim user, or deface the login page. Public proof-of-concept code exists to demonstrate the vulnerability, lowering the technical skill required for exploitation.