This is a booby-trapped product page, not a master key to your environment
CVE-2025-0175 is a reflected XSS issue in code-projects Online Shop 1.0. The vulnerable path is /view.php, where attacker-controlled name and details parameters are echoed into the page without output encoding; the public PoC shows direct use of $_GET['name'] and $_GET['details']. I could not find any authoritative evidence of a vendor-fixed release, so the affected range is effectively 1.0 / all known public downloads of this project.
Operationally, the original LOW rating is the right neighborhood and arguably still a bit generous for enterprise patch queues. NVD later modeled it as a higher-score web XSS case because the endpoint appears reachable without auth, but in the real world this still needs a victim to load a crafted URL, usually needs a live session to matter, and sits in an educational PHP sample app that is far less prevalent than mainstream commerce platforms.
4 steps from start to impact.
Find a live Online Shop instance
code-projects Online Shop 1.0 application. In practice this is usually done with commodity recon and manual page fingerprinting rather than a mature exploit framework, because this project is a downloadable sample app, not a broadly fingerprinted enterprise product.- A copy of Online Shop 1.0 is actually deployed
- The web app is reachable from the attacker position
- This is a niche educational package, so exposed population is likely tiny
- There is no strong product fingerprint or mainstream scanner coverage for this exact app
Weaponize the reflected XSS with a crafted URL
name or details on /view.php. The public PoC by th4s1s shows the vulnerable sinks and a simple onerror payload, so exploit construction is trivial once the app is identified.- The target page reflects
nameordetailsinto HTML - The attacker can send a link or otherwise induce a request
- This is reflected XSS, so it generally requires user interaction
- Basic email security, user skepticism, or URL rewriting can break the lure
Execute script in the victim browser
- A victim user visits the malicious link
- The browser permits the payload to execute
- The victim has a meaningful session or privileges in the app
HttpOnly,SameSite, and CSP can sharply reduce useful post-exploitation- If the victim is anonymous, impact may be limited to defacement or nuisance in that session context
Abuse the session inside the same app
- Victim session has permissions worth stealing or replaying
- The application exposes state-changing actions without stronger anti-abuse controls
- Impact is capped to one application tenant/session unless additional app flaws exist
- Modern EDR will not usually see much because the action stays inside the browser and web session
/view.php.view.php — Wrap name and details with htmlspecialchars(..., ENT_QUOTES, 'UTF-8') or equivalent before rendering. Because no upstream fixed version was identified, your practical remediation is a local code fix in your maintained copy, again with no SLA beyond normal backlog hygiene.- EDR on the web server won't meaningfully stop browser-side JavaScript execution because the abuse happens in the victim session, not as a host process exploit.
- Generic network segmentation alone does not fix a reflected XSS bug if users can still browse to the app from their workstation.
- MFA helps account login risk, but it does not stop an already-authenticated browser from executing attacker-supplied script in the application's origin.
The supporting signals.
| In-the-wild status | No authoritative evidence of active exploitation found in CISA KEV or vendor/government advisories reviewed. Public exploit information exists, but that is not the same as observed campaign use. |
|---|---|
| Proof-of-concept availability | Yes. A public GitHub Gist by th4s1s published on 2025-01-02 shows the vulnerable sinks in /view.php and a simple XSS payload. |
| EPSS | 0.00236 (0.236%), which is very low; third-party tracking places it at roughly the 28th percentile. That is consistent with a low-likelihood, low-prevalence web app bug. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog as checked on 2026-05-30. |
| CVSS disagreement | CNA/VulDB scored it 3.5 LOW with PR:L/UI:R, while NVD later assessed 6.1 MEDIUM with PR:N/UI:R/S:C. The code sample and PoC support the view that the endpoint itself is reachable without auth, but the *operational* risk still stays low because user interaction and app-local blast radius dominate. |
| Affected versions | Online Shop 1.0; vulnerable behavior is in /view.php via the name and details parameters. |
| Fixed versions | No authoritative vendor-fixed version or patch release was identified. Treat this as no known upstream patch unless you maintain your own fork. |
| Exposure reality | I found no reliable Shodan/Censys/GreyNoise product census for this exact app. The stronger signal is that the project is distributed as a small downloadable PHP/XAMPP learning app, which materially lowers enterprise prevalence. |
| Disclosure timeline | PoC dated 2025-01-02; NVD shows the CVE published on 2025-01-02 and modified on 2025-02-25; the user-supplied disclosure date of 2025-01-03 matches common third-party indexing. |
| Researcher / reporting | Public PoC attributed to th4s1s; CVE record source is VulDB, with NVD enrichment added later. |
Sources.
Why this verdict
- Start from 3.5 LOW: the vendor baseline already assumes a modest web-impact bug, and nothing here justifies a fleet-priority upgrade.
- Exposure population cuts the score down: this is a downloadable training/demo PHP shop, not Exchange, Confluence, or a VPN edge product. Real enterprise prevalence is likely tiny.
- Requires a prior human step: the attacker typically needs a victim to click or load a crafted link. That implies social engineering or another delivery channel, which is a compounding friction point.
- Blast radius is app-local: successful execution lives in the browser origin of this single shop app. Without a privileged victim session or adjacent flaws, it does not become host takeover or domain compromise.
- Threat intel is quiet: no KEV entry, no credible campaign reporting, and a very low EPSS all argue against elevating this above backlog-grade work.
Why not higher?
NVD's higher technical score reflects a generic internet-reachable XSS model, but enterprise defenders should score the *whole chain*, not the sink in isolation. Here that chain narrows fast: niche deployment, reflected delivery, user interaction, and session-scoped impact all push down operational severity.
Why not lower?
This is still a real web exploit with a public PoC, not a theoretical code smell. If you actually run this app and staff use it with authenticated sessions, an attacker can still steal app-context data or perform actions as the victim, so it should not be ignored outright.
Crowdsourced verification payload.
Run this on the target web host, a mounted deployment artifact, or a CI workspace containing the PHP app source. Invoke it as python3 verify_cve_2025_0175.py /var/www/html/online-shop (or the app root on Windows/Linux/macOS); no admin rights are required beyond read access to the application files.
#!/usr/bin/env python3
# verify_cve_2025_0175.py
# Checks whether code-projects Online Shop view.php appears vulnerable to CVE-2025-0175.
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN
import os
import re
import sys
VULN_PATTERNS = [
re.compile(r"echo\s*\(?\s*\$_GET\s*\[\s*['\"]name['\"]\s*\]\s*\)?", re.I),
re.compile(r"echo\s*\(?\s*\$_GET\s*\[\s*['\"]details['\"]\s*\]\s*\)?", re.I),
]
SAFE_HINTS = [
re.compile(r"htmlspecialchars\s*\(", re.I),
re.compile(r"htmlentities\s*\(", re.I),
re.compile(r"strip_tags\s*\(", re.I),
]
def find_view_php(root):
if os.path.isfile(root):
return root if os.path.basename(root).lower() == 'view.php' else None
for dirpath, _, filenames in os.walk(root):
for f in filenames:
if f.lower() == 'view.php':
return os.path.join(dirpath, f)
return None
def main():
if len(sys.argv) != 2:
print("UNKNOWN - usage: python3 verify_cve_2025_0175.py <app_root_or_view.php>")
sys.exit(2)
target = sys.argv[1]
if not os.path.exists(target):
print(f"UNKNOWN - path does not exist: {target}")
sys.exit(2)
view_php = find_view_php(target)
if not view_php:
print("UNKNOWN - view.php not found")
sys.exit(2)
try:
with open(view_php, 'r', encoding='utf-8', errors='ignore') as fh:
content = fh.read()
except Exception as e:
print(f"UNKNOWN - cannot read {view_php}: {e}")
sys.exit(2)
name_raw = bool(VULN_PATTERNS[0].search(content))
details_raw = bool(VULN_PATTERNS[1].search(content))
safe_present = any(p.search(content) for p in SAFE_HINTS)
# Heuristic result logic:
# - vulnerable if raw echo for either parameter appears and no obvious output encoding is present.
# - patched if the file exists and the raw patterns are absent, or if safe encoding wrappers are present around output.
if (name_raw or details_raw) and not safe_present:
print(f"VULNERABLE - raw $_GET output found in {view_php}")
sys.exit(0)
elif safe_present or (not name_raw and not details_raw):
print(f"PATCHED - no raw vulnerable sink detected in {view_php}")
sys.exit(1)
else:
print(f"UNKNOWN - manual review required for {view_php}")
sys.exit(2)
if __name__ == '__main__':
main()