SQL injection in bulk_update affects Frappe (vendor: frappe)

Frappe is a full-stack web application framework. Prior to 16.14.0 and 15.104.0, Frappe has a SQL injection in bulk_update. This vulnerability is fixed in 16.14.0 and 15.104.0.

The normalized affected data identifies these vulnerable ranges:

• frappe package: < 15.104.0.
• frappe package: >= 16.0.0-beta.1, < 16.14.0.

The vendor advisory displays the broader ranges <16.14.0 and <15.104.0; the structured record further bounds the 16.x affected branch to begin at 16.0.0-beta.1. The status of releases before 16.0.0-beta.1 and any other parallel branch is not established by the available evidence.

Frappe (vendor: frappe) has a SQL injection vulnerability in the bulk_update operation, classified as CWE-89. The flaw means data supplied to this operation can affect SQL command construction or execution, but the available evidence does not identify the exact parameter, statement, endpoint, or code path. The attack characteristics in the record describe a network-reachable path with low complexity, no authentication requirement, and no user interaction. This supports remote exposure for deployments where the vulnerable operation is reachable, but it does not establish a particular public URL or deployment configuration. The affected scope is limited to the release branches listed in affected_summary; the status of other branches is not established. The specific database engine behavior, database-account permissions, and tenant-isolation impact are not documented.

The record characterizes the vulnerability as reachable over the network, with low complexity, no authentication requirement, and no user interaction. The supplied record marks public_exploit as false and known_exploited as null. This does not prove that exploitation is impossible or has not occurred. The available evidence does not establish a public exploit, campaign, victim, or specific indicator.

Successful exploitation could allow unauthorized SQL operations within the permissions available to the application and its database account. Possible outcomes include unauthorized data disclosure, data modification or deletion, and degradation or loss of database-backed service. The record characterizes confidentiality, integrity, and availability impact as high, but it does not specify database privileges, application-authorization bypass, or the tenant scope of an attack. Organisational consequences could therefore range from data exposure or corruption to operational disruption, depending on deployment configuration.

An affected Frappe deployment could face unauthorized access to data, unauthorized data changes, or disruption of database-backed services. The actual harm depends on the database account permissions, the data accessible to the application, and the deployment's tenant-isolation design. Deployments with network-reachable Frappe functionality should be prioritized for inventory and upgrade. The available evidence does not name an intrusion, victim, or campaign, so it does not establish that a breach or operational outage has occurred.

1. For an affected 15.x branch, upgrade Frappe to exactly 15.104.0.
2. For an affected 16.x branch, upgrade Frappe to exactly 16.14.0.
3. The vendor advisory states that there is no workaround and directs users to upgrade to the patched versions. Network access restriction should not be treated as a fix; it may only reduce reachability as temporary defense in depth.
4. Recheck every environment and release branch after upgrading. A fix for one branch does not establish that other branches or parallel releases are unaffected.

1. Inventory every frappe package installation, including production, staging, and tenant environments, and compare each version with the affected ranges.
2. Identify deployments that use or expose the bulk_update functionality. The available evidence does not name a specific endpoint, so do not infer a URL to test.
3. Review application, reverse-proxy, and database logs for requests associated with bulk updates or unusual SQL errors. This is precautionary monitoring because the available sources provide no specific IOC or log signature.
4. After upgrading, recheck package metadata and verify that each release branch reaches its corresponding fixed version. The absence of suspicious log evidence does not prove that a system is safe.