EUVD-2026-53317
GHSA-666w-8983-6664
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network API requiring low-privilege auth (change_mailaccount); no complexity beyond permission; full credential confidentiality loss; no integrity or availability impact.
Primary rating from Vendor (309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c).
CVSS VectorVendor: 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c
Lifecycle Timeline
1DescriptionCVE.org
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.
AnalysisAI
Credential exfiltration via SSRF in Paperless-ngx's mail account test endpoint allows an authenticated user holding only object-level change_mailaccount permission to redirect IMAP test connections to an attacker-controlled host, causing the application to transmit stored plaintext passwords or OAuth tokens to that host. The MailAccountViewSet.test() action accepts caller-supplied imap_server, imap_port, and imap_security parameters while silently reusing the real stored credentials when a masked password placeholder is submitted - a design flaw that converts a benign connectivity test into an unanticipated credential-forwarding primitive. No public exploit code has been identified and this CVE is not currently listed in the CISA KEV catalog.
Technical ContextAI
The vulnerability is rooted in CWE-918 (Server-Side Request Forgery), specifically a credential-forwarding variant where the application initiates an outbound connection on behalf of a caller but uses privileged stored secrets rather than caller-supplied credentials. The affected component is the Django REST Framework ViewSet action MailAccountViewSet.test() in paperless-ngx (GitHub: paperless-ngx/paperless-ngx). When this endpoint receives a request referencing an existing mail account ID with a masked password sentinel, it hydrates the request with the stored account_type, password, refresh_token, and expiration from the database - but accepts imap_server, imap_port, and imap_security directly from the request body without pinning them to the stored account values. The IMAP authentication then proceeds to the attacker-supplied host using the real credentials. The root cause is the asymmetric trust model: stored secrets are treated as protected while connection routing parameters are treated as user-controllable, with no validation that they match the account being tested. Affected CPE is not enumerated in the provided data; the product is the self-hosted paperless-ngx document management application.
RemediationAI
No vendor-released patch version has been identified in the available data; the sole reference is the upstream GitHub repository at https://github.com/paperless-ngx/paperless-ngx, which should be monitored for a fix release. As a primary compensating control, restrict the change_mailaccount permission to fully trusted administrators only - this eliminates the low-privilege exploitation path entirely. If granular object-level permissions must remain delegated to non-admin users, consider network-level controls that prevent the Paperless-ngx application server from making outbound IMAP connections to arbitrary hosts (e.g., egress firewall rules that allowlist only known mail server IPs), which would block the credential-forwarding step even if the malformed request is accepted. Note that restricting egress may break legitimate mail account testing against new servers, so coordinate with operators before enforcing it. Rotating stored IMAP passwords and OAuth tokens for all mail accounts as a precautionary measure is advisable if non-admin users have held change_mailaccount permission in a multi-user deployment.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today