Information Disclosure in Revive Adserver v6.0.0 via Verbose Errors

Disclaimer

This article is published strictly for educational and defensive security purposes.
All testing described was performed under authorized conditions or responsible disclosure programs.
The goal of this write-up is to help developers, defenders, and security learners understand why information disclosure vulnerabilities matter and how to prevent them.

Introduction

Not every serious vulnerability begins with a complex exploit chain or advanced payloads.
Sometimes, the most damaging weaknesses are exposed through something far more ordinary: error messages.

In this case, a security researcher identified an information disclosure vulnerability in Revive Adserver v6.0.0, where a single malformed input caused the application to reveal raw SQL queries, database versions, PHP runtime details, and internal logic.

This write-up walks through how the issue was discovered, why it is dangerous, and how similar misconfigurations continue to put real-world systems at risk.

What is Revive Adserver?

Revive Adserver is a widely used open-source ad management platform that allows publishers and advertisers to manage, track, and deliver online advertisements.

Because it is commonly deployed in:

• Advertising networks
• Publisher infrastructures
• Marketing platforms

any vulnerability affecting Revive Adserver has the potential to impact multiple organizations at once.

Vulnerability Summary

Target: Revive Adserver v6.0.0
Vulnerability Type: Information Disclosure via Verbose Error Messages
CWE: CWE-209 (Information Exposure Through an Error Message)
Reporter: yoyomiski

The application returned detailed backend error messages directly to the client, exposing internal implementation details that should never be visible in production environments.

Technical Breakdown

Step 1 – Accessing the Vulnerable Functionality

The issue was identified within the Revive Adserver admin panel.

After logging in with a valid user account, the researcher navigated to the channel access control configuration page:

http://<target-ip>/admin/channel-acl.php?affiliateid=<id>&channelid=<id>

This page allows administrators to define delivery rules for advertising channels, such as:

• Browser conditions
• Language restrictions
• Execution order logic

Step 2 – Manipulating the Input

Within the form, there is a field labeled Execution order.
Under normal circumstances, this field expects a numeric value such as 1 or 2.

Instead of providing a number, the researcher entered a single quote:

'

This is one of the most basic malformed inputs commonly used to test how applications handle unexpected values.

Step 3 – Intercepting the Request

The request was intercepted using an HTTP proxy (such as Burp Suite) while saving the form.

POST /admin/channel-acl.php HTTP/1.1
Host: 192.168.109.200
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.109.200/admin/channel-acl.php
Cookie: sessionID=<session>

acl[1][executionorder]='

This malformed parameter was sufficient to trigger a backend error during SQL execution.

Step 4 – Verbose Error Disclosure

Instead of handling the error gracefully, the application returned a detailed error message directly in the HTTP response.

The response revealed:

• MariaDB version: 10.6.22-MariaDB-0ubuntu0.22.04.1
• PHP version: 8.4.13
• Raw SQL query structure:

INSERT INTO rv_acls_channel (channelid, logical, type, comparison, data, executionorder) VALUES (...)

• Internal table and column names
• Execution logic details

This single response effectively provided an attacker with a blueprint of the backend environment.

Why This Is Dangerous

1. Backend Stack Exposure

By leaking precise version numbers, attackers can:

• Identify known vulnerabilities for specific PHP or database versions
• Tailor exploit payloads with high accuracy
• Reduce guesswork during reconnaissance

2. SQL Query and Schema Leakage

Exposing raw SQL queries reveals:

• Table names
• Column names
• Logical relationships
• Query execution patterns

This significantly lowers the barrier for SQL injection, logic abuse, or privilege escalation attempts later on.

3. Internal Application Behavior Disclosure

Verbose errors often leak:

• File paths
• Library references
• Function calls
• Code execution flow

These details are frequently used to chain vulnerabilities into LFI, RCE, or authentication bypasses.

Root Cause Analysis

The core issue stems from improper error handling.

The application directly echoed database and PHP error objects back to the client, likely due to:

• Debug mode enabled in production
• Misconfigured PHP error reporting
• Lack of centralized error logging

// Insecure practice
echo $db->error;

Instead of:

// Secure practice
logError($db->error);
showGenericErrorMessage();

Defensive Perspective – How This Should Be Fixed

1. Disable Verbose Errors in Production

• Set display_errors = Off in php.ini
• Use environment-based error reporting
• Never expose stack traces to users

2. Implement Generic Error Messages

Users should see messages like:

“An unexpected error occurred. Please try again later.”

No versions. No SQL. No stack traces.

3. Treat All Inputs as Untrusted

Even admin-only fields must be validated and sanitized.

• Use prepared statements
• Enforce strict input types
• Reject malformed values early

4. Hide Version Information

Remove technology disclosures from:

• HTTP headers
• Error responses
• Application footers

For web servers:

ServerTokens Prod
ServerSignature Off

5. Centralized Error Logging

Log detailed errors server-side only using:

• Sentry
• ELK Stack
• Graylog

This preserves debugging capability without exposing attackers to sensitive data.

How Bug Hunters Identify Similar Issues

Security researchers often look for:

• Numeric fields accepting non-numeric input
• Unexpected 500 errors
• SQL syntax hints in responses
• Version strings in error pages

Common test payloads include:

'
"
)
;

Sometimes, a single character is all it takes.

Conclusion

Information disclosure vulnerabilities are often underestimated, yet they form the foundation of real-world attack chains.

In Revive Adserver v6.0.0, a simple malformed input exposed:

• Database versions
• SQL logic
• Backend environment details

While the vulnerability may appear “low impact” in isolation, its real danger lies in what it enables next.

The takeaway is clear:

Silence your errors before your errors expose you.

Final Thoughts

This case reinforces an important security principle:

The absence of visible breakage does not mean the absence of risk.

Sometimes, the most dangerous vulnerabilities are the quiet ones - hiding inside error messages no one bothered to silence.