Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2025-56380 — 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. | Kitploit
Outils/GitHubGitHub/moalali/cve-2025-56380
Génération de PayloadsAnalyse des VulnérabilitésExploitationExploitation d'Applications WebTests d'IntrusionApprentissage et Éducation
GitHubmoalali/cve-2025-56380

CVE-2025-56380

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.

Voir le dépôt
il y a 10 moisPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

CVE-2025-56380 — Injection SQL aveugle basée sur le temps dans Frappe / ERPNext (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.


🛠 Détails techniques

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

    • Frappe — 15.72.4
    • ERPNext — 15.67.0 (même base de code affectée)
  • Composant affecté : méthode API frappe.client.get_value (frappe/client.py)

  • Point de terminaison vulnérable :

    root@kitploit:~
    /api/method/frappe.client.get_value
    

    Exemple de requête vulnérable :

    root@kitploit:~
    /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


🚀 Preuve de concept (PoC) — Injection SQL aveugle basée sur le temps

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

root@kitploit:~
GET /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893

Étapes pour confirmer

  1. Authentifiez-vous sur l'instance Frappe/ERPNext cible avec un utilisateur pouvant accéder à l'API de reporting/get_value.
  2. Envoyez la requête GET ci-dessus (ou une charge utile encodée URL équivalente).
  3. Observez le temps de réponse ; si la réponse est retardée d'environ 15 secondes, cela indique une injection temporelle réussie.
  4. Répétez la même requête pour confirmer la reproductibilité.
  5. Retirez la charge utile injectée +%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.


🧪 Vecteurs d'attaque et impact

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

    • Déni de service : Retards forcés dans la réponse du serveur (épuisement des ressources en cas d'abus).
    • Divulgation d'informations : Extraction aveugle de données via des techniques basées sur le temps (requêtes bitwise / conditionnelles au temps).
    • Manipulation de données : Capacité potentielle à modifier l'état de la base de données si d'autres vecteurs d'injection SQL sont disponibles.
    • Autre : Escalade de l'impact en fonction des privilèges de base de données disponibles pour l'utilisateur de l'application.

🔐 Recommandations d'atténuation

  1. Requêtes paramétrées / Instructions préparées : Assurez-vous que 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.
  2. Validation stricte des entrées / Listes blanches : Pour les paramètres censés être des noms de champs ou des identifiants, validez par rapport à une liste blanche stricte de noms de champs valides connus ou utilisez un mappage côté serveur plutôt que d'accepter des identifiants de champs bruts provenant des clients.
  3. Échappez les identifiants en toute sécurité : Si des identifiants doivent être utilisés dynamiquement, utilisez des fonctions de citation/échappement d'identifiants sûres et spécifiques à la base de données — et continuez de restreindre les valeurs autorisées.
  4. Compte de base de données à privilèges minimaux : Exécutez l'application avec un utilisateur de base de données ne disposant que des privilèges nécessaires (lecture seule si possible pour les points de terminaison de reporting).
  5. Limitation de débit et surveillance : Appliquez des limites de débit et détectez les modèles de requêtes anormaux ou les tests de délai répétés ; alertez sur le trafic suspect.
  6. Audit et journalisation : Consignez les requêtes vers les points de terminaison API sensibles et surveillez les charges utiles suspectes (par exemple, sleep, pg_sleep, benchmark, /, ;).
  7. Correctif et publication : Les développeurs de Frappe/ERPNext doivent auditer 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.

🔗 Références

  • Découvreur / Rapporteur : Mohammed Aloli — GitHub : https://github.com/MoAlali — X : https://x.com/alaliksa_ — LinkedIn : https://www.linkedin.com/in/mohammedaloli/
  • Bases de code Frappe / ERPNext (revue et correctif) : https://github.com/frappe/frappe , https://github.com/frappe/erpnext
  • Recommandations générales sur les injections SQL : OWASP SQL Injection Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

🙏 Remerciements

Découvert par Mohammed Aloli


📢 Avertissement

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.

Télécharger l’outil
fieldname
  • Tests de sécurité : Ajoutez des tests automatisés pour détecter l'injection SQL (y compris aveugle basée sur le temps) dans les points de terminaison API.