Frappe Framework Blind SQL Injection in Event Retrieval

Frappe Framework before 16.33.0 contains a blind SQL injection vulnerability in the frappe.desk.doctype.event.event.get_events method, which fails to properly neutralize user-supplied input before including it in SQL queries. Authenticated attackers can send crafted input to get_events and infer query results from application behavior to extract sensitive database information.

• Frappe's frappe package: versions less than 16.33.0 are identified as affected.
• Version 16.33.0 is identified by the vendor advisory as patched and is marked unaffected in the record.
• The reviewed evidence does not establish the status of later versions or parallel release branches; that status should not be inferred from the stated patch alone.

Frappe Framework's frappe.desk.doctype.event.event.get_events method accepts user-supplied input and includes it in SQL queries without properly neutralizing special elements. This is a CWE-89 SQL injection flaw in which an attacker can infer query results from application behavior instead of receiving the query output directly. Exploitation requires an authenticated account and network reachability to the method; the supplied assessment indicates that no user interaction is required and that attack complexity is low. The available evidence does not identify the exact input parameter, SQL statement, database engine, or patch implementation.

The vulnerability is reachable over the network and requires authentication. The supplied assessment indicates that exploitation does not require user interaction and has low complexity. The technical description states that an attacker sends crafted input to get_events and infers query results from the application's behavior. The reviewed sources do not establish a public exploit, active exploitation, campaign, or specific indicator; those aspects should be treated as unknown rather than absent.

The flaw allows an authenticated attacker to infer database information through application behavior, creating a primary confidentiality risk. Low integrity impact is recorded in the structured assessment, but the public description does not explain whether data modification is possible, so arbitrary modification should not be assumed. No separate availability impact is described in the assessment. Actual exposure depends on the data reachable through the application's database query context and the privileges of the authenticated account.

An attacker with a valid account may use application responses to extract sensitive information from the database. This can expose business data or other information reachable through the application's database query context. The structured assessment records high confidentiality impact and low integrity impact, but the public narrative does not describe a separate write path or service-disruption path. The available evidence does not identify a specific victim, campaign, or breach.

1. Upgrade the frappe package to the exact confirmed patched release, 16.33.0.
2. Rebuild or redeploy services using the affected package, then verify that the runtime is using the updated package.
3. If updating cannot be completed immediately, treat the deployment as exposed. The vendor advisory states that there is no workaround; access restrictions should not be treated as a vendor-confirmed fix.
4. Reconcile each release branch and deployment artifact separately. Do not assume that every version after the stated patched release has been verified when the evidence does not cover it.

1. Inventory deployments using the frappe package and compare the runtime package state with the affected and fixed boundaries in the affected summary.
2. Identify applications, routes, or integrations that allow authenticated accounts to invoke functionality associated with frappe.desk.doctype.event.event.get_events.
3. Review application and access logs for repeated or unusual requests to event retrieval functionality, especially input showing possible SQL probing. This is precautionary monitoring, not a source-confirmed indicator.
4. Verify the package actually deployed in the runtime after updating, rather than checking only a lockfile or source tree. The absence of suspicious log activity does not prove that a deployment is safe.