A vulnerability was found in code-projects Online Shoe Store 1

CVE-2025-0204 is a SQL injection flaw in code-projects Online Shoe Store 1.0, specifically in /details.php via the id parameter. The published proof of concept shows the app reading $_GET['id'] directly into SELECT * FROM product WHERE product_id = '$id', which makes database extraction straightforward if this sample PHP app is deployed and reachable.

The vendor's MEDIUM 6.3 baseline is technically plausible for a single exposed app, but it overstates fleet-level urgency for most enterprises. The big reality check is *reach*: this is a low-prevalence code-projects sample app, not Exchange, Ivanti, or a common edge platform; there is no KEV listing, no observed mass exploitation signal in the sources reviewed, and the scary sqlmap-to-shell outcome depends on extra database and filesystem privileges that many real deployments will not grant.

Why this verdict

• Start from 6.3 MEDIUM: an exposed SQLi on a public product page is a legitimate application compromise path.
• Reachability cuts hard: attacker position is unauthenticated remote, but that only matters if you actually run this obscure sample app; most enterprises do not, so exposed population is tiny compared with true patch-priority software.
• The PR:L metric likely understates exploitability on a vulnerable host: the PoC and code path suggest normal browse access to /details.php?id=, so I am *not* dropping this to IGNORE.
• Blast radius is usually app-local: the reliable outcome is database compromise for this one application; turning SQLi into OS shell requires extra DB and filesystem privileges that many deployments will not have.
• Threat intel is quiet: no KEV listing, no authoritative active-exploitation evidence found, and the EPSS supplied is extremely low.

Why not higher?

Because this is not a common enterprise platform, the reachable victim population is the whole story. A pre-auth SQLi on a forgotten demo site can absolutely burn that site, but it does not create the kind of broad, repeatable fleet risk that justifies MEDIUM-to-HIGH prioritization across a large enterprise program.

Why not lower?

Because if you *do* have this app exposed, exploitation is not hypothetical. There is public PoC material, the vulnerable code pattern is straightforward, and a single internet-facing instance is enough for direct database compromise.

1. Remove it from the internet — If this app exists, the best control is to stop treating a demo PHP storefront as public production software. Put it behind VPN, IP allowlists, or internal-only access; for a LOW verdict there is no formal deadline, so handle as backlog hygiene unless the app is actually exposed.
2. Add a targeted WAF rule — Block obvious SQLi metacharacters and sqlmap-style request patterns on /details.php and especially the id parameter. This is a stopgap, not a fix, but it meaningfully raises attacker cost where no vendor patch exists; for LOW, treat this as opportunistic hardening rather than SLA work.
3. Constrain the database account — Strip dangerous DB privileges such as file-write or admin capabilities and keep the app user limited to only the tables and verbs it needs. This directly reduces the chance that SQLi becomes filesystem write or broader host compromise; again, no formal SLA at LOW, but worth doing if the app must stay up.
4. Retire or replace the codebase — The surrounding disclosure pattern suggests a generally unsafe application, not a single isolated bug. If business value is real, migrate to a supported commerce platform; if not, decommission it as backlog hygiene.

Run this on the target web host or against a checked-out application directory, not from an auditor workstation. Invoke it as python verify_cve_2025_0204.py /var/www/html/onl-shoe or python .\verify_cve_2025_0204.py C:\xampp\htdocs\onl-shoe; it needs only read access to the app files.

#!/usr/bin/env python3
"""
verify_cve_2025_0204.py

Static verifier for CVE-2025-0204 in code-projects Online Shoe Store 1.0.
Checks whether details.php appears to read $_GET['id'] and interpolate it
into the product query without prepared statements.

Exit codes:
  0 = PATCHED
  1 = VULNERABLE
  2 = UNKNOWN
  3 = USAGE ERROR
"""

import os
import re
import sys
from pathlib import Path

VULN_PATTERNS = [
    re.compile(r"\$_GET\s*\[\s*['\"]id['\"]\s*\]", re.I),
    re.compile(r"\$id\s*=\s*\$_GET\s*\[\s*['\"]id['\"]\s*\]", re.I),
    re.compile(r"SELECT\s+\*\s+FROM\s+product\s+WHERE\s+product_id\s*=\s*['\"]\$id['\"]", re.I),
    re.compile(r"query\s*\(\s*['\"].*product_id\s*=\s*['\"]\$id['\"]", re.I | re.S),
]

SAFE_HINTS = [
    re.compile(r"prepare\s*\(", re.I),
    re.compile(r"bind_param\s*\(", re.I),
    re.compile(r"PDO\s*::\s*prepare", re.I),
    re.compile(r"mysqli_prepare\s*\(", re.I),
    re.compile(r"intval\s*\(\s*\$_GET\s*\[\s*['\"]id['\"]\s*\]\s*\)", re.I),
    re.compile(r"filter_input\s*\(\s*INPUT_GET\s*,\s*['\"]id['\"]", re.I),
]


def load_file(base: Path):
    candidates = [
        base / "details.php",
        base / "onl shoe" / "details.php",
        base / "online shoe store" / "details.php",
    ]

    for candidate in candidates:
        if candidate.is_file():
            try:
                return candidate, candidate.read_text(encoding="utf-8", errors="ignore")
            except Exception:
                pass

    found = list(base.rglob("details.php"))
    for candidate in found:
        if candidate.is_file():
            try:
                return candidate, candidate.read_text(encoding="utf-8", errors="ignore")
            except Exception:
                continue

    return None, None


def main():
    if len(sys.argv) != 2:
        print("UNKNOWN")
        print("Usage: python verify_cve_2025_0204.py <application_root>", file=sys.stderr)
        sys.exit(3)

    root = Path(sys.argv[1]).expanduser().resolve()
    if not root.exists() or not root.is_dir():
        print("UNKNOWN")
        print(f"Path not found or not a directory: {root}", file=sys.stderr)
        sys.exit(2)

    target, content = load_file(root)
    if not target or content is None:
        print("UNKNOWN")
        print("details.php not found under supplied root", file=sys.stderr)
        sys.exit(2)

    vuln_hits = sum(1 for p in VULN_PATTERNS if p.search(content))
    safe_hits = sum(1 for p in SAFE_HINTS if p.search(content))

    if vuln_hits >= 3 and safe_hits == 0:
        print("VULNERABLE")
        print(f"Matched vulnerable code pattern in: {target}")
        sys.exit(1)

    if safe_hits >= 1 and vuln_hits < 3:
        print("PATCHED")
        print(f"Found sanitization/prepared-statement indicators in: {target}")
        sys.exit(0)

    print("UNKNOWN")
    print(f"Manual review needed for: {target}")
    sys.exit(2)


if __name__ == "__main__":
    main()

Sources

1. Official CVE JSON record
2. NVD entry
3. OpenCVE parsed record
4. Public PoC gist by th4s1s
5. Product page for Online Shoe Store Using PHP
6. CISA Known Exploited Vulnerabilities Catalog
7. CISA vulnerability summary for week of 2024-12-30
8. FIRST EPSS documentation and API