Frappe Personal Data Download Request Response Discrepancy Enables User Enumeration

Frappe is a full-stack web application framework. Prior to 15.115.0 and 16.27.0, the public request-data web form and PersonalDataDownloadRequest class in frappe/website/doctype/personal_data_download_request/personal_data_download_request.py return distinguishable response shapes for registered and unregistered email addresses, including the user_name field and persistence behavior. A remote attacker can compare the responses to enumerate registered users. This issue is fixed in versions 15.115.0 and 16.27.0.

Frappe Framework is affected in the following branches:

• Branch 15: versions < 15.115.0 are affected. Version 15.115.0 is identified as fixed by the CNA and the vendor advisory.
• Branch 16: versions >= 16.0.0-beta.1, < 16.27.0 are affected. Version 16.27.0 is identified as fixed.
• The record does not establish the status of branches or parallel release lines outside these ranges. The corrective change was backported separately to the version-15-hotfix and version-16-hotfix branches.

Frappe processes attacker-supplied email addresses through the public request-data web form and the PersonalDataDownloadRequest class in frappe/website/doctype/personal_data_download_request/personal_data_download_request.py. Before the fix, requests for registered and unregistered email addresses produced distinguishable response shapes, including differences involving the user_name field and persistence behavior. An unauthenticated remote attacker can submit email addresses and compare the responses to determine which addresses are associated with Frappe users. This is a CWE-204, Observable Response Discrepancy. The patch keeps the response agnostic, removes user_name from the serialized response, and handles unknown users without creating a real database record; implementation details beyond these observed changes are not established.

The flaw is reachable over the network through the public request-data web form. The supplied record describes exploitation as requiring no prior privileges, no user interaction, and no special complexity. At a high level, an attacker submits different email addresses and compares the resulting response shapes, but this entry does not provide a payload or a weaponized exploit sequence. The supplied record does not identify a public exploit and does not confirm that the vulnerability has been exploited in the wild.

The direct technical outcome is that a remote user can infer account existence by observing differences between responses from the same public function. This weakens the confidentiality of the user population and may expose related response information involving user_name or persistence behavior in vulnerable releases. The flaw is not described as permitting data modification, arbitrary access to personal data, privilege escalation, or service disruption. The exposed account information can nevertheless make later targeted attacks more efficient.

The direct business impact is disclosure of whether an email address corresponds to an account on a Frappe deployment. This is account-identity leakage that could support phishing, credential-stuffing, or other targeting activity, although those follow-on outcomes are possible consequences rather than confirmed events in this record. The record does not establish data modification, service disruption, or account takeover. Organizations should prioritize public sites that expose the request-data function and process sensitive user populations.

1. Upgrade branch 15 deployments to 15.115.0 or branch 16 deployments to 16.27.0, according to the deployed branch. Do not generalize a fix for one branch to all other branches.
2. Verify that the running package and deployed source correspond to the fixed release, especially where hotfix branches or internally built packages are used.
3. The Frappe advisory states that there are no workarounds, so monitoring or obscuring the form should not be treated as a substitute for upgrading. If an immediate upgrade is not possible, temporarily restricting public access to the request-data function may reduce exposure where operationally appropriate, but this is a temporary exposure reduction rather than a confirmed fix.
4. After upgrading, test that registered and unregistered email submissions produce equivalent response structures, that user_name no longer creates an observable difference, and that requests for unknown users do not create unintended persistence.

1. Inventory deployed Frappe instances that expose the public request-data web form and record the framework version in use.
2. Check the deployed release branch against the affected boundaries in affected_summary, including beta or hotfix deployments on the 16 branch.
3. Review application or reverse-proxy logs for repeated requests to the public form using many different email addresses. This is precautionary monitoring, not a confirmed indicator of compromise.
4. If historical response data is available, check whether the form previously returned different structures for registered and unregistered addresses. The absence of such evidence in logs does not prove that a deployment was safe.
5. After upgrading, perform an authorized parity test with controlled test addresses and verify that the two input classes no longer produce distinguishable response shapes.