CVE-2026-92806 in phpList
Summary
by MITRE • 09/16/2026
phpList versions before 3.6.17 fail to validate cross-site request forgery tokens in the mass subscriber removal form handler. Attackers can induce logged-in administrators to visit crafted pages that silently delete and blacklist arbitrary subscriber addresses without authentication verification.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in phpList versions prior to 3.6.17 represents a critical failure in access control mechanisms, specifically concerning Cross-Site Request Forgery protections within the administrative interface. As an open-source email marketing platform widely deployed for managing subscriber lists and sending bulk communications, phpList relies on authenticated administrators to perform sensitive operations such as modifying user data. The specific flaw resides in the mass subscriber removal form handler, which processes requests to delete or blacklist subscribers from the database without adequately verifying that the request originated from a legitimate session initiated by an authorized administrator. This absence of anti-CSRF token validation allows external actors to craft malicious web pages containing hidden forms or automated scripts that submit deletion commands directly to the phpList application while the victim is logged in, effectively bypassing authentication checks for these specific administrative actions.
From a technical perspective, this vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery as an attack that forces an end user to execute unwanted actions on a trusted web application in which they are currently authenticated. The attacker does not need to steal session cookies or credentials; instead, they exploit the trust that the server places in the browser's automatic inclusion of authentication cookies with every request made by the logged-in user. By inducing the administrator to visit a malicious page, often through social engineering tactics such as embedding the attack vector in an email or a compromised website link, the attacker can trigger state-changing requests silently and without any visual indication to the victim that their administrative privileges are being abused. The lack of unique per-session tokens ensures that the server cannot distinguish between a request initiated by the user's own browser actions and one forged by an external party.
The operational impact of this vulnerability is severe, particularly for organizations relying on phpList for legitimate marketing or communication purposes. An attacker with sufficient knowledge of the application structure can silently delete large numbers of subscriber addresses from the database, leading to significant data loss and disruption of ongoing campaigns. Furthermore, the ability to blacklist arbitrary email addresses allows an adversary to manipulate recipient lists in ways that could harm the organization's reputation or interfere with business continuity. Since these actions are performed under the context of a logged-in administrator, they carry full privileges within the application scope, meaning there is no audit trail distinguishing them from legitimate administrative changes made by the actual user. This undermines the integrity and availability aspects of the CIA triad for the email marketing infrastructure.
To mitigate this vulnerability, organizations running phpList versions before 3.6.17 must upgrade to version 3.6.17 or later immediately, as these newer releases implement proper CSRF token validation mechanisms that ensure each state-changing request is associated with a valid, server-generated session token. For environments where immediate upgrading is not feasible due to compatibility constraints, temporary mitigations include enforcing strict Content Security Policy headers to restrict form submissions and implementing network-level controls such as requiring same-site cookies or validating the Origin header on administrative endpoints. Additionally, enabling multi-factor authentication for all administrator accounts adds a layer of defense-in-depth, although it does not directly prevent CSRF attacks if the session remains active during the attack window. Regular security audits and adherence to OWASP guidelines for web application security are recommended to identify similar flaws in other parts of the application logic. This incident highlights the importance of rigorous input validation and state management practices in all administrative interfaces that handle sensitive data modifications, ensuring that every action requiring privilege escalation or data alteration is protected by robust anti-CSRF measures consistent with industry standards like those outlined in ATT&CK technique T1556 for modifying authentication processes.