CVE-2025-8274 is a high severity (CVSS 7.3) SQL injection affecting Campcodes Online Recruitment Management System 1.0. Input in the ID parameter of /admin/ajax.php?action=save_recruitment_status is used in a database query without safe handling. The exploit is public and no patched release is named, so limit exposure and rewrite the query.
What's affected
Campcodes Online Recruitment Management System version 1.0 is the version named in the record. The vulnerable file is /admin/ajax.php?action=save_recruitment_status and the argument is ID. The reporter says the ID value arrives in a POST request.
The reporter states that no login or authorization is needed to reach it, so treat that as the working assumption until you test your own copy.
The record gives a CVSS 3.1 score of 7.3 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. The record's own wording calls the issue critical, which is the language VulDB uses for the report, while the numeric score places it in the high band. Both are shown here so you can decide which to weigh.
No fixed version is listed. Campcodes Online Recruitment Management System is a small PHP project of the kind distributed as sample or learning code, and the sources I read show no vendor patch. Check the project page or your own source drop for any newer release before assuming none exists.
How to check if you're exposed
First find out whether you run it. Search your web roots for the vulnerable file name. Adjust the path to your server layout.
find /var/www -name "ajax.php" 2>/dev/null
If the file exists, open it and look at how the ID value is used. A query built by joining text and the variable, rather than a prepared statement, matches the reported pattern.
Next, see who has been calling it. Your web server access log shows requests to the path.
grep "ajax.php" /var/log/apache2/access.log | tail -n 50
Look for unusual values in the ID field, long strings, quote characters or SQL keywords, and for requests from addresses you do not recognize. Only test copies you own.
You can also run the free in-browser dependency scan at gold.safeguard.sh/scan on the project's manifests. It covers third-party packages, so it will not find a flaw in the application's own code, but it will show what else in the project is out of date.
What to do now
- Find every copy of Campcodes Online Recruitment Management System in your environment, including test and demo installs.
- Take public-facing copies offline, or put them behind a VPN or an allowlist of trusted addresses.
- Rewrite the query in
ajax.phpto use prepared statements with bound parameters, and validate the type ofID. - Run the database account with the least privilege the page needs. A page that only reads should not hold write or admin rights.
- Review access logs and the database for unexpected changes, and rotate any credentials stored in the database if you see signs of misuse.
- If the app is a sample or training project, remove it from any server that holds real data.
Why it matters
This is CWE-89 (SQL Injection), listed under the broader CWE-74 (Injection). The root cause is string building: request data is placed straight into a query instead of being passed as a bound parameter. When data and command share one string, the data can rewrite the command.
The record does not flag this CVE as CISA KEV, and it makes no claim about attacks seen in the wild. It does say a public exploit has been disclosed, which lowers the effort for anyone who finds the app exposed. Software like this tends to show up on small business servers and in student projects that were never meant for production, which is exactly why an inventory matters.
Try it yourself
This demo shows how static analysis flags a query built from request input, which is the pattern behind this class of bug.
Click through it at your own pace, or open it full screen.
Quick check
Will upgrading fix CVE-2025-8274?
The record lists no fixed version for Campcodes Online Recruitment Management System 1.0. Neither the NVD record nor the reporter page names a patch, so the practical fix is to change the code to use prepared statements, or to stop running the application.
Can I just filter the input?
Input filtering helps as a second layer, but blacklists miss cases. Binding the value as a parameter is the reliable control, because the database never parses the value as SQL.
Sources
- CVE-2025-8274 on Safeguard Gold
- https://github.com/ashin9/CVE/issues/1
- NVD record data for CVE-2025-8274, published 2025-07-28
Last reviewed: 18 October 2026.
