# CVE-2025-56380 โ€” Time-based Blind SQL Injection in Frappe / ERPNext (frappe.client.get_value) ๐Ÿ“Œ **Summary** A time-based blind SQL injection vulnerability was discovered in the `frappe.client.get_value` API endpoint in Frappe Framework v15.72.4 (and present in ERPNext v15.67.0 codebase). An authenticated user with access to the reporting/client API can inject SQL via the `fieldname` parameter. By inserting time-delay functions (e.g., `sleep(15)`) into the `fieldname` parameter, an attacker can confirm injection via measurable response delays โ€” enabling denial of service, information disclosure (via blind techniques), and data manipulation. --- ## ๐Ÿ›  Technical Details * **Vulnerability Type:** SQL Injection (time-based blind) (CWEโ€‘89) * **Affected Product(s):** Frappe Framework / ERPNext * **Affected Versions (reported):** * Frappe โ€” **15.72.4** * ERPNext โ€” **15.67.0** (same code base affected) * **Affected Component:** `frappe.client.get_value` API method (`frappe/client.py`) * **Vulnerable Endpoint:** ``` /api/method/frappe.client.get_value ``` Example vulnerable query: ``` /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893 ``` * **Vulnerable Parameter:** `fieldname` (improperly sanitized / concatenated into SQL) * **Attack Type:** Remote (requires authentication and access to the reporting API) * **Severity:** High (time-based blind SQLi enables data exfiltration, DoS, and manipulation) * **Estimated CVSS v3.1 Score:** **8.0 (High)** โ€” *estimate based on remote authentication-required SQL injection enabling data disclosure and DoS; authoritative scoring should be performed by assigners.* * **Status:** Not fixed (as reported) * **Discovered by:** Mohammed Aloli (GitHub: [https://github.com/MoAlali](https://github.com/MoAlali)) * **Date Discovered:** Not specified in report * **CVE ID:** **CVE-2025-56380** --- ## ๐Ÿš€ Proof of Concept (PoC) โ€” Time-based Blind SQLi > **Only test in authorized / lab environments. Do NOT run against systems you do not own or have explicit permission to test.** **PoC Request (example):** image ``` GET /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893 ``` **Steps to confirm** 1. Authenticate to the target Frappe/ERPNext instance with a user that can access the reporting/get_value API. 2. Send the above GET request (or equivalent URL-encoded payload). 3. Observe the response time; if response is delayed by ~15 seconds, this indicates successful time-based injection. 4. Repeat the same request to confirm reproducibility. 5. Remove the injected `+%2F+sleep(15)+&` payload and observe the response returns immediately โ€” confirming injection causes time delay. **Notes:** Replace `sleep(15)` with other time functions or time values suited to the backend DBMS (e.g., `pg_sleep(n)` for PostgreSQL) depending on DB engine. The PoC demonstrates blind injection via timing; more complex payloads could be used to extract data bit-by-bit. --- ## ๐Ÿงช Attack Vectors & Impact * **Attack vector:** Authenticated user crafts GET requests to `/api/method/frappe.client.get_value` with a malicious `fieldname` parameter containing SQL payloads (time delay functions). * **Impact:** * **Denial of Service:** Forced delays in server response (resource exhaustion if abused). * **Information Disclosure:** Blind extraction of data via time-based techniques (bitwise/time-conditional queries). * **Data Manipulation:** Potential ability to alter database state if other SQL injection vectors are available. * **Other:** Escalation of impact depending on DB privileges available to the application user. --- ## ๐Ÿ” Mitigation Recommendations 1. **Parameterized Queries / Prepared Statements:** Ensure the `fieldname` and all user-supplied input are never concatenated directly into SQL. Use parameterized queries or ORM APIs that properly bind parameters. 2. **Strict Input Validation / Whitelisting:** For parameters that should be field names or identifiers, validate against a strict allowlist of known valid field names or use server-side mapping rather than accepting raw field identifiers from clients. 3. **Escape Identifiers Safely:** If identifiers must be used dynamically, use safe DB-specific identifier quoting/escaping functions โ€” and *still* restrict allowed values. 4. **Least Privilege DB Account:** Run the application with a database user that has only necessary privileges (read-only where possible for reporting endpoints). 5. **Rate-limiting & Monitoring:** Apply rate limits and detect anomalous request patterns or repeated time-delay tests; alert on suspicious traffic. 6. **Audit & Logging:** Log requests to sensitive API endpoints and monitor for suspicious payloads (e.g., `sleep`, `pg_sleep`, `benchmark`, `/`, `;`). 7. **Patch & Release:** Frappe/ERPNext developers should audit `frappe.client.get_value` and the code path handling `fieldname`/filters, replace unsafe concatenation with safe APIs, and release a security patch. Operators should apply updates promptly. 8. **Security Testing:** Add automated tests to detect SQL injection (including time-based blind) in API endpoints. --- ## ๐Ÿ”— References * Discoverer / Reporter: Mohammed Aloli โ€” GitHub: `https://github.com/MoAlali` โ€” X: `https://x.com/alaliksa_` โ€” LinkedIn: `https://www.linkedin.com/in/mohammedaloli/` * Frappe / ERPNext codebases (review and patch): `https://github.com/frappe/frappe` , `https://github.com/frappe/erpnext` * General SQLi guidance: OWASP SQL Injection Cheat Sheet โ€” `https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html` --- ## ๐Ÿ™ Acknowledgments Discovered by **Mohammed Aloli** --- ## ๐Ÿ“ข Disclaimer This information is provided for defensive and remediation purposes only. Do **not** attempt to exploit this vulnerability against systems you do not own or do not have explicit authorization to test. Operators should prioritize patching, apply secure coding fixes, and follow the mitigation guidance above.