CVE-2026-34828: listmonk Auth Bypass Vulnerability

CVE-2026-34828 Overview

CVE-2026-34828 is a session management vulnerability affecting listmonk, a standalone, self-hosted newsletter and mailing list manager. The vulnerability exists in versions 4.1.0 through versions prior to 6.1.0, where previously issued authenticated sessions remain valid after sensitive account security changes, specifically password reset and password change operations.

Critical Impact

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, completely undermining account recovery and session security guarantees.

Affected Products

• listmonk versions 4.1.0 to before 6.1.0
• Self-hosted listmonk newsletter manager deployments
• Environments with compromised or leaked session tokens

Discovery Timeline

• 2026-04-02 - CVE-2026-34828 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-34828

Vulnerability Analysis

This vulnerability is classified under CWE-613 (Insufficient Session Expiration). The core issue stems from listmonk's failure to invalidate existing user sessions when critical security events occur—specifically password changes and password resets. In a properly secured application, these security-sensitive operations should trigger immediate invalidation of all active sessions to prevent unauthorized persistent access.

When a user changes their password (whether through normal password change or password reset functionality), the application should treat all existing session tokens as potentially compromised. The vulnerable versions of listmonk failed to implement this session invalidation logic, allowing old session cookies to remain valid indefinitely.

Root Cause

The root cause is insufficient session lifecycle management in the authentication module. When a user's password is changed or reset, the application did not call any session invalidation routines, leaving previously authenticated sessions intact in the database. This architectural oversight means session tokens remain valid until their natural expiration, regardless of credential changes.

Attack Vector

The attack requires an adversary to first obtain a valid session cookie through various means such as session hijacking, cross-site scripting, network interception, or accessing a shared/public computer. Once the session is obtained:

1. The attacker gains authenticated access to the victim's listmonk account
2. The victim becomes aware of suspicious activity and changes their password
3. Despite the password change, the attacker's stolen session remains valid
4. The attacker retains persistent access to manage newsletters, mailing lists, and subscriber data

The following patch demonstrates how the vulnerability was addressed by adding session invalidation after password reset operations:

 		return echo.NewHTTPError(http.StatusInternalServerError, a.i18n.T("globals.messages.internalError"))
 	}
 
+	// Invalidate all existing sessions for the user after password reset.
+	if err := a.core.DeleteUserSessions(user.ID, ""); err != nil {
+		a.log.Printf("error destroying sessions after password reset for user_id=%d: %v", user.ID, err)
+	}
+
 	// Log the user in directly without forcing a manual login right after password change.
 	if err := a.auth.SaveSession(user, "", c); err != nil {
 		return err

Source: GitHub Commit Update

Similarly, the fix was applied to admin-initiated password changes in cmd/users.go:

 	// Blank out the password hash in the response.
 	user.Password = null.String{}
 
+	// If password was changed by admin, destroy all sessions for the given user.
+	if u.Password.String != "" {
+		if err := a.core.DeleteUserSessions(id, ""); err != nil {
+			a.log.Printf("error destroying sessions on admin password change for user_id=%d: %v", id, err)
+		}
+	}
+
 	// Cache the API token for in-memory, off-DB /api/* request auth.
 	if _, err := cacheUsers(a.core, a.auth); err != nil {
 		return err

Source: GitHub Commit Update

Detection Methods for CVE-2026-34828

Indicators of Compromise

• Multiple concurrent sessions from geographically disparate IP addresses for the same user account
• Session activity continuing after a recorded password change event in application logs
• Unusual administrative actions (subscriber list modifications, campaign changes) occurring from different client fingerprints than typical user behavior
• Database session records with timestamps predating recent password reset events

Detection Strategies

• Implement logging that correlates password change events with subsequent session usage to identify sessions that persist after credential updates
• Monitor for API requests authenticated with sessions created before the most recent password modification timestamp
• Deploy anomaly detection rules that flag continued authentication from known compromised session tokens after password reset workflows are triggered
• Review listmonk application logs for session-related errors or warnings that may indicate exploitation attempts

Monitoring Recommendations

• Enable verbose logging for authentication events including session creation, validation, and destruction
• Configure alerting on multiple failed login attempts followed by successful session usage from different source IPs
• Implement session tracking dashboards that visualize active sessions per user to identify anomalous patterns
• Monitor the sessions database table for records with creation timestamps older than recent password change events

How to Mitigate CVE-2026-34828

Immediate Actions Required

• Upgrade listmonk to version 6.1.0 or later immediately
• Force logout of all active user sessions after applying the patch by clearing the sessions table in the database
• Audit recent account activity for signs of unauthorized access, particularly accounts that recently changed passwords
• Notify users to review their account activity and change passwords again after the upgrade is applied

Patch Information

The vulnerability has been patched in listmonk version 6.1.0. The fix adds calls to DeleteUserSessions() in both the password reset flow (cmd/auth.go) and the admin password change flow (cmd/users.go), ensuring all existing sessions are invalidated when credentials are updated. For detailed patch information, see the GitHub Security Advisory GHSA-h5j9-cvrw-v5qh and the GitHub Release v6.1.0.

Workarounds

• If immediate upgrade is not possible, manually truncate or clear the sessions table after any password change or reset operation
• Implement a reverse proxy or WAF rule to invalidate session cookies based on password change timestamps stored in an external cache
• Reduce session token lifetime to minimize the window of exposure for stolen sessions
• Consider temporarily disabling password reset functionality until the patch can be applied

# Configuration example
# Manual session invalidation for PostgreSQL-based listmonk deployments
# Run after any password change if upgrade to 6.1.0 is not immediately possible

# Connect to listmonk database and clear all sessions
psql -U listmonk_user -d listmonk -c "DELETE FROM sessions WHERE user_id = <affected_user_id>;"

# Alternatively, clear all sessions system-wide (forces all users to re-authenticate)
psql -U listmonk_user -d listmonk -c "TRUNCATE TABLE sessions;"