CVE-2026-71244 in Paperless-ngx
Summary
by MITRE • 08/05/2026
Paperless-ngx's MailAccountViewSet.test() action, when called with an existing account's ID and a masked password field, reuses the stored password, account_type, refresh_token, and expiration from that existing account while allowing the caller to supply a different imap_server, imap_port, and imap_security in the same request. The test connection then authenticates to the caller-specified server using the real stored credentials. A user holding only object-level change_mailaccount permission on the target account (not full admin) can redirect the test connection to an attacker-controlled IMAP host, causing the real stored IMAP password or OAuth token to be sent to that host.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability exists within Paperless-ngx's MailAccountViewSet.test() endpoint where the system fails to properly validate user permissions when processing test connection requests. The flaw stems from insufficient authorization checks that allow users with only change_mailaccount permission to manipulate critical connection parameters while retaining access to sensitive authentication credentials stored in the database. When a user submits a test request containing an existing account ID alongside a masked password field, the system incorrectly reuses stored credentials including passwords, account types, refresh tokens, and expiration dates while accepting new server configuration values such as imap_server, imap_port, and imap_security from the request payload.
The technical implementation of this vulnerability creates a privilege escalation scenario through what is known as a "credential exposure" attack pattern. The system's design flaw allows an attacker to leverage legitimate stored credentials to authenticate against an arbitrary IMAP server specified by the attacker, effectively bypassing normal access controls. This behavior directly violates the principle of least privilege as defined in CWE-250 and represents a classic case of insecure direct object reference where user input can be used to manipulate system behavior without proper validation.
The operational impact of this vulnerability is significant as it enables attackers with minimal permissions to conduct credential harvesting attacks against email accounts configured within Paperless-ngx. The attack vector allows for the redirection of authentication attempts to attacker-controlled servers, potentially exposing sensitive IMAP passwords or OAuth tokens that could be used for unauthorized access to email accounts. This threat model aligns with ATT&CK technique T1566 which describes credential harvesting through social engineering and system exploitation, while also mapping to T1078 which covers legitimate credentials usage.
The vulnerability can be exploited by users who possess object-level change_mailaccount permission but lack administrative privileges, creating a scenario where restricted access can be leveraged to compromise the security of email accounts. This represents a critical flaw in the application's authorization model as it fails to implement proper input validation and credential isolation during test connection operations. The system should enforce strict parameter validation and ensure that any modification to connection parameters requires elevated permissions or additional authentication factors.
Mitigation strategies should focus on implementing comprehensive access control checks before allowing credential reuse during test operations. The system must validate that users have appropriate authorization levels for all parameters being modified, including server configuration details. Additionally, the implementation should separate credential handling from parameter modification in test operations, ensuring that sensitive authentication data cannot be used to establish connections to arbitrary servers without additional verification. Proper logging and monitoring should be implemented to detect unusual connection patterns and potential exploitation attempts. The vulnerability also highlights the need for input sanitization and parameter validation to prevent unauthorized redirection of authentication flows as outlined in security best practices for web application development and secure coding standards.