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:

  root@kitploit:~

  /api/method/frappe.client.get_value
  

  Example vulnerable query:

  root@kitploit:~

  /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)

• 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):

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.

🔗 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.