A vulnerability was found in Campcodes Student Grading System 1

CVE-2025-0212 is an SQL injection in Campcodes Student Grading System 1.0, specifically in /view_students.php where the id parameter is interpolated into a MySQL query without sanitization. The CNA record and PoC both point to version 1.0; no authoritative fixed version was published in the sources reviewed, and the vulnerable code path appears tied to the student-view workflow in the PHP application.

The vendor/CNA MEDIUM is closer to reality than NVD's later 9.8 CRITICAL enrichment. The decisive friction is privilege requirement: the CNA score says PR:L, the PoC workflow points at an authenticated student-management page, and the product itself is a niche downloadable PHP project rather than a broadly exposed enterprise platform. Public exploit code exists, but this is still mostly a post-login data-layer abuse problem with limited population and partial impact.

Why this verdict

• Auth requirement cuts the blast radius hard: CNA scores PR:L, and the PoC context points to the Students workflow rather than a public unauthenticated endpoint. That means attacker position is *authenticated remote*, which usually implies prior compromise, credential theft, or insider access.
• Population is narrow: this is a downloadable Campcodes PHP/MySQL project, not Exchange, Fortinet, or Confluence. The fraction of enterprises with this exact product exposed is likely tiny, so vendor-medium is already a ceiling in most fleets.
• Public exploit code is real but not enough to upgrade: a GitHub PoC exists, which removes doubt about exploitability and prevents a downgrade to LOW. But CISA ADP also marks exploitation as poc and automatable: no, which is a long way from mass exploitation pressure.
• Impact looks partial, not domain-wide: the likely damage is app-database read/write within the grading system. That's serious for the affected school or department, but it is not the same as pre-auth RCE on an internet edge appliance.
• NVD's 9.8 is not a good operations baseline here: NVD changed the vector to PR:N/C:H/I:H/A:H, but the source record, reference tagging, and PoC context support lower privileges and lower practical impact.

Why not higher?

There is no reviewed evidence of KEV listing, active campaigns, ransomware use, or broad internet exposure. More importantly, the most plausible path requires authenticated access to a niche app, which compounds downward: prior access + specific product + specific endpoint + app-bounded impact.

Why not lower?

This is still a real SQL injection with public exploit material and plausible confidentiality/integrity impact against live student data. If your organization actually runs this application, especially internet-facing, it is too actionable to dismiss as backlog noise.

1. Restrict exposure — Put the grading app behind VPN, campus IP allowlists, or an identity-aware proxy so the vulnerable endpoint is not broadly reachable. For a MEDIUM verdict there is no mitigation SLA, but do this opportunistically as the highest-value risk reducer if the app is still exposed.
2. Enforce strong auth on all app accounts — Because the decisive friction is authenticated access, tighten passwords, disable stale student/staff accounts, and add SSO/MFA in front of the app where possible. There is no mitigation SLA — go straight to the 365-day remediation window, but auth hardening is the best compensating control when no vendor fix is published.
3. Add a WAF rule for view_students.php — Create targeted blocking or alerting for SQL metacharacters and UNION/error-based payloads on the id POST parameter to /grading/view_students.php. Use this as a temporary containment layer where the app cannot be removed immediately.
4. Reduce DB privileges — Ensure the PHP application's MySQL account has only the minimum rights needed; if it cannot write arbitrary tables, the integrity impact drops sharply. This is especially important when the source code cannot be patched centrally.
5. Locally patch the query — If you own the code, replace string concatenation with prepared statements and validate id as an integer. Since no authoritative vendor fixed version was found, a local code fix may be the only realistic remediation path inside the 365-day window.

Run this on the target web server or on a mounted copy of the application source. Invoke it as bash check-cve-2025-0212.sh /var/www/html/grading/view_students.php or point it at the application root like bash check-cve-2025-0212.sh /var/www/html/grading. No root is required if the account can read the PHP source file.

#!/usr/bin/env bash
# check-cve-2025-0212.sh
# Detects likely vulnerable Campcodes Student Grading System view_students.php SQLi pattern.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/error

set -u

TARGET="${1:-}"

if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <path-to-view_students.php|path-to-app-root>"
  exit 3
fi

resolve_file() {
  local input="$1"
  if [[ -f "$input" ]]; then
    echo "$input"
    return 0
  fi
  if [[ -d "$input" ]]; then
    local found
    found=$(find "$input" -type f -name 'view_students.php' 2>/dev/null | head -n 1)
    if [[ -n "$found" ]]; then
      echo "$found"
      return 0
    fi
  fi
  return 1
}

FILE=$(resolve_file "$TARGET") || {
  echo "UNKNOWN - could not locate view_students.php under: $TARGET"
  exit 2
}

# Normalize line endings for matching.
CONTENT=$(tr -d '\r' < "$FILE")

has_post_id=0
has_concat_query=0
has_student_query=0
has_prepared_stmt=0

if grep -Eq '\$_POST\s*\[\s*["\x27]id["\x27]\s*\]' <<< "$CONTENT"; then
  has_post_id=1
fi

if grep -Eq 'SELECT \* From student_info.*STUDENT_ID\s*=\s*\x27\$id\x27' <<< "$CONTENT"; then
  has_student_query=1
fi

if grep -Eq 'mysqli_query\s*\(.*STUDENT_ID\s*=\s*\x27\$id\x27' <<< "$CONTENT"; then
  has_concat_query=1
fi

if grep -Eqi 'prepare\s*\(|bind_param\s*\(' <<< "$CONTENT"; then
  has_prepared_stmt=1
fi

if [[ $has_post_id -eq 1 && $has_concat_query -eq 1 && $has_student_query -eq 1 && $has_prepared_stmt -eq 0 ]]; then
  echo "VULNERABLE - unsafe POST id is concatenated into SQL in $FILE"
  exit 1
fi

if [[ $has_prepared_stmt -eq 1 ]]; then
  echo "PATCHED - prepared statement patterns present in $FILE"
  exit 0
fi

# If file exists but does not match the known vulnerable pattern, we cannot be certain.
echo "UNKNOWN - file found at $FILE but known vulnerable pattern was not confidently matched"
exit 2

Sources

1. NVD CVE-2025-0212
2. OpenCVE record for CVE-2025-0212
3. GitHub PoC: SQL Injection in Student Grading System
4. Campcodes product page: Online Student Grading System in PHP MySQL
5. CISA Known Exploited Vulnerabilities Catalog
6. CVEDetails entry with EPSS display
7. INCIBE-CERT reference for CVE-2025-0212