A vulnerability

CVE-2025-0199 is an SQL injection in code-projects Point of Sales and Inventory Management System 1.0, specifically /user/minus_cart.php via the id parameter. The published PoC sends a POST request to that endpoint with a live PHPSESSID cookie, and the vulnerable route sits under the app's /user/ area; taken together, that strongly suggests an attacker needs an authenticated session to reach the bug, not just raw internet access. No vendor-fixed version or formal remediation release is published in the advisory trail I found; the vulnerable version remains 1.0 and public sources show no documented patched build.

Vendor severity at MEDIUM 6.3 is already closer to reality than the description's throwaway word '*critical*'. For enterprise prioritization, this drops further because the exploit chain is narrow: likely authenticated app access, a niche source-code PHP project rather than a broadly deployed enterprise platform, no KEV listing, no credible in-the-wild reporting, and an EPSS of 0.00086. Yes, it's SQLi and public PoC exists, but this looks like opportunistic post-login abuse against a small-exposure app, not something that should displace externally reachable pre-auth RCEs.

Why this verdict

• Downward adjustment: attacker position is probably post-login — the public PoC includes a PHPSESSID cookie and hits a /user/ endpoint, so this does not read like an internet-wide unauthenticated smash-and-grab.
• Downward adjustment: narrow reachable population — this is a downloadable code-projects PHP application, not Exchange, SharePoint, PAN-OS, or some other enterprise-common target with huge external exposure.
• Downward adjustment: weak threat pull — KEV: No, EPSS 0.00086, and no credible reporting of active campaigns mean there is little evidence adversaries care about this one at scale.
• Kept above IGNORE: public PoC and real SQLi — if you do run this app, an authenticated user may be able to read or tamper with backend data using straightforward web exploitation tooling.

Why not higher?

There is no evidence this is pre-auth, wormable, broadly exposed, or chained to code execution. The practical path appears to require prior foothold in the application itself, which is exactly the kind of compounding friction that should push severity down for enterprise patch queues.

Why not lower?

This is still a legitimate SQL injection with a public PoC against a real shipping codebase. If the app is deployed and reachable by untrusted users, the issue can enable data access or tampering and should not be dismissed as paperwork-only noise.

1. Restrict access to the app — Put the application behind VPN, IP allowlists, or internal-only publishing where possible. For a LOW verdict there is no SLA (treat as backlog hygiene), but if you keep the app, reducing who can even reach login and /user/ routes is the cleanest risk cut.
2. Add WAF rules for SQLi patterns — Deploy targeted rules for POSTs to /user/minus_cart.php and block classic SQLi metacharacters, boolean/time-based payloads, and abnormal parameter lengths. Use this as a compensating control while you schedule remediation; for LOW, there is no SLA (treat as backlog hygiene).
3. Review application auth controls — Since the likely exploit path starts with a user session, tighten local account policy, kill default/shared credentials, and front the app with stronger authentication where possible. That matters more here than with a pre-auth appliance bug because the exploit chain appears to start after login.
4. Monitor the endpoint directly — Add log alerts for spikes, odd id values, SQL error traces, and repeated POSTs to /user/minus_cart.php. For a low-priority backlog item, cheap telemetry gives you disproportionate defensive value without a large engineering lift.

Run this on the target web server that hosts the PHP application, not from an auditor workstation. Invoke it as bash verify-cve-2025-0199.sh /var/www/html/PISP (replace with the application root); it needs read access to the PHP source tree but not root if the files are world-readable.

#!/usr/bin/env bash
# verify-cve-2025-0199.sh
# Check code-projects Point of Sales and Inventory Management System for the
# published minus_cart.php SQL injection pattern tied to CVE-2025-0199.
#
# Usage: bash verify-cve-2025-0199.sh /path/to/app_root
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

APP_ROOT="${1:-}"
if [[ -z "$APP_ROOT" ]]; then
  echo "UNKNOWN - missing application root path"
  exit 2
fi

TARGET="$APP_ROOT/user/minus_cart.php"
if [[ ! -f "$TARGET" ]]; then
  echo "UNKNOWN - file not found: $TARGET"
  exit 2
fi

# Heuristic 1: file exists in expected location.
# Heuristic 2: vulnerable sink patterns commonly used by this code-projects PHP app.
# Heuristic 3: lack of obvious prepared statements / parameterized APIs.

content="$(tr '\n' ' ' < "$TARGET")"

has_sink=0
if grep -Eqi '(mysql_query|mysqli_query|->query\s*\(|query\s*\()' "$TARGET"; then
  has_sink=1
fi

has_id_flow=0
if grep -Eqi '(\$_POST\s*\[\s*["'"'']id["'"'']\s*\]|\$_REQUEST\s*\[\s*["'"'']id["'"'']\s*\]|\$_GET\s*\[\s*["'"'']id["'"'']\s*\])' "$TARGET"; then
  has_id_flow=1
fi

has_prepared=0
if grep -Eqi '(prepare\s*\(|bind_param\s*\(|PDO\s*\(|execute\s*\()' "$TARGET"; then
  has_prepared=1
fi

# Stronger heuristic: direct interpolation of $id inside SQL strings.
if grep -Eqi '(select|update|delete|insert).*(\$id|\{\$id\}|id\s*=\s*["'"'']?\$id)' "$TARGET"; then
  echo "VULNERABLE - direct SQL use of id-like variable detected in $TARGET"
  exit 1
fi

if [[ $has_sink -eq 1 && $has_id_flow -eq 1 && $has_prepared -eq 0 ]]; then
  echo "VULNERABLE - SQL query function + attacker-controlled id + no obvious prepared statements"
  exit 1
fi

if [[ $has_prepared -eq 1 ]]; then
  echo "PATCHED - prepared/parameterized DB access indicators found; manual review still recommended"
  exit 0
fi

echo "UNKNOWN - file present but exploit pattern could not be confirmed heuristically"
exit 2

Sources

1. NVD CVE record
2. CVE.org record
3. OpenCVE enrichment
4. Public PoC Gist by Masamune
5. Product page on code-projects.org
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. CVE Details entry with EPSS percentile view