A vulnerability

CVE-2025-0207 is an unauthenticated SQL injection in code-projects Online Shoe Store 1.0, specifically the password parameter in /function/login.php. The vulnerable code concatenates user-controlled email and password directly into a SQL query against the customer table, enabling login bypass, database dumping, and—if the database account is over-privileged or stacked queries/filesystem features are available—possible follow-on code execution. Public writeups and a PoC gist point only to version 1.0; no maintained fixed version or distro backport was identified.

The vendor-side HIGH label is technically understandable for an unauthenticated remote SQLi, but it overstates enterprise patch urgency in practice. The decisive downgrade is reach and prevalence: this is a downloadable PHP sample/shop project from code-projects, not a mainstream enterprise platform, with no evidence of KEV listing, no credible campaign reporting, and a very low EPSS. If you actually have it internet-facing, it is a bad day for *that host*; across a 10,000-host enterprise fleet, it is usually shadow IT or trainingware, not top-of-queue mass risk.

Why this verdict

• Downgrade for prevalence: this is code-projects Online Shoe Store 1.0, a downloadable PHP project, not a common managed enterprise product; that sharply narrows the exposed population.
• Downgrade for attacker economics: exploitation requires first finding an organization that actually deployed this exact sample app in a reachable environment; that is materially different from a flaw in Exchange, PAN-OS, or Confluence.
• Hold at MEDIUM, not LOW: once exposed, the path is easy—unauthenticated remote SQLi with public PoC and likely login bypass/data theft using sqlmap.
• Downgrade for evidence: EPSS is extremely low and there is no KEV listing or solid campaign reporting, so the market is not telling us this is a priority-1 internet fire.
• Downgrade for blast-radius uncertainty: the jump from SQLi to full host compromise is environment-dependent; in many real deployments the impact stays at app/database compromise, not automatic RCE.

Why not higher?

If this were a broadly deployed commercial e-commerce platform, unauthenticated remote SQLi with public exploit would land comfortably in HIGH and might flirt with CRITICAL for internet-facing estates. It does not get that treatment here because the attack chain begins with a major population filter: very few enterprises should be running this exact code in production at scale.

Why not lower?

This is still an unauthenticated remote injection with a public PoC against a login endpoint. If you do have an exposed instance, an attacker does not need phishing, credentials, or prior foothold, and the likely outcome is direct data access or auth bypass.

1. Pull it off the internet — If any instance is externally reachable, move it behind VPN, IP allowlists, or an internal reverse proxy. For a MEDIUM noisgate verdict there is no mitigation SLA, but exposed instances should be treated as an exception because this is a trivial unauthenticated SQLi.
2. Block /function/login.php at the edge if the app is not needed — Add a reverse-proxy or WAF rule to deny direct access to the vulnerable endpoint, or disable the login feature entirely while you validate business need. There is no noisgate mitigation SLA for MEDIUM; use the control as immediate containment where the app cannot be removed quickly.
3. Constrain the database account — Reduce the application's DB user to the minimum required privileges and explicitly deny file-write, admin, and dangerous function access. This does not fix the SQLi, but it cuts the step from data theft to filesystem writes or shell attempts.
4. Hunt for shadow IT copies — Search webroots, Git repos, VM templates, and student/lab environments for Online Shoe Store, smss_db.sql, or the vulnerable login.php pattern. Because no vendor-fixed version was identified, discovery is the hard part and should be completed before the 365-day remediation window closes.
5. Replace or locally patch the code — Since no official fixed release was identified, the durable answer is to rewrite the vulnerable query with prepared statements or retire the application. For a MEDIUM verdict, there is no mitigation SLA—go straight to the remediation window and eliminate the vulnerable code before it expires.

Run this on the target web host or inside the container/VM where the PHP app is deployed. Invoke it as bash verify-cve-2025-0207.sh /var/www/html and provide the application webroot; no root is required for read access, but the account must be able to read function/login.php.

#!/usr/bin/env bash
# verify-cve-2025-0207.sh
# Detects likely vulnerable code-projects Online Shoe Store login.php pattern.
# Usage: bash verify-cve-2025-0207.sh /path/to/webroot
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

WEBROOT="${1:-}"
if [[ -z "$WEBROOT" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/webroot"
  exit 2
fi

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

# Normalize whitespace for simpler matching.
CONTENT="$(tr '\n\r\t' '   ' < "$TARGET")"

# Strong vulnerable indicators from the public PoC / NVD description.
HAS_EMAIL_POST=0
HAS_PASSWORD_POST=0
HAS_CUSTOMER_QUERY=0
HAS_DIRECT_INTERP=0
HAS_PREPARE=0

if grep -Eq '\$_POST\[["'"'']email["'"'']\]' "$TARGET"; then HAS_EMAIL_POST=1; fi
if grep -Eq '\$_POST\[["'"'']password["'"'']\]' "$TARGET"; then HAS_PASSWORD_POST=1; fi
if grep -Eqi 'SELECT[[:space:]]+\*[[:space:]]+FROM[[:space:]]+customer' "$TARGET"; then HAS_CUSTOMER_QUERY=1; fi
if grep -Eqi "email=.?['\"]?\$email['\"]?.*password=.?['\"]?\$password['\"]?" "$TARGET"; then HAS_DIRECT_INTERP=1; fi
if grep -Eqi '(prepare\s*\(|bind_param\s*\(|mysqli_prepare\s*\(|PDO\s*::\s*prepare\s*\()' "$TARGET"; then HAS_PREPARE=1; fi

if [[ $HAS_EMAIL_POST -eq 1 && $HAS_PASSWORD_POST -eq 1 && $HAS_CUSTOMER_QUERY -eq 1 && $HAS_DIRECT_INTERP -eq 1 && $HAS_PREPARE -eq 0 ]]; then
  echo "VULNERABLE - login.php appears to concatenate email/password into SQL directly"
  exit 1
fi

if [[ $HAS_PREPARE -eq 1 ]]; then
  echo "PATCHED - prepared statement usage detected; review manually to confirm"
  exit 0
fi

echo "UNKNOWN - file exists but pattern is inconclusive; manual code review required"
exit 2

Sources

1. NVD CVE-2025-0207
2. Public PoC gist by th4s1s
3. code-projects - Online Shoe Store Using PHP With Source Code
4. code-projects - Online Shoes Store IN PHP, CSS, Js, AND MYSQL
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST EPSS API documentation