A vulnerability has been found in code-projects Point of Sales and Inventory Management System 1

CVE-2025-0200 is an SQL injection flaw in code-projects Point of Sales and Inventory Management System 1.0, specifically /user/search_num.php. The CNA/NVD description says the vulnerable argument is search, while the public PoC uses the name POST field with a valid PHPSESSID; either way, the issue is the same: user-controlled input is fed into SQL without safe parameterization. The product page describes a login-driven PHP/XAMPP app with user, supplier, and admin roles, so this is not a clean unauthenticated edge bug.

Vendor MEDIUM 6.3 is a fair technical baseline, but it is still too hot for patch triage at enterprise scale. The real-world brakes are strong: the bug needs authenticated access, hits a niche training/sample-code PHP app that is commonly run on localhost/XAMPP, has only partial CIA impact, and there is no evidence here of broad internet exploitation or KEV status. Public PoC code keeps it from being ignorable, but this is post-auth app abuse, not a fleet emergency.

Why this verdict

• Start at vendor 6.3 MEDIUM: technically fair for remote SQLi, but that baseline assumes the target is meaningfully exposed and reachable
• Downgrade for attacker position: PR:L means the attacker needs a valid session first; that implies prior access, weak account controls, or insider status before the SQLi even matters
• Downgrade for exposure population: this is a small PHP/XAMPP source-code project, not a common enterprise platform, so the reachable population is likely tiny compared with products that justify aggressive internet-facing patch SLAs
• Downgrade for impact ceiling: available scoring and CISA ADP both point to partial impact and no automation; there is no evidence here of pre-auth takeover or direct RCE
• Slight uplift for exploitability evidence: there is a public PoC gist, so defenders should not dismiss it as purely theoretical if they actually run this app

Why not higher?

To score higher, this would need one of the usual amplifiers: unauthenticated reachability, strong evidence of internet exposure at scale, active exploitation, or code execution. Instead, the chain begins with a login requirement and appears to end in application-database abuse, which sharply narrows both attacker population and business blast radius.

Why not lower?

It is still a genuine SQL injection with a public PoC, not a paper cut. If an organization really does expose this app and allows broad user access, a low-privileged account can likely read or tamper with application data, so IGNORE would be too complacent.

1. Remove public exposure — If this app is reachable from the internet, move it behind VPN, IP allowlisting, or an internal reverse proxy. For a LOW verdict there is no noisgate mitigation SLA; treat this as backlog hygiene, but do it promptly if the app is externally exposed because exposure is the main amplifier.
2. Require strong authentication — Reduce the chance that a commodity attacker can satisfy the PR:L prerequisite. Use unique local accounts at minimum, and if this app matters operationally, front it with SSO/MFA; LOW has no formal mitigation SLA, so this is risk reduction rather than an emergency control.
3. Add a WAF SQLi rule set — Basic SQLi signatures can block the simple public PoC and slow down sqlmap, especially on legacy PHP apps you cannot quickly fix. This is not a substitute for code remediation, but it buys coverage while the issue sits in backlog hygiene.
4. Constrain DB privileges — Ensure the PHP application's DB account has only the minimum rights needed for the app schema and nothing broader. That limits the blast radius if exploitation occurs and is especially useful where no vendor-fixed version is clearly available.
5. Monitor authenticated search endpoints — Alert on SQLi markers, abnormal POSTs to /user/search_num.php, and sqlmap-like probing patterns. With a LOW verdict there is no SLA-driven mitigation window, so detection is your main short-term safety net if the app must stay online.

Run this on the target web server or on a workstation that has filesystem access to the deployed app directory. Invoke it as python3 verify_cve_2025_0200.py /var/www/html/POS_inventory or py verify_cve_2025_0200.py C:\xampp\htdocs\POS_inventory; no admin rights are required unless the files are permission-restricted.

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

import os
import re
import sys

TARGET_REL = os.path.join('user', 'search_num.php')


def println(msg):
    sys.stdout.write(msg + '\n')


def main():
    if len(sys.argv) != 2:
        println('UNKNOWN')
        sys.exit(2)

    base = sys.argv[1]
    target = os.path.join(base, TARGET_REL)

    if not os.path.isfile(target):
        println('UNKNOWN')
        sys.exit(2)

    try:
        with open(target, 'r', encoding='utf-8', errors='ignore') as fh:
            data = fh.read()
    except Exception:
        println('UNKNOWN')
        sys.exit(2)

    lower = data.lower()

    # Signals of parameterized queries / safer handling
    patched_signals = [
        '->prepare(',
        'mysqli_prepare(',
        'bind_param(',
        'bindparam(',
        'bindvalue(',
        'execute(['
    ]

    # Signals of direct use of user input in a SQL string
    vuln_input_signals = [
        "$_post['name']",
        '$_post["name"]',
        "$_post['search']",
        '$_post["search"]',
        '$search',
        '$name'
    ]

    sql_signals = ['select ', ' from ', ' where ', ' like ', 'mysqli_query(', 'query(']

    has_patched = any(s in lower for s in patched_signals)
    has_input = any(s in lower for s in vuln_input_signals)
    has_sql = any(s in lower for s in sql_signals)

    # Look for likely concatenation/interpolation into SQL
    concat_patterns = [
        r"select.+\$search",
        r"select.+\$name",
        r"like\s*['\"]?%?\s*\.\s*\$search",
        r"like\s*['\"]?%?\s*\.\s*\$name",
        r"mysqli_query\s*\(.+select",
        r"query\s*\(.+select"
    ]
    has_concat_pattern = any(re.search(p, lower, re.DOTALL) for p in concat_patterns)

    if has_patched and not has_concat_pattern:
        println('PATCHED')
        sys.exit(0)

    if has_sql and (has_input or has_concat_pattern) and not has_patched:
        println('VULNERABLE')
        sys.exit(1)

    println('UNKNOWN')
    sys.exit(2)


if __name__ == '__main__':
    main()

Sources

1. NVD entry for CVE-2025-0200
2. OpenCVE mirror of the CNA/CISA-enriched record
3. Public PoC by Masamune
4. Vendor project page / deployment guidance
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. VulDB reference listed by the CNA