A vulnerability was found in Campcodes Project Management System 1

CVE-2025-0213 is an unrestricted file upload flaw in Campcodes Project Management System 1.0, specifically in /forms/update_forms.php?action=change_pic2&id=4. The published proof of concept shows the handler accepting a user-supplied file and moving it into ../images/ without extension or content validation; if that directory executes PHP, an authenticated user can turn an image upload into a web shell and likely remote code execution on the web server. Publicly stated affected versioning is just 1.0, and I could not find an authoritative vendor-fixed release.

The vendor/NVD baseline of MEDIUM 6.3 is directionally right but slightly generous for enterprise prioritization. The decisive friction is not exploit complexity; it is attacker position: this is authenticated remote against a niche downloadable PHP/MySQL project, which implies the adversary already has credentials or a foothold into the app. That sharply narrows real-world reach, even though the post-auth impact can be ugly on a misconfigured PHP host.

Why this verdict

• Downward pressure: requires valid app auth. PR:L is not a paper detail here; it implies stolen credentials, session theft, or another bug first, which makes this a post-initial-access issue.
• Downward pressure: narrow deployment population. Campcodes is a downloadable PHP/MySQL project for small deployments and educational use, not a high-density enterprise platform with broad managed exposure.
• Upward pressure: file upload can become code execution. The PoC is not theoretical; it shows a working multipart upload of a PHP payload into a web path, which is exactly how web shells land.
• Upward pressure: public weaponization exists. A public GitHub PoC lowers attacker effort and raises reliability once someone already has a session.
• Downward pressure: no exploitation evidence and very low EPSS. No KEV entry, no credible campaign reporting, and low EPSS all argue against emergency treatment across a 10,000-host estate.

Why not higher?

It is not HIGH because the attacker does not get to start from the open internet unauthenticated. Requiring a valid application session, plus the likely small and uneven deployment footprint of this software, compounds the friction hard enough that this is not a broad enterprise fire drill.

Why not lower?

It is not LOW because the technical consequence is more serious than the CVSS sub-scores imply when PHP execution is enabled in the upload path. A real public PoC exists, and once an attacker has app access, exploitation is simple enough to produce a durable web shell.

1. Block script execution in upload paths — Disable PHP execution under the application's images/ and other writable directories using Apache/Nginx/PHP-FPM policy. For a MEDIUM noisgate verdict there is no mitigation SLA, but this is the highest-value hardening step and should go into the next routine web-tier change before the 365-day remediation deadline.
2. Restrict access to the app — Put the Campcodes instance behind VPN, reverse-proxy allowlists, or at minimum strong SSO/MFA where possible, because the exploit chain starts with a valid session. There is no mitigation SLA for MEDIUM; apply in the next normal access-control cycle and definitely before remediation closes.
3. Watch for web-shell patterns — Alert on multipart uploads of .php, double extensions, and direct requests to newly created files under /images/. There is no mitigation SLA for MEDIUM; deploy as standard detective coverage while you schedule remediation.
4. Constrain the web service account — Run the app with least privilege, isolate the vhost/container, and remove unnecessary shell tools and secrets from the host so a successful upload has less room to pivot. There is no mitigation SLA for MEDIUM; fold this into normal hardening work before the remediation deadline.
5. Retire or locally fix unsupported installs — If no vendor-fixed release exists, treat local code remediation or product retirement as the actual fix: add strict extension allowlists, server-side MIME validation, and deny executable uploads. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.

Run this on the target web host that serves Campcodes, not from your scanner workstation. Invoke it as sudo bash verify_cve_2025_0213.sh /var/www/html/construction_pms or point it at the application root; it only needs read access to the webroot, but sudo is often required if the files are owned by root or the web user.

#!/usr/bin/env bash
# verify_cve_2025_0213.sh
# Checks Campcodes Project Management System for the vulnerable upload pattern in forms/update_forms.php
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

APP_ROOT="${1:-}"
TARGET_REL="forms/update_forms.php"

if [[ -z "$APP_ROOT" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/construction_pms"
  exit 2
fi

TARGET="$APP_ROOT/$TARGET_REL"

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

if [[ ! -r "$TARGET" ]]; then
  echo "UNKNOWN - cannot read: $TARGET"
  exit 2
fi

content="$(cat "$TARGET")"

has_change_pic2=0
has_move_upload=0
has_images_path=0
has_validation=0
has_php_block=0

printf '%s' "$content" | grep -q "change_pic2" && has_change_pic2=1
printf '%s' "$content" | grep -q "move_uploaded_file" && has_move_upload=1
printf '%s' "$content" | grep -q "\.\./images/" && has_images_path=1

# crude signs of extension/MIME validation or explicit deny rules
printf '%s' "$content" | grep -Eqi "(in_array\s*\(|preg_match\s*\(|mime_content_type\s*\(|finfo_|pathinfo\s*\(|allowed(_|)ext|whitelist|blacklist|application/x-php|php[0-9]?\$|deny)" && has_validation=1

# optional server-side defense check: look for common Apache/Nginx rules near app root
if find "$APP_ROOT" -maxdepth 2 \( -name ".htaccess" -o -name "nginx.conf" -o -name "default.conf" -o -name "*.conf" \) -type f 2>/dev/null | xargs -r grep -Eqi "<FilesMatch.*php|location.*images|deny all|return 403|php_admin_flag engine off|RemoveHandler .*php|SetHandler none"; then
  has_php_block=1
fi

if [[ $has_change_pic2 -eq 1 && $has_move_upload -eq 1 && $has_images_path -eq 1 && $has_validation -eq 0 ]]; then
  if [[ $has_php_block -eq 1 ]]; then
    echo "UNKNOWN - vulnerable code pattern present, but server config appears to block some script execution paths; validate manually"
    exit 2
  else
    echo "VULNERABLE - unrestricted upload pattern detected in $TARGET"
    exit 1
  fi
fi

if [[ $has_change_pic2 -eq 0 && $has_move_upload -eq 0 ]]; then
  echo "PATCHED - vulnerable handler signature not found in $TARGET"
  exit 0
fi

if [[ $has_validation -eq 1 ]]; then
  echo "PATCHED - upload handler contains signs of validation/hardening; review manually to confirm"
  exit 0
fi

echo "UNKNOWN - inconclusive result; review $TARGET manually"
exit 2

Sources

1. NVD CVE-2025-0213
2. OpenCVE record for CVE-2025-0213
3. Public GitHub PoC
4. Campcodes project page
5. Campcodes download page
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS documentation
8. CVE Details entry with EPSS snapshot