CVE-2026-34828: 
NixOS vulnerability analysis and mitigation

CVE-2026-34828 is an insufficient session expiration vulnerability in listmonk, a self-hosted newsletter and mailing list manager, that allows previously issued authenticated sessions to remain valid after a password reset or password change. Affecting versions 4.1.0 through 6.0.x, the flaw means an attacker who has captured a valid session cookie can retain persistent access to the account even after the victim attempts to recover it by changing credentials. The vulnerability was published on April 2, 2026, and patched in version 6.1.0. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, Feedly).

The root cause is CWE-613 (Insufficient Session Expiration): when a user resets or changes their password, the application updates credentials and consumes the reset token but does not revoke existing database-backed session records. The fix, introduced in commit db82035, added a DeleteUserSessions function that executes DELETE FROM sessions WHERE data->>'user_id' = $1 AND ($2 = '' OR id != $2) — purging all sessions for the affected user (optionally preserving the current session on self-initiated password change). Exploitation requires that an attacker has already obtained a valid session cookie through any prior means (e.g., XSS, malware, shared machine, proxy leakage), after which they can replay the cookie against authenticated endpoints such as GET /api/profile even post-password-reset (GitHub Advisory, Patch Commit).

An attacker holding a stolen session cookie can maintain unauthorized access to a listmonk account indefinitely, bypassing the victim's password reset or change as an account recovery mechanism. The primary impact is high confidentiality loss — the attacker can read all account data accessible via the API, including user profile information and potentially mailing list data — with low integrity impact from the ability to make authenticated API calls. Availability is not affected, and the scope is limited to the compromised user account; however, in multi-user deployments, admin accounts are equally at risk, potentially exposing broader administrative capabilities (GitHub Advisory, Feedly).

Public proof-of-concept (PoC) exploit code with step-by-step reproduction instructions is available on GitHub, including a dedicated PoC repository by researcher 0xmrma and detailed reproduction steps in the official security advisory (PoC Repository, GitHub Advisory). The vulnerability requires low privileges (a valid session cookie obtained through prior means) and no user interaction, making it straightforward to exploit once a session is captured. The EPSS score is 0.01% (very low), and there is no evidence of active in-the-wild exploitation or CISA KEV catalog listing as of the time of reporting (Feedly).

1. Session Capture: Obtain a valid listmonk session cookie for the target account through any prior means — e.g., XSS, malware on the victim's machine, network interception, or access to a shared/compromised browser.
2. Store the session cookie: Save the captured session=<value> cookie for later replay.
3. Wait for or trigger a password reset: Allow the victim to initiate a password reset (forgot-password flow) or change their password via the profile endpoint, which the attacker may monitor or anticipate.
4. Replay the old session cookie: Send an authenticated request to the listmonk API using the pre-reset session cookie:

   GET /api/profile HTTP/1.1
   Host: <target>:9000
   Cookie: session=<captured_value>

5. Confirm persistent access: Observe that the server returns HTTP/1.1 200 OK with the authenticated user's profile data, confirming the session remains valid despite the password change.
6. Leverage access: Use the persistent session to enumerate account data, modify mailing lists, access subscriber information, or perform any action the compromised account is authorized to perform (GitHub Advisory, PoC Repository).

• Network: Repeated authenticated API requests (e.g., GET /api/profile) originating from IP addresses or user agents inconsistent with the legitimate account owner's normal access patterns, particularly following a password reset event.
• Logs: listmonk access logs showing successful 200 OK responses to authenticated endpoints from session cookies that predate a recorded password change or reset event; concurrent authenticated sessions from geographically or temporally disparate sources for the same user account.
• Database: Presence of session records in the sessions table with created_at timestamps predating the most recent password change for the associated user_id, indicating sessions that should have been invalidated.
• Behavioral: Authenticated API activity (e.g., profile reads, list modifications) occurring immediately after a password reset with no corresponding new login event in the authentication logs (GitHub Advisory).

Upgrade listmonk to version 6.1.0 or later, which includes the fix that wipes all user sessions from the database upon password reset or password change (v6.1.0 Release, Patch Commit). As a temporary workaround prior to patching, administrators can manually delete rows from the sessions table in the PostgreSQL database for users who have recently changed or reset their passwords: DELETE FROM sessions WHERE data->>'user_id' = '<user_id>';. Users who suspect session compromise should also change their password after upgrading to ensure the new session invalidation logic takes effect (GitHub Advisory).

The vulnerability was reported by security researcher 0xmrma, who is credited in the official GitHub Security Advisory and also published a standalone PoC repository (GitHub Advisory, PoC Repository). The listmonk maintainer (knadh) acknowledged and patched the issue promptly in v6.1.0, noting it as an important security fix alongside other permission validation fixes in the release notes (v6.1.0 Release). No significant broader media coverage or notable social media discussion beyond standard CVE aggregator reporting was observed.