Revive Adserver CVE-2026-50744

The attacker must hold a valid low-privilege account on the Revive Adserver instance (consistent with CVSS PR:L) to issue an authenticated HTTP request to the XML-RPC endpoint. The XML-RPC API must be network-accessible from the attacker's position; if restricted by firewall or web-server ACL to admin IP ranges only, remote exploitation is blocked. The flaw is triggered by the ox.login method specifically - other API methods are not the trigger. Exploitation is limited to Revive Adserver 6.0.7 (and potentially earlier versions); platforms not running this software are unaffected. There is no required user interaction and no special non-default configuration needed beyond the XML-RPC API being reachable.

The vendor-assigned CVSS 3.0 score of 4.3 (Medium) with C:L/I:N/A:N likely underestimates realistic impact: bypassing an admin-only API gate plausibly enables both read and write operations on advertising campaigns, user data, and platform configuration, suggesting I:L at minimum. No EPSS data was supplied; its absence means exploitation probability cannot be quantified from that signal. The vulnerability is not listed in CISA KEV, and no public proof-of-concept has been confirmed, indicating opportunistic mass exploitation has not been observed. CVSS metrics (AV:N/AC:L/PR:L) indicate the attack is network-accessible with low complexity and requires only low-privilege credentials, making it straightforward for any authenticated non-admin user to execute once the technique is understood. The HackerOne disclosure channel suggests responsible reporting, which may have limited early exposure. Overall priority is moderate for organizations running Revive Adserver 6.0.7: the ease of exploitation is high but the niche deployment footprint and absence of known active exploitation temper urgency.

An authenticated low-privileged Revive Adserver user sends an ox.login XML-RPC request containing admin credentials they do not possess; the server returns an authentication-failure error but also sets a live session cookie in the HTTP response headers. The attacker extracts that Set-Cookie value, discards the error, and includes the session token in subsequent XML-RPC API calls to invoke admin-restricted methods - such as modifying ad campaigns or retrieving account data - without ever possessing the admin password. No public proof-of-concept has been confirmed, but the attack technique is straightforward and requires only HTTP-level tooling.