A vulnerability classified as critical has been found in code-projects Online Shoe Store 1

CVE-2025-0205 is a SQL injection flaw in code-projects Online Shoe Store 1.0, specifically the /details2.php endpoint where the id parameter is not safely handled before reaching backend SQL. Public descriptions consistently name version 1.0 as affected, and there is a public exploit reference tied to the CVE. I could not find any authoritative vendor patch or fixed release; for this product, the practical reality looks like *vulnerable 1.0* versus *locally modified code* rather than a clean supported upgrade path.

The vendor-side MEDIUM 6.3 call is directionally closer to reality than NVD's inflated 9.8, but for the wrong reason. The decisive downward pressure is not that SQLi is harmless—it is not—but that this is a small, freely downloadable demo-style PHP/MySQL project with weak evidence of meaningful enterprise deployment, low EPSS, no KEV listing, and no credible in-the-wild campaign reporting. If you *do* run it on the internet, it is an unauthenticated data-exposure bug; if you manage a normal enterprise estate, it is not a fleet-wide fire drill.

Why this verdict

• Unauthenticated remote path raises the floor: despite the CNA's PR:L vector, NVD's later enrichment points to a remotely reachable SQLi with no user interaction, so this is not mere local hygiene.
• Exposure population crushes urgency: the prerequisite is not just 'internet access' but 'internet access to a niche downloadable PHP source project actually deployed in production,' which sharply narrows real-world victim count.
• Commodity exploit path: sqlmap-class tooling and a public PoC reference reduce attacker effort once a live target exists.
• No KEV, no campaign signal, very low EPSS: absent exploitation evidence, this does not deserve top-quartile patch priority in an enterprise queue.
• Impact is data-layer first, not instant estate-wide takeover: the likely outcome is DB read/write abuse against one app, with further damage dependent on weak secrets, reused creds, or adjacent trust.

Why not higher?

To reach HIGH, I would want either broad enterprise prevalence, active exploitation, or a cleaner path to immediate high-value compromise across many organizations. Here, the attack starts unauthenticated, but the reachable population is narrow and the business impact is usually bounded to one small web app unless operators compounded the problem with bad secret reuse.

Why not lower?

This is still a remotely reachable SQL injection bug with public exploit material, so it is not paperwork-only noise. If you actually run this storefront on the internet, an attacker can plausibly pull data or tamper with records without already owning the environment.

1. Block public access to the app — If this storefront is nonessential, put it behind VPN, IP allowlisting, or an internal reverse proxy and remove direct internet reachability. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but internet-facing exposure is the one control most likely to collapse the attack path immediately.
2. Deploy targeted WAF rules — Add SQLi signatures focused on /details2.php and the id parameter, including quote, comment, UNION, boolean, and time-based patterns. Use this as a compensating control where no clean vendor patch exists; tune and validate quickly, then leave it in place until the code is replaced or fixed.
3. Constrain the database account — Reduce the web application's DB user to only the minimum tables and verbs it genuinely needs. Least privilege will not remove the bug, but it can turn a full dump/tamper event into a smaller blast radius.
4. Hunt for probe activity — Review web, proxy, and WAF logs for requests to /details2.php carrying suspicious id values, especially quotes, comments, sleep, benchmark, or unusually long numeric-looking payloads. This is cheap detection coverage for a bug class that tends to be noisy during validation.
5. Replace the app if it is business-facing — Because I found no authoritative fixed release, the durable answer is to retire or locally remediate this codebase rather than waiting for a vendor lifecycle that may not exist. For MEDIUM, track it inside the 365-day remediation window, but do not let 'no patch' become 'no owner'.

Run this on the target web host that serves the PHP application, not from an auditor workstation. Invoke it as sudo bash verify-cve-2025-0205.sh /var/www/html or point it at the app root you use; read access to the web files is required, and sudo helps if the webroot is restricted.

#!/usr/bin/env bash
# verify-cve-2025-0205.sh
# Checks a local code-projects Online Shoe Store deployment for signs of CVE-2025-0205
# Usage: bash verify-cve-2025-0205.sh /path/to/webroot
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_ROOT="${1:-}"
if [[ -z "$TARGET_ROOT" ]]; then
  echo "UNKNOWN: missing webroot path argument"
  exit 2
fi

if [[ ! -d "$TARGET_ROOT" ]]; then
  echo "UNKNOWN: path does not exist or is not a directory: $TARGET_ROOT"
  exit 2
fi

DETAILS_FILE="$(find "$TARGET_ROOT" -type f -name 'details2.php' 2>/dev/null | head -n 1)"
if [[ -z "$DETAILS_FILE" ]]; then
  echo "PATCHED: details2.php not found under $TARGET_ROOT"
  exit 0
fi

# Heuristic checks only. There is no authoritative fixed version string published.
HAS_GET_ID=0
HAS_SQL=0
HAS_PREPARED=0

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

if grep -Eqi '(select|insert|update|delete).*(from|into|set)' "$DETAILS_FILE"; then
  HAS_SQL=1
fi

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

# Stronger heuristic: look for direct concatenation of id into query-ish code.
DIRECT_INJECTION_MATCH=0
if grep -Eqi '(\$_(GET|REQUEST)\s*\[\s*["\x27]id["\x27]\s*\].*(select|update|delete|insert))|((select|update|delete|insert).*(\$_(GET|REQUEST)\s*\[\s*["\x27]id["\x27]\s*\]))' "$DETAILS_FILE"; then
  DIRECT_INJECTION_MATCH=1
fi

if [[ $DIRECT_INJECTION_MATCH -eq 1 ]]; then
  echo "VULNERABLE: details2.php appears to use request parameter id in SQL logic ($DETAILS_FILE)"
  exit 1
fi

if [[ $HAS_GET_ID -eq 1 && $HAS_SQL -eq 1 && $HAS_PREPARED -eq 0 ]]; then
  echo "VULNERABLE: details2.php contains id input handling and SQL patterns without obvious prepared statements ($DETAILS_FILE)"
  exit 1
fi

if [[ $HAS_PREPARED -eq 1 ]]; then
  echo "PATCHED: details2.php found, but prepared-statement patterns are present; manual review still recommended ($DETAILS_FILE)"
  exit 0
fi

echo "UNKNOWN: details2.php exists but the script could not determine exploitability conclusively ($DETAILS_FILE)"
exit 2

Sources

1. NVD CVE-2025-0205
2. OpenCVE record for CVE-2025-0205
3. OSV entry for CVE-2025-0205
4. code-projects download page for Online Shoes Store
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. Feedly CVE page surfacing EPSS/PoC references
8. CVE Details summary for CVE-2025-0205