A vulnerability classified as critical was found in code-projects Point of Sales and Inventory Management…

CVE-2025-0197 is an SQL injection flaw in code-projects Point of Sales and Inventory Management System affecting version 1.0, specifically the /user/search.php handler and its name parameter. The published PoC shows a crafted POST request against that endpoint, and both the CNA and NVD scoring indicate the attacker needs low privileges rather than being unauthenticated at the edge.

The vendor's MEDIUM label is technically reasonable in a vacuum, but it still overstates operational urgency for most enterprise patch queues. The decisive reality is friction: this is a niche PHP source-code project, commonly stood up in XAMPP-style lab deployments, and the exploit path starts after the attacker already has a valid session; that makes it a post-initial-access app bug with narrow real-world exposure, so I downgrade it to LOW for enterprise prioritization.

Why this verdict

• Start from 6.3 MEDIUM: the vendor baseline is fair for raw technical impact because SQLi can expose or alter application data.
• Authenticated remote access is required: PR:L means the attacker must already be inside the app. That is immediate downward pressure because it implies prior compromise, weak credential hygiene, or an exposed test account rather than direct perimeter break-in.
• Reachable population is probably small: this is not Exchange, Confluence, or a mainstream ERP. It is a code-projects PHP source package typically installed in ad hoc XAMPP-style environments, so the fraction of large enterprises meaningfully exposed is low.
• Blast radius is application-scoped: the likely win is the app database under whatever permissions that DB account has. There is no evidence in the advisory or PoC that this is a straight shot to host-level code execution.
• Threat intel does not amplify urgency: there is a public PoC, but there is no KEV listing and the supplied EPSS is very low, so exploitation interest looks opportunistic rather than operationally widespread.

Why not higher?

If this were unauthenticated SQLi in a widely deployed enterprise product, this would stay in the MEDIUM-to-HIGH lane. But the chain here is narrowed twice: you need app access first, and the app itself has a small enterprise footprint. That combination kills urgency.

Why not lower?

I am not calling this IGNORE because it is still a real, weaponizable SQL injection with a public PoC. If your org actually runs this app in production and exposes it to users, a low-privileged insider or attacker with stolen creds can absolutely dump or tamper with business data.

1. Remove public exposure — If this app is reachable from the internet, put it behind VPN, IP allowlisting, or retire the exposure entirely. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene, but if the app is public-facing do it immediately because exposure, not CVSS, is what makes this dangerous.
2. Constrain authenticated access — Limit login to named admins, enforce strong auth upstream, and kill shared/default accounts. There is no mitigation SLA for LOW, so handle it in routine hardening, but this is the most effective way to raise friction because the exploit starts after login.
3. Front it with SQLi-aware filtering — Deploy ModSecurity CRS or equivalent WAF rules for suspicious payloads hitting /user/search.php, especially the name POST field. This is not a substitute for code repair, but it is a practical guardrail when no vendor-fixed release is available.
4. Audit the DB account permissions — Reduce the application's MySQL privileges to the minimum tables and operations it truly needs. That turns a successful injection into a smaller incident by capping read/write scope.
5. Plan replacement or local code fix — Because no vendor patch was located, durable remediation is either decommissioning the app or editing the vulnerable PHP to use parameterized queries. For LOW, schedule it as backlog hygiene unless the instance handles sensitive data or is internet-accessible.

Run this on the target web server or in CI against the unpacked application source. Invoke it as python3 verify_cve_2025_0197.py /path/to/PISP or point directly at search.php; read access to the application files is sufficient, no admin privileges required unless your web root is restricted.

#!/usr/bin/env python3
# verify_cve_2025_0197.py
# Heuristic verifier for CVE-2025-0197 in code-projects Point of Sales and Inventory Management System 1.0
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

import os
import re
import sys

VULN_REL = os.path.join('user', 'search.php')

def read_file(path):
    try:
        with open(path, 'r', encoding='utf-8', errors='ignore') as f:
            return f.read()
    except Exception:
        return None

def locate_target(arg):
    if os.path.isfile(arg):
        return arg
    if os.path.isdir(arg):
        candidate = os.path.join(arg, VULN_REL)
        if os.path.isfile(candidate):
            return candidate
    return None

def main():
    if len(sys.argv) != 2:
        print('UNKNOWN')
        print('Usage: python3 verify_cve_2025_0197.py /path/to/project_or_search.php')
        sys.exit(3)

    target = locate_target(sys.argv[1])
    if not target:
        print('UNKNOWN')
        print('Could not locate user/search.php from supplied path')
        sys.exit(2)

    data = read_file(target)
    if data is None:
        print('UNKNOWN')
        print('Could not read target file')
        sys.exit(2)

    lower = data.lower()

    # Signals that suggest the vulnerable pattern:
    # 1) request parameter named 'name'
    # 2) SQL SELECT statement present
    # 3) concatenation/interpolation into query string
    # 4) no obvious prepared statement API in the file
    param_signal = bool(re.search(r"\$_(post|get|request)\s*\[\s*['\"]name['\"]\s*\]", data, re.I))
    select_signal = 'select' in lower and 'from' in lower
    concat_signal = bool(re.search(r"(select[\s\S]{0,300}(\.|concat\s*\(|\$[A-Za-z_][A-Za-z0-9_]*))", data, re.I))
    prepared_signal = any(x in lower for x in ['prepare(', 'bind_param(', 'pdo->prepare', 'mysqli_prepare'])

    # Strong vulnerable heuristic: tainted name parameter + query building + no prepared API
    if param_signal and select_signal and concat_signal and not prepared_signal:
        print('VULNERABLE')
        print(f'Heuristic match: {target} appears to use the name parameter in a dynamically built SQL query without prepared statements')
        sys.exit(1)

    # Strong patched heuristic: prepared statements present in the target file and the name parameter is handled
    if param_signal and prepared_signal:
        print('PATCHED')
        print(f'Prepared statement API detected in {target}; no obvious vulnerable pattern matched')
        sys.exit(0)

    print('UNKNOWN')
    print(f'File found at {target}, but the source pattern did not conclusively match vulnerable or patched logic')
    sys.exit(2)

if __name__ == '__main__':
    main()

Sources

1. NVD CVE-2025-0197
2. GitHub Gist PoC by Masamune
3. code-projects product / install page
4. OSV record for CVE-2025-0197
5. OpenCVE mirror of CNA data
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS