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

CVE-2025-0195 is an SQL injection in code-projects Point of Sales and Inventory Management System 1.0, specifically in /user/del_product.php via the id parameter. The published CVE data says the attack is remote, requires low privileges, and affects version 1.0; NVD/OpenCVE do not show any vendor-published fixed version, so the practical state is *1.0 vulnerable, no authoritative patch record surfaced*.

The vendor's MEDIUM is directionally fair in lab conditions, but it overstates urgency for enterprise patch triage. The biggest reality check is friction: the attacker needs a valid application session, this product is a niche PHP sample app rather than a common enterprise platform, and the documented impact is app/database-level data access or tampering rather than turnkey host takeover.

Why this verdict

• Start at vendor 6.3, then subtract for PR:L — requiring a valid application account means the attacker is already past identity controls or already inside your environment.
• Subtract again for exposure reality — this is a niche code-projects PHP app, not Exchange, Ivanti, or a perimeter appliance with massive external footprint.
• Subtract for constrained blast radius — current evidence supports app/database data theft or tampering, not direct host takeover or domain-wide compromise.
• Add a little back for public exploit disclosure — NVD/OpenCVE reference a public exploit gist, so once auth is obtained the attack path is low-friction.

Why not higher?

If this were unauthenticated remote SQLi on a broadly exposed enterprise platform, the score would climb fast. But PR:L plus uncertain external exposure changes the operational story: most enterprises that get hit here are already dealing with a prior control failure or an internal attacker.

Why not lower?

It is still SQL injection, still remote *after login*, and still tied to business data in a POS/inventory workflow. Public exploit disclosure and the product's broader cluster of similar SQLi bugs mean you should not write it off as theoretical.

1. Fence the app off the internet — Put the POS application behind VPN, IP allowlists, or an internal reverse proxy so PR:L also implies *internal reachability*. For a LOW verdict there is no formal deadline; treat this as backlog hygiene and do it during normal hardening work.
2. Constrain who can hit product-management routes — Limit /user/* administrative and deletion workflows to only the smallest set of cashier/admin roles and, where possible, branch subnets. For LOW, there is no mitigation SLA; fold this into routine access-control cleanup.
3. Add SQLi-aware WAF rules — A reverse proxy or WAF can blunt commodity payloads aimed at id and similar parameters, which matters because this codebase appears to have multiple SQLi points. Since there is no official patch record surfaced, virtual patching is a reasonable compensating measure during normal maintenance.
4. Watch database and app logs for delete-path abuse — Alert on unusual requests to /user/del_product.php, bursty id probing, SQL errors, and anomalous product deletions. For LOW, monitor as backlog hygiene rather than emergency response unless the app is externally exposed.

Run this on the target web server that hosts the PHP application, not from an auditor workstation. Invoke it as sudo bash verify-cve-2025-0195.sh /var/www/html/pos (replace with the app root); read access to the PHP files is required, and sudo helps if the web root is restricted.

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

set -euo pipefail

APP_ROOT="${1:-}"
TARGET_REL="user/del_product.php"

if [[ -z "$APP_ROOT" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/app_root"
  exit 2
fi

TARGET="$APP_ROOT/$TARGET_REL"

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

# Heuristics:
# 1) presence of id sourced from GET/REQUEST/POST
# 2) presence of SQL keywords in the file
# 3) evidence of string concatenation/interpolation using the id variable
# 4) absence of obvious prepared statement usage

src_id=0
sql_ops=0
concat_id=0
prepared=0

if grep -Eqi '\$_(GET|POST|REQUEST)\s*\[\s*["\x27]id["\x27]\s*\]' "$TARGET"; then
  src_id=1
fi

if grep -Eqi '(select|delete|update|insert)[[:space:]]+.*(from|into|set)' "$TARGET"; then
  sql_ops=1
fi

if grep -Eqi '(\.\s*\$[A-Za-z_][A-Za-z0-9_]*id\b|\$[A-Za-z_][A-Za-z0-9_]*id\b\s*\.|\$id\b)' "$TARGET"; then
  concat_id=1
fi

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

# Stronger signal: common vulnerable pattern in simple PHP CRUD apps
if grep -Eqi '\$id\s*=\s*\$_(GET|POST|REQUEST)\s*\[\s*["\x27]id["\x27]\s*\]' "$TARGET" \
   && grep -Eqi '(delete|select|update).*(where).*(id).*(\$id|\'.*\$id|".*\$id)' "$TARGET" \
   && [[ $prepared -eq 0 ]]; then
  echo "VULNERABLE - direct id parameter flow into SQL detected in $TARGET_REL"
  exit 1
fi

if [[ $src_id -eq 1 && $sql_ops -eq 1 && $concat_id -eq 1 && $prepared -eq 0 ]]; then
  echo "VULNERABLE - likely unsafe id-to-SQL pattern detected in $TARGET_REL"
  exit 1
fi

if [[ $prepared -eq 1 ]]; then
  echo "PATCHED - prepared statement usage detected in $TARGET_REL (manual review still recommended)"
  exit 0
fi

echo "UNKNOWN - file exists but the vulnerable pattern was not confidently confirmed"
exit 2

Sources

1. NVD CVE-2025-0195
2. OpenCVE record for CVE-2025-0195
3. Code-projects product page
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS overview
6. Indusface January 2025 bulletin
7. CVEFeed detail page
8. Referenced public exploit gist