Revive Adserver EUVD-2026-38508

Exploitation requires the attacker to hold a valid low-privileged user account on the target Revive Adserver instance - unauthenticated exploitation is not possible. The attacker must be able to set or update their Full Name profile field to include HTML/JavaScript content. A system event that generates an email incorporating the user's Full Name must occur and be logged to the userlog table (e.g., account notifications, password resets, or other user-triggered email workflows). Finally, an administrator must actively navigate to userlog-details.php and render the log entry containing the poisoned content. Limiting factors are: valid user account required (PR:L per independent CVSS assessment), administrator must take active UI action to view the specific log entry (UI:R), and the attack is indirect - the payload is not triggered by the attacker's own request but by a subsequent admin session viewing stored data.

The CVSS vector supplied in the input (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N) is a null placeholder - it assigns zero impact and no privilege requirement, directly contradicting the description which specifies a low-privileged user initiating the attack and an admin performing a UI interaction. This vector must be disregarded entirely. The real-world risk profile requires a valid user account (PR:L) and active admin interaction with the log page (UI:R), which substantially reduces the attack surface compared to what the placeholder CVSS implies. The cross-privilege escalation is the primary concern: a regular user can compromise an admin session, enabling privileged account takeover, data exfiltration, or further lateral movement within the admin interface. No EPSS score was provided and the vulnerability does not appear in CISA KEV, indicating no confirmed widespread or active exploitation. Risk is meaningful for Revive Adserver deployments that permit untrusted user registrations, but the admin interaction requirement limits opportunistic mass exploitation.

An attacker registers or uses an existing low-privileged Revive Adserver account and sets their Full Name to a JavaScript payload - for example, a script that POSTs the current document cookie to an attacker-controlled endpoint. The attacker then triggers any account event that generates a system email (such as a password reset), causing the email body containing the malicious name to be written to the userlog table. When an administrator later reviews system activity by navigating to userlog-details.php, the stored payload executes silently in the admin's browser, delivering the admin session token to the attacker and enabling full account takeover.