A vulnerability has been found in Campcodes School Faculty Scheduling System 1

CVE-2025-0210 is an unauthenticated SQL injection in Campcodes School Faculty Scheduling System 1.0, specifically the login handler at /admin/ajax.php?action=login. The public proof-of-concept shows the username parameter being concatenated directly into a SQL query, enabling blind time-based injection against the app's user database and likely admin auth bypass or data extraction. Publicly documented affected range is only version 1.0; I found no authoritative fixed release from Campcodes.

The vendor/CNA baseline of HIGH 7.3 overstates enterprise urgency. Technically this is a real pre-auth remote bug, but in the real world it sits in a niche educational PHP source-code project, not a mainstream enterprise platform, with very low EPSS, no KEV listing, and no visible evidence of broad attacker attention in the reviewed public sources. For a team managing 10,000 hosts, this belongs in backlog hygiene unless you knowingly run this app on an internet-facing server.

Why this verdict

• Start at vendor HIGH 7.3 because this is pre-auth remote SQL injection on a login endpoint with a public PoC.
• Downgrade for attacker economics because the target is a niche Campcodes educational/source-code application, not a common enterprise platform, which sharply narrows the victim pool.
• Downgrade for real deployment patterns because this kind of PHP school project is often labware, internal-only, or abandoned content rather than a hardened, internet-facing business-critical service.
• Downgrade for blast radius because the sourced evidence supports app/database compromise, auth bypass, and data manipulation, but not a demonstrated direct OS-level RCE chain.
• Hold above IGNORE because if you do have this app exposed, exploitation is easy, unauthenticated, and operationally useful to an attacker.

Why not higher?

A higher score would require a broader exposed population, active exploitation evidence, KEV inclusion, or a clearer path to cross-host compromise. None of that showed up in the reviewed sources. This bug is serious on the individual app, but not strategically important across a normal enterprise fleet.

Why not lower?

It is not IGNORE because the vulnerability is real, reachable over the network, and backed by public proof-of-concept details. If an exposed instance exists in your environment, an unauthenticated attacker can likely extract data or bypass the app's login with very little effort.

1. Inventory the app — Search ASM, CMDB, repo mirrors, and VM/web-server content for School Faculty Scheduling System, /admin/ajax.php?action=login, or the vulnerable SQL string. For a LOW verdict there is no SLA (treat as backlog hygiene), but do this in the next normal hygiene cycle so you can quickly close as not applicable or isolate the rare instance you do have.
2. Restrict admin paths — If you find a live instance, put /admin/ behind VPN, IP allowlisting, or reverse-proxy authentication. This reduces exposure immediately and is the fastest containment step for a PHP app with no clear vendor patch; for LOW there is no SLA (treat as backlog hygiene).
3. Add a WAF rule — Block or challenge SQLi patterns on the login POST to /admin/ajax.php?action=login, especially quote-plus-comment and timing-function payloads. This is only a compensating control, but it meaningfully raises attacker cost on exposed instances; again, LOW means no SLA (treat as backlog hygiene).
4. Patch locally or retire it — Because no authoritative fixed release was located, the practical fix may be code-level remediation: parameterize the query in admin/ajax.php or remove the app entirely if it is non-production sampleware. For LOW there is no SLA (treat as backlog hygiene), so route it through normal application maintenance instead of emergency patch lanes.

Run this on the target web server that hosts the application source, not from your auditor workstation. Invoke it as bash check_cve_2025_0210.sh /var/www/html/scheduling with read access to the app files; root is not required unless the web root is restricted.

#!/usr/bin/env bash
# check_cve_2025_0210.sh
# Detect likely vulnerable Campcodes School Faculty Scheduling System 1.0 login code.
# Usage: bash check_cve_2025_0210.sh /path/to/app
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN / usage / path problem

set -u

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

TARGET_FILE="$APP_PATH/admin/ajax.php"
if [[ ! -f "$TARGET_FILE" ]]; then
  echo "UNKNOWN - file not found: $TARGET_FILE"
  exit 2
fi

# Normalize path for messages
TARGET_FILE="$(cd "$(dirname "$TARGET_FILE")" && pwd)/$(basename "$TARGET_FILE")"

# Heuristics:
# 1) vulnerable function name present
# 2) direct concatenation of $username into SQL query
# 3) login action endpoint likely exists in this app tree
has_login_fn=0
has_username_concat=0
has_password_concat=0
has_users_query=0

if grep -Eq 'function[[:space:]]+login[[:space:]]*\(' "$TARGET_FILE"; then
  has_login_fn=1
fi
if grep -Eq "username[[:space:]]*=.*\$username|where username = '\"\.\$username\.\"'|where username = '\''\.\$username\.\''" "$TARGET_FILE"; then
  has_username_concat=1
fi
if grep -Eq "password[[:space:]]*=.*md5\(\$password\)|password = '\"\.md5\(\$password\)\.\"'|password = '\''\.md5\(\$password\)\.\''" "$TARGET_FILE"; then
  has_password_concat=1
fi
if grep -Eq 'SELECT \* FROM users|select \* from users' "$TARGET_FILE"; then
  has_users_query=1
fi

# Stronger exact pattern match from public PoC/source snippet
if grep -Fq "SELECT * FROM users where username = '" "$TARGET_FILE" && grep -Fq "and password = '" "$TARGET_FILE"; then
  echo "VULNERABLE - found login query with direct username/password concatenation in $TARGET_FILE"
  exit 1
fi

# Secondary heuristic match
if [[ $has_login_fn -eq 1 && $has_username_concat -eq 1 && $has_users_query -eq 1 ]]; then
  echo "VULNERABLE - likely matching vulnerable login code pattern in $TARGET_FILE"
  exit 1
fi

# Look for signs of remediation: prepared statements or parameter binding in file
if grep -Eiq 'prepare\(|bind_param\(|PDO\(|execute\(' "$TARGET_FILE"; then
  echo "PATCHED - no vulnerable query pattern found and prepared-statement indicators exist in $TARGET_FILE"
  exit 0
fi

# If file exists but pattern is unclear, return UNKNOWN rather than over-claiming
if [[ $has_login_fn -eq 1 || $has_users_query -eq 1 || $has_password_concat -eq 1 ]]; then
  echo "UNKNOWN - app file present but vulnerable pattern not conclusively identified in $TARGET_FILE"
  exit 2
fi

echo "PATCHED - vulnerable Campcodes login query pattern not found in $TARGET_FILE"
exit 0

Sources

1. NVD CVE-2025-0210
2. OSV mirror for CVE-2025-0210
3. VulDB entry VDB-290155
4. Public GitHub proof of concept
5. Campcodes project page
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. FIRST EPSS data documentation