Exploit for 📄 Grocery Store Management System 1.0 SQL Injection CVE-2025-63943

## https://sploitus.com/exploit?id=PACKETSTORM:211630
# CVE-2025-63943 — SQL Injection in Grocery Store Management System 1.0
    
    ## Overview
    A high-severity **SQL Injection** vulnerability was identified in the `search_products.php` component of **Grocery Store Management System 1.0**, a PHP/MySQL-based web application created by *anirudhkannan*.  
    The issue arises from improper input validation and unsafe construction of SQL queries using the user-controlled `scost` parameter. This flaw enables attackers to manipulate the underlying SQL logic, potentially leading to sensitive data exposure, data alteration, or full compromise of the database.
    
    ---
    
    ## Affected Product
    - **Name:** Grocery Store Management System  
    - **Vendor:** anirudhkannan  
    - **Version:** 1.0  
    - **Repository:**  
      https://github.com/anirudhkannanvp/GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN-/tree/master  
    - **Affected File:**  
      `Grocery/search_products.php`
    
    ---
    
    ## Vulnerability Description
    The vulnerability exists due to the **direct concatenation of unvalidated user input** into SQL queries.  
    The `scost` POST parameter, intended to represent a numeric product cost value, is embedded into the SQL WHERE clause without:
    
    - Input sanitization  
    - Type enforcement  
    - Parameterized queries  
    - Prepared statement usage  
    
    This allows an attacker to inject **arbitrary SQL boolean expressions**, altering query behavior and extracting database contents using **boolean-based SQL Injection** techniques.
    
    The vulnerability is exploitable through a standard POST request to `search_products.php`. When malicious expressions are supplied, the backend returns measurable response differences (TRUE/FALSE variations), confirming that user input influences SQL logic.
    
    ---
    
    ## Root Cause
    - Lack of server-side validation on the `scost` input field  
    - Direct use of string concatenation for building SQL queries  
    - Absence of prepared statements in the affected code path  
    - No filtering or whitelisting for numeric input fields  
    
    These conditions collectively enable attackers to modify the intended SQL logic.
    
    ---
    
    ## Severity & Impact
    This vulnerability is rated **High** due to its low attack complexity, lack of authentication requirements, and full read/write database impact.
    
    ### Potential Impacts Include:
    - **Sensitive data exposure:** Attackers may extract product, user, or system data.  
    - **Data modification or deletion:** Injected SQL can alter or remove database entries.  
    - **Authentication bypass (possible):** If used in other parts of the application’s query logic.  
    - **Full database compromise:** Depending on DB privileges and configuration.  
    - **System instability:** Malicious queries could disrupt normal application behavior.
    
    ---
    
    ## CVSS v3.1 Score (Preliminary Assessment)
    **CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H**
    
    - **Attack Vector (AV):** Network  
    - **Attack Complexity (AC):** Low  
    - **Privileges Required (PR):** None  
    - **User Interaction (UI):** None  
    - **Scope (S):** Unchanged  
    - **Confidentiality (C):** High  
    - **Integrity (I):** High  
    - **Availability (A):** High  
    
    **Estimated Severity: High (9.8)**
    
    ---
    
    ## Exploitation Summary
    The vulnerability can be exploited through crafted values passed to the `scost` parameter.  
    Attackers can:
    
    - Influence boolean logic  
    - Trigger conditional responses  
    - Enumerate database structures  
    - Extract sensitive information  
    
    *(Detailed payloads are intentionally omitted to prevent misuse.)*
    
    ---
    
    ## Mitigation & Recommendations
    
    ### For Developers / Vendors
    To remediate the vulnerability:
    
    1. **Implement prepared statements / parameterized queries**  
    2. **Enforce strict input validation** — ensure `scost` accepts only numeric values  
    3. **Reject suspicious characters** — filter operators, quotes, comments, and expression symbols  
    4. **Apply least-privilege database permissions**  
    5. **Audit the codebase** for similar patterns elsewhere in the application  
    
    ### For Users
    Until a patch is available:
    
    - Restrict public access to the application  
    - Use a firewall or WAF to block malicious requests  
    - Monitor logs for unusual SQL-related behavior
    - 
    ---
    
    ## References
    - OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection  
    - CWE-89 — Improper Neutralization of Special Elements in SQL Commands