A vulnerability

CVE-2025-0198 is an SQL injection in code-projects Point of Sales and Inventory Management System 1.0, specifically in /user/search_result.php via the id parameter. The vulnerable code path sits under the product's user area, and the CNA/NVD scoring already reflects PR:L, meaning the attacker needs at least low-privileged authenticated access before they can send the injected request.

The vendor's MEDIUM 6.3 is already a bit generous for enterprise prioritization, and reality pushes it lower. Yes, there is a public PoC, but the friction stack is substantial: authenticated access, a niche and lightly maintained educational PHP app, unclear internet-facing population, no KEV listing, and a very low EPSS. That makes this a real defect with local blast radius inside the application database, not a broad internet-scale emergency.

Why this verdict

• Start at 6.3, then subtract for attacker position: PR:L means the exploit chain begins with authenticated remote access, not cold-start internet compromise.
• Subtract again for exposure population: this is a niche, educational PHP POS app with unclear enterprise footprint, so the reachable population is far narrower than a mainstream edge product.
• Subtract for threat reality: public PoC exists, but KEV is negative and EPSS is extremely low, which says attackers are not broadly prioritizing this bug.
• Keep it above IGNORE because it is still SQLi: once logged in, an attacker can likely read or alter app data with low friction.

Why not higher?

There is no evidence of unauthenticated exploitation, no evidence of RCE, and no evidence of active campaigns. Requiring a valid session means modern controls like MFA, VPN gating, SSO, and basic network segmentation can remove most of the practical risk before the vulnerable code is ever reached.

Why not lower?

This is still a genuine SQL injection with a published PoC against a live endpoint. If you do expose this app externally or if an attacker already has credentials, data theft and record tampering inside the POS database are plausible and cheap.

1. Pull it off the internet — If any instance is externally reachable, put it behind VPN, an internal reverse proxy, or an allowlist. For a LOW verdict there is no noisgate mitigation SLA; treat this as backlog hygiene, but do it promptly on any internet-facing instance because exposure matters more than the raw CVSS here.
2. Gate access with strong auth — Enforce SSO, MFA where possible, and remove shared/default accounts so attackers cannot satisfy the PR:L prerequisite cheaply. For LOW, there is no formal mitigation SLA, but this is the highest-value control because authenticated access is the whole exploit hinge.
3. Add a targeted WAF rule — Create parameter-specific blocking or normalization for /user/search_result.php and the id parameter, including quotes, comment markers, boolean tautologies, and time-delay payloads. This is a good stopgap when no confirmed vendor patch exists.
4. Audit app database privileges — Reduce the web app's database account to the minimum read/write scope needed by the POS workflow. That will not fix the injection, but it can turn a full schema dump into a smaller disclosure event.
5. Retire or replace the app — This project shows signs of being old, educational, and lightly maintained. Since no authoritative fixed version was found, the durable answer is replacement or internal-only containment rather than waiting for a mature patch stream.

Run this on the web server or a source checkout of the application, not from an auditor workstation. Invoke it with the application root path, for example python3 verify_cve_2025_0198.py /var/www/html/PISP or py verify_cve_2025_0198.py C:\xampp\htdocs\PISP; it only needs read access to the application files.

#!/usr/bin/env python3
# verify_cve_2025_0198.py
# Detect likely vulnerable code-projects Point of Sales and Inventory Management System 1.0 SQLi
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import re
import sys

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

SQL_PATTERNS = [
    re.compile(r"select\s+.*from", re.I | re.S),
    re.compile(r"mysql_query\s*\(", re.I),
    re.compile(r"mysqli_query\s*\(", re.I),
    re.compile(r"->query\s*\(", re.I),
    re.compile(r"prepare\s*\(", re.I),
]

ID_PATTERNS = [
    re.compile(r"\$_GET\s*\[\s*['\"]id['\"]\s*\]", re.I),
    re.compile(r"\$_REQUEST\s*\[\s*['\"]id['\"]\s*\]", re.I),
]

SAFE_PATTERNS = [
    re.compile(r"prepare\s*\(", re.I),
    re.compile(r"bind_param\s*\(", re.I),
    re.compile(r"intval\s*\(\s*\$_(?:GET|REQUEST)\s*\[\s*['\"]id['\"]\s*\]\s*\)", re.I),
    re.compile(r"\(int\)\s*\$_(?:GET|REQUEST)\s*\[\s*['\"]id['\"]\s*\]", re.I),
    re.compile(r"filter_input\s*\(\s*INPUT_GET\s*,\s*['\"]id['\"]\s*,\s*FILTER_VALIDATE_INT", re.I),
]


def print_result(state, msg, code):
    print(f"{state}: {msg}")
    sys.exit(code)


def main():
    if len(sys.argv) != 2:
        print("Usage: python3 verify_cve_2025_0198.py <app_root>")
        sys.exit(2)

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

    if not os.path.exists(root):
        print_result("UNKNOWN", f"Application root not found: {root}", 2)

    if not os.path.isfile(target):
        print_result("UNKNOWN", f"Target file not found: {target}", 2)

    try:
        with open(target, 'r', encoding='utf-8', errors='ignore') as fh:
            data = fh.read()
    except Exception as e:
        print_result("UNKNOWN", f"Could not read {target}: {e}", 2)

    has_id_source = any(p.search(data) for p in ID_PATTERNS)
    has_sql = any(p.search(data) for p in SQL_PATTERNS)
    has_safe = any(p.search(data) for p in SAFE_PATTERNS)

    concatenates_id = False
    if has_id_source:
        concatenates_id = bool(re.search(r"(id\s*=\s*\$_(?:GET|REQUEST)\s*\[\s*['\"]id['\"]\s*\])", data, re.I)) or \
                         bool(re.search(r"\.(\s*\$id\s*)", data)) or \
                         bool(re.search(r"where\s+.*id.*(\$id|\$_GET\s*\[\s*['\"]id['\"]\s*\])", data, re.I | re.S))

    if has_id_source and has_sql and not has_safe and concatenates_id:
        print_result("VULNERABLE", f"{target} appears to use request parameter 'id' in SQL without clear parameterization or integer validation", 1)

    if has_id_source and has_safe:
        print_result("PATCHED", f"{target} contains signs of integer validation or prepared statements for 'id'", 0)

    print_result("UNKNOWN", f"{target} exists but the script could not conclusively prove vulnerable or patched logic", 2)


if __name__ == '__main__':
    main()

Sources

1. NVD CVE-2025-0198
2. OpenCVE record for CVE-2025-0198
3. GitHub Gist PoC by masamune
4. code-projects product page
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. OSV record for CVE-2025-0198
8. INCIBE-CERT summary