A vulnerability classified as critical has been found in code-projects Point of Sales and Inventory…

CVE-2025-0196 is a SQL injection in code-projects Point of Sales and Inventory Management System 1.0, specifically the cat parameter in /user/plist.php. The public PoC shows a crafted GET request to that route, and the CVE metadata assigns PR:L, which points to an authenticated low-privilege web user rather than anonymous internet access. Publicly documented affected scope is only version 1.0; no authoritative fixed release is referenced in the CVE, NVD, or OSV records reviewed.

The vendor/CNA MEDIUM rating is closer to reality than the word *critical* in the prose description. The decisive downgrade pressure is the attacker position: this is not pre-auth edge RCE, it is a low-privilege authenticated SQLi in a low-prevalence PHP demo-style application, with no KEV entry, very low EPSS, and no sourced evidence of broad in-the-wild abuse. If you actually expose this app to the internet, it still deserves attention; across a 10,000-host estate, it should not outrank broadly deployed pre-auth flaws.

Why this verdict

• Downgrade for attacker position: PR:L means authenticated low-privilege access, which usually implies prior compromise, insider access, or valid business-user credentials before exploitation starts.
• Downgrade for reachable population: this is a niche code-projects PHP application tied to version 1.0, not a broadly deployed enterprise platform. Even if the bug is real, the exposed population is small.
• Downgrade for threat evidence: no KEV listing, no sourced campaign reporting, and EPSS around 0.0008 all argue against urgent fleet-wide action.
• Partial upward pressure: public PoC exists and SQLi can expose or tamper with application data once a session is obtained, so this is not IGNORE.

Why not higher?

There is no strong evidence this is anonymously exploitable at the internet edge, and there is no sourced evidence of widespread active exploitation. The blast radius is usually constrained to the application and its database privileges, with any host-level pivot depending on extra misconfigurations not demonstrated by the advisory.

Why not lower?

It is still a real injection flaw with a working public PoC, and authenticated SQLi against a business app can absolutely leak customer, product, or transaction data. If your environment actually runs this app and exposes it to users, you cannot dismiss it as noise.

1. Restrict reachability — Put the application behind VPN, an allowlist, or a management jump path so random internet users cannot even attempt login or session theft. For a LOW verdict there is no SLA (treat as backlog hygiene), but if this app is internet-facing you should still reduce exposure during the next normal change window.
2. Force authentication hygiene — Reset weak/shared app accounts, disable unused users, and enforce unique credentials so PR:L remains a real barrier instead of a paper wall. For LOW, handle this as backlog hygiene unless you know the app is externally reachable.
3. Add targeted WAF rules — Deploy explicit blocking or alerting for SQLi metacharacters and boolean/comment payloads on /user/plist.php and related /user/ routes. This is compensating control, not a fix, and for LOW it fits standard maintenance rather than an emergency window.
4. Constrain DB privileges — Ensure the web app's database account cannot write files, create users, or access unrelated schemas; that sharply limits SQLi blast radius. For LOW, schedule this as hardening work in normal backlog flow.
5. Retire or self-patch the app — Because no authoritative vendor-fixed version is published, the practical remediation is to remove the app, patch the vulnerable query yourself, or replace it with supported software. For LOW, plan that as hygiene work rather than a fire drill.

Run this on the target web server host that serves the PHP application, not from an auditor workstation. Invoke it as sudo bash verify-cve-2025-0196.sh /var/www/html/POS_inventory or let it search common docroots with sudo bash verify-cve-2025-0196.sh; read access to the PHP files is required, root is only needed if the web root is restricted.

#!/usr/bin/env bash
# verify-cve-2025-0196.sh
# Detect likely vulnerable code paths for CVE-2025-0196 in code-projects POS & Inventory 1.0
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_ROOT="${1:-}"
FOUND_ANY=0
FOUND_VULN=0
FOUND_PATCH_HINT=0

check_file() {
  local f="$1"
  local content
  content="$(tr '\n' ' ' < "$f" 2>/dev/null)" || return

  # Strong vulnerability hints: cat parameter from GET/request and direct SQL concatenation/interpolation.
  if printf '%s' "$content" | grep -Eqi '\$_(GET|REQUEST)\s*\[\s*["'"'"']cat["'"'"']\s*\]' \
     && printf '%s' "$content" | grep -Eqi '(select|from|where).*(cat|category)' \
     && printf '%s' "$content" | grep -Eqi '(\.\s*\$cat\s*\.|\.\s*\$cat\s*[;)]|["'"'"']\s*\.\s*\$cat\s*\.\s*["'"'"']|where[^;]{0,120}\$cat)'; then
    echo "VULNERABLE"
    exit 1
  fi

  # Patch hints: explicit integer coercion or prepared statements around cat.
  if printf '%s' "$content" | grep -Eqi '(intval\s*\(\s*\$_(GET|REQUEST)\s*\[\s*["'"'"']cat["'"'"']\s*\]\s*\)|\(int\)\s*\$_(GET|REQUEST)\s*\[\s*["'"'"']cat["'"'"']\s*\])'; then
    FOUND_PATCH_HINT=1
    return
  fi

  if printf '%s' "$content" | grep -Eqi '(prepare\s*\(|mysqli_prepare\s*\(|bind_param\s*\()' \
     && printf '%s' "$content" | grep -Eqi 'cat'; then
    FOUND_PATCH_HINT=1
    return
  fi
}

scan_root() {
  local root="$1"
  [ -d "$root" ] || return
  while IFS= read -r -d '' file; do
    FOUND_ANY=1
    check_file "$file"
  done < <(find "$root" -type f -path '*/user/plist.php' -print0 2>/dev/null)
}

if [ -n "$TARGET_ROOT" ]; then
  scan_root "$TARGET_ROOT"
else
  for root in /var/www /srv/www /usr/local/apache2/htdocs /opt/lampp/htdocs /Applications/XAMPP/xamppfiles/htdocs; do
    scan_root "$root"
  done
fi

if [ "$FOUND_ANY" -eq 0 ]; then
  echo "UNKNOWN"
  exit 2
fi

if [ "$FOUND_PATCH_HINT" -eq 1 ]; then
  echo "PATCHED"
  exit 0
fi

echo "UNKNOWN"
exit 2

Sources

1. NVD CVE-2025-0196
2. MITRE CVE record
3. Public PoC Gist by Masamune
4. Code-projects product page
5. OpenCVE record
6. OSV record
7. INCIBE advisory mirror