
Frappe Framework v15.72.4 s'est avéré contenir une vulnérabilité d'injection SQL via le paramètre fieldname dans le point de terminaison API frappe.client.get_value.
📌 Résumé
Une vulnérabilité d'injection SQL aveugle basée sur le temps a été découverte dans le point de terminaison API frappe.client.get_value de Frappe Framework v15.72.4 (et présente dans la base de code ERPNext v15.67.0). Un utilisateur authentifié ayant accès à l'API de reporting/client peut injecter du SQL via le paramètre fieldname. En insérant des fonctions de délai temporel (par exemple, sleep(15)) dans le paramètre fieldname, un attaquant peut confirmer l'injection via des délais de réponse mesurables — permettant un déni de service, une divulgation d'informations (via des techniques aveugles) et une manipulation des données.
Type de vulnérabilité : Injection SQL (aveugle basée sur le temps) (CWE‑89)
Produit(s) affecté(s) : Frappe Framework / ERPNext
Versions affectées (signalées) :
Composant affecté : méthode API frappe.client.get_value (frappe/client.py)
Point de terminaison vulnérable :
/api/method/frappe.client.get_value
Exemple de requête vulnérable :
/api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893
Paramètre vulnérable : fieldname (mal assaini / concaténé dans le SQL)
Type d'attaque : À distance (nécessite une authentification et un accès à l'API de reporting)
Gravité : Élevée (l'injection SQL aveugle basée sur le temps permet l'exfiltration de données, un déni de service et la manipulation)
Score CVSS v3.1 estimé : 8.0 (Élevé) — estimation basée sur une injection SQL à distance nécessitant une authentification, permettant la divulgation de données et un déni de service ; le score faisant autorité doit être établi par les organismes d'attribution.
Statut : Non corrigé (selon le rapport)
Découvert par : Mohammed Aloli (GitHub : https://github.com/MoAlali)
Date de découverte : Non précisée dans le rapport
Identifiant CVE : CVE-2025-56380
Testez uniquement dans des environnements autorisés / de laboratoire. N'exécutez PAS de tests contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de tester.
Requête PoC (exemple) :

GET /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893
Étapes pour confirmer
+%2F+sleep(15)+& et observez que la réponse revient immédiatement — confirmant que l'injection provoque le délai.Remarques : Remplacez sleep(15) par d'autres fonctions temporelles ou valeurs de délai adaptées au SGBD back-end (par exemple, pg_sleep(n) pour PostgreSQL) selon le moteur de base de données. Le PoC démontre une injection aveugle via la temporisation ; des charges utiles plus complexes pourraient être utilisées pour extraire des données bit par bit.
Vecteur d'attaque : Un utilisateur authentifié forge des requêtes GET vers /api/method/frappe.client.get_value avec un paramètre fieldname malveillant contenant des charges utiles SQL (fonctions de délai temporel).
Impact :
fieldname et toutes les entrées fournies par l'utilisateur ne sont jamais concaténées directement dans le SQL. Utilisez des requêtes paramétrées ou des API ORM qui lient correctement les paramètres.sleep, pg_sleep, benchmark, /, ;).frappe.client.get_value et le chemin de code gérant /filters, remplacer la concaténation non sécurisée par des API sûres, et publier un correctif de sécurité. Les exploitants doivent appliquer les mises à jour rapidement.https://github.com/MoAlali — X : https://x.com/alaliksa_ — LinkedIn : https://www.linkedin.com/in/mohammedaloli/https://github.com/frappe/frappe , https://github.com/frappe/erpnexthttps://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.htmlDécouvert par Mohammed Aloli
Ces informations sont fournies à des fins défensives et de remédiation uniquement. N'essayez pas d'exploiter cette vulnérabilité contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de tester. Les exploitants doivent donner la priorité aux correctifs, appliquer les corrections de codage sécurisé et suivre les recommandations d'atténuation ci-dessus.
fieldname