A vulnerability

CVE-2025-0229 is an SQL injection bug in code-projects Travel Management System 1.0, specifically the public enquiry.php workflow. The referenced code concatenates $_REQUEST["pid"] and POST fields t1 through t7 directly into an INSERT statement for the enquiry table, so affected scope is effectively version 1.0 / enquiry.php in the downloadable PHP project.

The vendor's 6.3 MEDIUM is already closer to reality than NVD's 9.8, and I would still push it lower for enterprise patch triage. The big reason is friction: this is a niche sample PHP app, there is no KEV signal, the EPSS is extremely low, and the public PoC shown in the referenced GitHub write-up uses UNION SELECT against what appears to be an INSERT sink, which is a weak indicator of reliable, high-impact exploitation.

Why this verdict

• Baseline starts at vendor 6.3 MEDIUM because the CNA vector already assumes limited impact and some privilege requirement, which is far more believable than NVD's later 9.8 overlay.
• One notch back up for exposure semantics: the vulnerable feature appears to be the public enquiry workflow, so I do *not* buy the vendor's PR:L in a strict sense. If you run this app on the internet, an unauthenticated user can likely reach the sink.
• Two notches down for product prevalence: this is a small downloadable PHP sample project from Code-Projects, not a mainstream enterprise platform. That sharply limits the population actually at risk across a 10,000-host estate.
• Another notch down for exploit quality: the public PoC targets an INSERT sink with UNION SELECT, which is not convincing evidence of easy, repeatable data extraction. That is major friction in real operations.
• Down again for threat intel: no KEV listing, no reviewed campaign reporting, and an extremely low EPSS all argue against urgent attacker demand.

Why not higher?

Because the scary part is mostly theoretical unless you already have this exact niche app exposed and the injection can be turned into a reliable blind or error-based channel. The reviewed material does not show a clean path to RCE, tenant-wide takeover, or broad enterprise blast radius.

Why not lower?

Because the code does appear to concatenate user input directly into SQL, and the vulnerable workflow is likely public-facing rather than admin-only. If you do run this exact app, an external attacker can at minimum try to tamper with database writes and potentially go further depending on database behavior.

1. Restrict exposure — If this sample app is not business-critical, pull it off the internet or put it behind VPN/reverse-proxy allowlisting. For a LOW verdict there is no SLA; treat as backlog hygiene, but exposure reduction is still the fastest risk cut if the app is public.
2. Add a WAF rule for enquiry parameters — Block or challenge SQL metacharacters and anomalous length in pid, t1-t7, and form submissions to enquiry.php. This is compensating control only, not a fix; for LOW, there is no formal mitigation SLA.
3. Constrain DB permissions — Ensure the application's database user has only the minimum privileges required for the enquiry workflow. If an injection attempt succeeds, least-privilege limits exfiltration and schema tampering; again, for LOW, handle this as backlog hygiene if not already standard.
4. Instrument logging on enquiry.php — Log request parameters safely, response codes, SQL errors, and source IPs for this endpoint so you can spot repeated payload testing. That gives you a cheap tripwire while the issue sits in the backlog.

Run this on the target web server that hosts the PHP application, not from your scanner workstation. Invoke it as bash verify-cve-2025-0229.sh /var/www/html/Travel/enquiry.php; it needs only read access to the PHP source file and returns VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# verify-cve-2025-0229.sh
# Detects the vulnerable SQL construction pattern in Travel Management System enquiry.php
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / usage / unreadable

set -u

TARGET="${1:-}"

if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN: usage: $0 /path/to/enquiry.php"
  exit 2
fi

if [[ ! -f "$TARGET" ]]; then
  echo "UNKNOWN: file not found: $TARGET"
  exit 2
fi

if [[ ! -r "$TARGET" ]]; then
  echo "UNKNOWN: file not readable: $TARGET"
  exit 2
fi

# Normalize whitespace to make pattern matching less brittle.
CONTENT="$(tr '\n\r\t' '   ' < "$TARGET")"

# Strong indicator: INSERT into enquiry table with direct concatenation of user-controlled pid/t1..t7
if echo "$CONTENT" | grep -Eiq 'insert[[:space:]]+into[[:space:]]+enquiry[[:space:]]*\(' \
  && echo "$CONTENT" | grep -Fq '$_REQUEST["pid"]' \
  && echo "$CONTENT" | grep -Fq '$_POST["t1"]' \
  && echo "$CONTENT" | grep -Fq 'mysqli_query($cn,$s)'; then
  echo "VULNERABLE: direct SQL string concatenation involving pid/t1..t7 found in enquiry.php"
  exit 1
fi

# If prepared statements or parameter binding appear near the query, assume likely patched.
if echo "$CONTENT" | grep -Eiq 'prepare\s*\(|bind_param\s*\(|PDO\s*::\s*prepare'; then
  echo "PATCHED: prepared statement usage detected; manual review still recommended"
  exit 0
fi

# If the file exists but the expected vulnerable markers are absent, status is uncertain.
echo "UNKNOWN: expected vulnerable pattern not found and no clear prepared statements detected"
exit 2

Sources

1. NVD CVE-2025-0229
2. Referenced public PoC / code analysis by Huandtx
3. Code-Projects Travel Management System product page
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS overview
6. FIRST EPSS API documentation
7. MITRE CWE-89