Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/knadh/listmonk >= 1.1.1-0.20241028090858-319053dd7a90, < 1.1.1-0.20260329113754-1b5e8d38c778
Fixed in
1.1.1-0.20260329113754-1b5e8d38c778· Vendor fix available
Issue
A session management vulnerability allows previously issued authenticated sessions to remain valid after sensitive account security changes, specifically password reset and password change. As a result, an attacker who has already obtained a valid session cookie can retain access to the account even after the victim changes or resets their password. This weakens account recovery and session security guarantees. I reproduced the issue on listmonk v6.0.0. Details The application updates account credentials successfully, but existing active sessions are not revoked afterward. This behavior was confirmed in two flows: 1. Password reset flow - A user resets their password through the forgot/reset flow. - The old password becomes invalid. - The new password works. - However, a session cookie issued before the reset remains valid and continues to authenticate successfully. 2. Authenticated password change flow - The same user logs in from two separate sessions. - Using session A,…
Recommended action: Upgrade to 1.1.1-0.20260329113754-1b5e8d38c778 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/knadh/listmonk >= 1.1.1, < 6.0.0; < 1.1.1-0.20251231125615-74dc5a01cfbb
Fixed in
6.0.01.1.1-0.20251231125615-74dc5a01cfbb· Vendor fix available
Issue
Security Advisory: Stored XSS Leading to Admin Account Takeover Affected Versions: ≤ 5.1.0 Vulnerability Type: CWE-79: Stored Cross-Site Scripting --- Summary A lower-privileged user with campaign management permissions can inject malicious JavaScript into campaigns or templates. When a higher-privileged user (Super Admin) views or previews this content, the XSS executes in their browser context, allowing the attacker to perform privileged actions such as creating backdoor admin accounts. The attack can be weaponized via the public archive feature, where victims simply need to visit a link - no preview click required. --- Required Attacker Permissions Note: These are common permissions for content managers who are not full admins. --- Attack Vectors Vector 1: Raw HTML (Direct Script Tag) Vector 2: Go Template Safe Function --- Attack Scenarios Scenario 1: Campaign Preview Attack 1. Attacker creates campaign with XSS payload 2. Request is made to super admin: "Please review my…
Recommended action: Upgrade to 6.0.0 or 1.1.1-0.20251231125615-74dc5a01cfbb (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The env and expandenv template functions which is enabled by default in Sprig enables capturing of env variables on the host. While this may not be a problem on single-user (super admin) installations, on multi-user installations, this allows non-super-admin users with campaign or template permissions to use the {{ env }} template expression to capture sensitive environment variables. Upgrade to v5.0.2 to mitigate. --------- Demonstration Description A critical template injection vulnerability exists in Listmonk's campaign preview functionality that allows authenticated users with minimal privileges (campaigns:get & campaigns:getall) to extract sensitive system data, including database credentials, SMTP passwords, and admin credentials due to some dangerous function being allowed. Proof of Concept - Create a user and give him campaigns:get and campaigns:getall privileges - Now login with that user, go to any campaign, go the Content section and here lies the vulnerability,…
Recommended action: Upgrade to 5.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.