A vulnerability classified as critical has been found in code-projects Job Recruitment 1

CVE-2025-0168 is a SQL injection flaw in code-projects Job Recruitment 1.0, specifically the /_parse/_feedback_system.php endpoint where the person parameter is handled unsafely. The CVE record and public PoC both describe remote exploitation against version 1.0, and NVD maps the affected software to cpe:2.3:a:anisha:job_recruitment:1.0:*:*:*:*:*:*:*. I found no authoritative evidence of a vendor-fixed release, so for practical purposes the affected range is 1.0 with no published patch.

Vendor severity at 6.3 MEDIUM is closer to reality for enterprise prioritization than the later NVD enrichment at 7.5 HIGH. Yes, unauthenticated SQLi with public exploit code is technically dangerous, but this product is a downloadable, educational PHP/XAMPP project explicitly documented to run on localhost and on a PC for educational use. That deployment profile sharply reduces exposed population, asset criticality, and fleet-wide blast radius, which keeps this out of the urgent patch-now bucket for most enterprises.

Why this verdict

• Downward pressure: niche deployment — the product is documented as a localhost/XAMPP educational download, which implies a very small exposed enterprise population compared with mainstream SaaS or edge appliances
• Downward pressure: narrow blast radius — exploitation compromises one small PHP app and its database first; it does not natively hand over domain admin, hypervisor control, or an enterprise control plane
• Upward pressure: remote SQLi with public PoC — if you *do* expose it, exploitation is cheap and commodity tooling like sqlmap is enough

Why not higher?

There is no evidence of KEV status, no trustworthy reporting of active campaigns, and no sign this software is broadly deployed in production enterprise estates. The best argument for HIGH is the technical class of bug, but the real-world reachable population is too small and too self-selecting for that to hold up at fleet scale.

Why not lower?

This is still a real SQL injection flaw with a public exploit path and likely no vendor patch. If an internet-facing copy exists, an unauthenticated attacker can probably pull data with very little effort, so dismissing it as mere noise would be sloppy.

1. Pull it off the internet — If any instance is externally reachable, remove direct internet exposure now and place it behind VPN, allowlists, or an internal reverse proxy. There is no mitigation SLA for MEDIUM, but exposed copies should still be contained immediately because the PoC is public.
2. Virtual-patch the endpoint — Add WAF or reverse-proxy rules to block suspicious requests to /_parse/_feedback_system.php and aggressively inspect the person parameter for SQL metacharacters and automation signatures. Use this as a stopgap while you retire, replace, or fork-fix the code within the 365-day remediation window.
3. Restrict database privileges — Ensure the app's DB account only has the minimum rights needed for this app and cannot access other schemas or perform admin actions. This limits post-SQLi blast radius and should be implemented during the same remediation cycle.
4. Hunt for shadow IT copies — Search web roots, VM templates, developer images, and student/lab environments for ai-recruitment-system-master, owlphin.sql, or the vulnerable PHP path. Because this is a downloadable code project, inventory failure is the main operational risk, not patch orchestration.

Run this on the target host or on a mounted webroot checkout of the application source. Invoke it as python3 check_cve_2025_0168.py /var/www/html/ai-recruitment-system-master or python check_cve_2025_0168.py C:\xampp\htdocs\ai-recruitment-system-master; no admin rights are required for a readable source tree.

#!/usr/bin/env python3
# check_cve_2025_0168.py
# Detect likely vulnerable Job Recruitment 1.0 source for CVE-2025-0168.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

import os
import re
import sys

TARGET_REL = os.path.join('_parse', '_feedback_system.php')

VULN_PARAM_PATTERNS = [
    r"\$_GET\s*\[\s*['\"]person['\"]\s*\]",
    r"\$_REQUEST\s*\[\s*['\"]person['\"]\s*\]",
    r"\$_POST\s*\[\s*['\"]person['\"]\s*\]",
]

PREPARED_PATTERNS = [
    r"->prepare\s*\(",
    r"mysqli_prepare\s*\(",
    r"bind_param\s*\(",
    r"PDO\s*::\s*prepare\s*\(",
]

SQLISH = [
    r"select\s+",
    r"insert\s+into\s+",
    r"update\s+",
    r"delete\s+from\s+",
]

CONCAT_PATTERNS = [
    r"\.\s*\$person",
    r"\$person\s*\.",
    r'"\s*\.\s*\$person\s*\.\s*"',
    r"'\s*\.\s*\$person\s*\.\s*'",
]


def read_file(path):
    try:
        with open(path, 'r', encoding='utf-8', errors='ignore') as f:
            return f.read()
    except Exception:
        return None


def exists_file(root):
    candidate = os.path.join(root, TARGET_REL)
    if os.path.isfile(candidate):
        return candidate
    return None


def has_any(patterns, text, flags=re.IGNORECASE | re.MULTILINE):
    return any(re.search(p, text, flags) for p in patterns)


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN')
        print('Usage: python3 check_cve_2025_0168.py <app_root>')
        sys.exit(3)

    root = sys.argv[1]
    php_file = exists_file(root)
    if not php_file:
        print('UNKNOWN')
        print(f'Missing expected file: {os.path.join(root, TARGET_REL)}')
        sys.exit(2)

    content = read_file(php_file)
    if content is None:
        print('UNKNOWN')
        print(f'Unable to read: {php_file}')
        sys.exit(2)

    normalized = content.lower()

    references_person = has_any(VULN_PARAM_PATTERNS, content)
    looks_prepared = has_any(PREPARED_PATTERNS, content)
    looks_sql = has_any(SQLISH, normalized)
    concatenates_person = has_any(CONCAT_PATTERNS, content)

    if references_person and looks_prepared and not concatenates_person:
        print('PATCHED')
        print(f'Prepared-statement pattern detected in {php_file}')
        sys.exit(0)

    if references_person and looks_sql and concatenates_person:
        print('VULNERABLE')
        print(f'Likely unsafely concatenated person parameter in {php_file}')
        sys.exit(1)

    if references_person and looks_sql and not looks_prepared:
        print('VULNERABLE')
        print(f'SQL handling found without clear prepared-statement usage in {php_file}')
        sys.exit(1)

    print('UNKNOWN')
    print(f'File present but signature inconclusive: {php_file}')
    sys.exit(2)


if __name__ == '__main__':
    main()

Sources

1. NVD CVE detail
2. MITRE CVE entry
3. Public PoC markdown
4. Vendor/product page
5. CISA weekly vulnerability bulletin SB25-006
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS overview