Revive Adserver before 3.2.3 suffers from session fixation, by allowing arbitrary session identifiers to be forced and, at the same time, by not invalidating the existing session upon a successful authentication. Under some circumstances, that could have been an opportunity for an attacker to steal an authenticated session.

Revive Adserver before 3.2.3 suffers from Improper Restriction of Excessive Authentication Attempts. The login page of Revive Adserver is vulnerable to password-guessing attacks. An account lockdown feature was considered, but rejected to avoid introducing service disruptions to regular users during such attacks. A random delay has instead been introduced as a countermeasure in case of password failures, along with a system to discourage parallel brute forcing. These systems will effectively allow the valid users to log in to the adserver, even while an attack is in progress.

An attacker could send a specifically crafted payload to the XML-RPC invocation script and trigger the unserialize() call on the "what" parameter in the "openads.spc" RPC method. Such vulnerability could be used to perform various types of attacks, e.g. exploit serialize-related PHP vulnerabilities or PHP object injection. It is possible, although unconfirmed, that the vulnerability has been used by some attackers in order to gain access to some Revive Adserver instances and deliver malware through them to third party websites. This vulnerability was addressed in version 4.2.0.

Revive Adserver before 3.2.5 and 4.0.0 suffers from Reflected File Download. www/delivery/asyncspc.php was vulnerable to the fairly new Reflected File Download (RFD) web attack vector that enables attackers to gain complete control over a victim's machine by virtually downloading a file from a trusted domain.

Authorization bypass in Revive Adserver 5.5.2 and 6.0.1 and earlier versions causes an logged in attacker to change other users' email address and potentialy take over their accounts using the forgot password functionality.

Revive Adserver before 3.2.3 suffers from Cross-Site Request Forgery (CSRF). A number of scripts in Revive Adserver's user interface are vulnerable to CSRF attacks: www/admin/banner-acl.php, www/admin/banner-activate.php, www/admin/banner-advanced.php, www/admin/banner-modify.php, www/admin/banner-swf.php, www/admin/banner-zone.php, www/admin/tracker-modify.php.

Revive Adserver before 3.2.3 suffers from Cross-Site Request Forgery (CSRF). The password recovery form in Revive Adserver is vulnerable to CSRF attacks. This vulnerability could be exploited to send a large number of password recovery emails to the registered users, especially in conjunction with a bug that caused recovery emails to be sent to all the users at once. Both issues have been fixed.

Revive Adserver before 3.2.3 suffers from Cross-Site Request Forgery (CSRF). The Revive Adserver team conducted a security audit of the admin interface scripts in order to identify and fix other potential CSRF vulnerabilities. Over 20+ such issues were fixed.

Use of cryptographically weak PRNG in the password recovery token generation of Revive Adserver < v4.2.1 causes a potential authentication bypass attack if an attacker exploits the password recovery functionality. In lib/OA/Dal/PasswordRecovery.php, the function generateRecoveryId() generates a password reset token that relies on the PHP uniqid function and consequently depends only on the current server time, which is often visible in an HTTP Date header.

The login page of Revive Adserver v5.4.1 is vulnerable to brute force attacks.

Revive Adserver before 3.2.2 allows remote attackers to perform unspecified actions by leveraging an unexpired session after the user has been (1) deleted or (2) unlinked.

The default Flash cross-domain policy (crossdomain.xml) in Revive Adserver before 3.2.2 does not restrict access cross domain access, which allows remote attackers to conduct cross domain attacks via unspecified vectors.

Directory traversal vulnerability in delivery-dev/al.php in Revive Adserver before 3.2.2 allows remote attackers to include and execute arbitrary local files via a .. (dot dot) in the layerstyle parameter.

HackerOne community member Jad Ghamloush (0xjad) has reported an authorization bypass vulnerability in the tracker-delete.php script of Revive Adserver. Users with permissions to delete trackers are mistakenly allowed to delete trackers owned by other accounts.

Multiple cross-site request forgery (CSRF) vulnerabilities in Revive Adserver before 3.0.5 allow remote attackers to hijack the authentication of administrators for requests that (1) delete data via a request to agency-delete.php, (2) tracker-delete.php, or (3) userlog-delete.php in admin/ or (4) unlink accounts via a request to admin-user-unlink.php. (5) advertiser-user-unlink.php, or (6) affiliate-user-unlink.php in admin/.

The HTMLQuickform library, as used in Revive Adserver before 3.2.2, allows remote attackers to bypass the CSRF protection mechanism via an empty token.

Multiple cross-site request forgery (CSRF) vulnerabilities in Revive Adserver before 3.2.2 allow remote attackers to hijack the authentication of users for requests that (1) perform certain plugin actions and possibly cause a denial of service (disabled core plugins) via unknown vectors or (2) change the contact name and language or possibly have unspecified other impact via a crafted POST request to an account-user-.php script.

SQL injection vulnerability in ppc-add-keywords.php in Inout Adserver allows remote authenticated users to execute arbitrary SQL commands via the id parameter.

Improper neutralisation of input in Revive Adserver 6.0.0+ causes a reflected XSS attack in the banner-zone.php script.

Improper Neutralization of Input in Revive Adserver 5.5.2 and 6.0.1 and earlier versions causes a potential reflected XSS attack.

A reflected XSS vulnerability exists in Revive Adserver 5.4.1 and earlier versions..

Revive Adserver before 5.1.1 is vulnerable to a reflected XSS vulnerability in stats.php via the setPerPage parameter.

Revive Adserver before 5.1.1 is vulnerable to a reflected XSS vulnerability in userlog-index.php via the periodpreset parameter.

Revive Adserver before 5.1.0 is vulnerable to a reflected cross-site scripting (XSS) vulnerability via the publicly accessible afr.php delivery script. While this issue was previously addressed in modern browsers as CVE-2020-8115, some older browsers (e.g., IE10) that do not automatically URL encode parameters were still vulnerable.

Revive Adserver before 5.1.0 is vulnerable to open redirects via the dest, oadest, and/or ct0 parameters of the lg.php and ck.php delivery scripts. Such open redirects had previously been available by design to allow third party ad servers to track such metrics when delivering ads. However, third party click tracking via redirects is not a viable option anymore, leading to such open redirect functionality being removed and reclassified as a vulnerability.

A user having access to the UI of a Revive Adserver instance could be tricked into clicking on a specifically crafted admin account-switch.php URL that would eventually lead them to another (unsafe) domain, potentially used for stealing credentials or other phishing attacks. This vulnerability was addressed in version 4.2.0.

Improper neutralization of input in Revive Adserver 5.5.2 and 6.0.1 and earlier versions causes manager accounts to be able to craft XSS attacks to their own advertiser users.

Improper input neutralization in the stats-conversions.php script in Revive Adserver 5.5.2 and 6.0.1 and earlier versions causes potential information disclosure and session hijacking via a stored XSS attack.

Missing JSON Content-Type header in a script in Revive Adserver 6.0.1 and 5.5.2 and earlier versions causes a stored XSS attack to be possible for a logged in manager user.

HackerOne community member Kassem S.(kassems94) has reported that username handling in Revive Adserver was still vulnerable to impersonation attacks after the fix for CVE-2025-52672, via several alternate techniques. Homoglyphs based impersonation has been independently reported by other HackerOne users, such as itzhari and khoof.