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

CVE-2025-0176 is a SQL injection flaw in code-projects Point of Sales and Inventory Management System 1.0, specifically in /user/add_cart.php via the id and qty parameters. The public PoC targets the app's user workflow and shows a crafted POST to the cart endpoint, which means the practical impact is app-database reads or tampering inside this one PHP application rather than instant host takeover.

The vendor's MEDIUM 6.3 is closer to reality than NVD's later HIGH 7.5 enrichment. The decisive issue is friction: the vulnerable endpoint sits under /user/, the PoC includes a live PHPSESSID, and this project is a downloadable educational PHP app typically run under XAMPP/WAMP or a small LAMP stack, not a broadly managed enterprise platform. That narrows reachable population and usually implies the attacker already has app access.

Why this verdict

• Downgrade pressure: likely requires a logged-in app user. The endpoint is /user/add_cart.php, and the public PoC includes a PHPSESSID, which is a strong practical signal that exploitation usually starts *after* the attacker has valid app access or a stolen session.
• Downgrade pressure: niche product and small exposure population. This is a downloadable PHP project intended for XAMPP/WAMP-style deployment and educational use, not a common enterprise platform with massive internet-facing footprint.
• Upgrade pressure: public exploitability is real. Once an attacker has the right position, the bug is straightforward SQLi with low technical complexity and normal database confidentiality/integrity impact.

Why not higher?

I am not scoring this HIGH because the attack path appears to require more than just internet reachability. Requiring authenticated application access dramatically cuts the number of viable targets and means the attacker is already past the front door. I also found no KEV entry, no active exploitation reporting, and no evidence this app has broad enterprise prevalence.

Why not lower?

I am not dropping this to LOW or IGNORE because it is still a real SQL injection with a public PoC and a defined vulnerable endpoint. If your organization actually runs this app, a low-privilege user or session thief can likely read or tamper with POS data, which is materially worse than cosmetic or theoretical bugs.

1. Move the app behind trusted access — Put the POS app behind VPN, SSO gateway, reverse-proxy ACLs, or at minimum IP allowlisting so /user/ is not broadly reachable. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but reducing exposure now is cheap risk reduction if the app must stay online.
2. Constrain database privileges — Ensure the app's DB account cannot administer the server, write arbitrary files, or read unrelated schemas. This limits the SQLi blast radius to app data even if the endpoint remains vulnerable during the 365-day remediation window.
3. Add focused WAF rules — Deploy targeted SQLi signatures on POSTs to /user/add_cart.php, especially around id and qty, to catch opportunistic exploitation and scanning. For MEDIUM, use this as defense-in-depth rather than an emergency stopgap.
4. Hunt for stale sessions and weak accounts — Because the likely hard requirement is app access, rotate weak/default credentials, expire dormant users, and shorten session lifetimes. That directly attacks the most important prerequisite in this exploit chain.

Run this on the target Linux/PHP web host that contains the application files, not from an auditor workstation. Invoke it as bash verify-cve-2025-0176.sh /var/www/html/PISP or point it at the app root; it needs read access to the application directory only, not root.

#!/usr/bin/env bash
# verify-cve-2025-0176.sh
# Heuristic verifier for CVE-2025-0176 in code-projects Point of Sales and Inventory Management System 1.0
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

APP_ROOT="${1:-}"
if [[ -z "$APP_ROOT" ]]; then
  echo "UNKNOWN: missing application path argument"
  echo "Usage: bash verify-cve-2025-0176.sh /path/to/app"
  exit 2
fi

if [[ ! -d "$APP_ROOT" ]]; then
  echo "UNKNOWN: path does not exist: $APP_ROOT"
  exit 2
fi

TARGET="$APP_ROOT/user/add_cart.php"
README1="$APP_ROOT/Readme.txt"
README2="$APP_ROOT/README.txt"

if [[ ! -f "$TARGET" ]]; then
  echo "UNKNOWN: target file not found: $TARGET"
  exit 2
fi

# Normalize line endings for matching
TMPFILE="$(mktemp)"
tr -d '\r' < "$TARGET" > "$TMPFILE"

is_pos_project=0
if [[ -f "$README1" ]] && grep -Eqi 'point of sales|inventory management|PISP|posales' "$README1"; then
  is_pos_project=1
elif [[ -f "$README2" ]] && grep -Eqi 'point of sales|inventory management|PISP|posales' "$README2"; then
  is_pos_project=1
elif grep -Eqi 'posales|add_cart|cart=1|mysql_query|SELECT|FROM' "$TMPFILE"; then
  is_pos_project=1
fi

# Heuristics for vulnerable code:
# - file exists at expected path
# - app appears to be the POS project
# - file contains direct use of request/body vars and legacy SQL building functions/patterns
has_request_vars=0
has_sql_usage=0
has_parameterization=0

if grep -Eqi '\$_(POST|GET|REQUEST)\s*\[[^]]*(id|qty)[^]]*\]' "$TMPFILE"; then
  has_request_vars=1
fi

if grep -Eqi 'mysql_query|mysqli_query|SELECT|INSERT|UPDATE' "$TMPFILE"; then
  has_sql_usage=1
fi

if grep -Eqi 'prepare\s*\(|bind_param\s*\(|PDO\s*::\s*prepare|->prepare\s*\(' "$TMPFILE"; then
  has_parameterization=1
fi

rm -f "$TMPFILE"

if [[ "$is_pos_project" -eq 1 && "$has_request_vars" -eq 1 && "$has_sql_usage" -eq 1 && "$has_parameterization" -eq 0 ]]; then
  echo "VULNERABLE: add_cart.php present with request-driven SQL patterns and no obvious parameterization"
  exit 1
fi

if [[ "$has_parameterization" -eq 1 ]]; then
  echo "PATCHED: add_cart.php shows parameterized query patterns"
  exit 0
fi

echo "UNKNOWN: app found but code pattern is inconclusive; manual review of $TARGET required"
exit 2

Sources

1. NVD CVE-2025-0176
2. CVE Record / OpenCVE mirror
3. Public PoC Gist by Masamune
4. Code-Projects product page
5. Related Code-Projects download page
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS documentation
8. CVE Details entry with score history and references