CVE-2025-3809 in Debug Log Manager <= 2.3.4 - Unauthenticated Stored Cross-Site Scripting

Recently, our team initiated a security review of «Debug Log Manager» (WordPress plugins). As part of this effort, we set up a new WordPress instance in Docker locally and began installing widely used plugins to test them in a controlled environment.

One of the plugins on our list was Debug Log Manager, a tool often used by developpers/administrators to manage and review PHP error logs directly from the admin dashboard.

The Initial Setup

We started with the latest available version of WordPress running in Docker. After deploying the environment, we installed the Debug Log Manager plugin, initially without suspecting any major issues. Our goal was simple: verify its functionality and ensure no security risks were introduced when parsing application logs.

Confirming the Vulnerability

During our testing, we attempted to generate controlled log entries. To do this, we leveraged another known vulnerability — CVE-2025-3436, a SQL Injection flaw previously discovered by the Haysec Team. (We will be publishing a detailed write-up of that finding in a separate article.), we used this injection as a way to insert controlled input into the WordPress debug log.

So, we tried to inject and provoke an SQL injection that would be logged and parsed into the debug log manager dashboard.

Payload: DESC'?phdddd');+?<img src=x onerror=alert(document.location)>.

The crafted payload was written into debug.log file and parsed directly in the Debug Log Manager Wordpress admin dashbord.

The Debug Log Manager plugin’s auto-refresh feature rendered the entry directly inside the admin dashboard — without sanitization or escaping. As a result, our injected script executed immediately when the log refreshed.

We want to thank Bowo, the plugin developer, for being extremely responsive and remediating the issue very quickly.

Recommendation:

• Update Debug Log Manager to version 2.3.5 or later immediately — and stay tuned for our upcoming write-up on CVE-2025-3436, where we’ll explain how that injection was first identified.