CVE-2025-7181 is a medium severity (CVSS 6.3) unrestricted file upload in code-projects Staff Audit System 1.0. The /test.php file accepts an uploaded file without checking what it is. No fixed version is confirmed, so restrict access to the page and add server side upload checks.
What's affected
The record names Staff Audit System 1.0 from code-projects. The weak spot is /test.php, and the argument is uploadedfile. The record says the attack can be launched remotely and that exploit details are public. The CVSS vector (PR:L) says the attacker needs a low privilege account first.
I could not confirm a fixed version. Neither the record nor the public write-up I read points to a patch. Check the vendor page before assuming one exists.
The description calls the issue "critical", which follows the VulDB wording. The CVSS 3.1 base score in the record is 6.3, which is medium. Both appear in the record, and this post uses the score. The CVE is not in the CISA Known Exploited Vulnerabilities catalog (the record's KEV flag is false).
The listed weaknesses are CWE-284 (improper access control) and CWE-434 (unrestricted upload of a file with a dangerous type).
How to check if you're exposed
This is a flaw in the application's own code, so a dependency scan will not report it. Check the deployment. Find the file and read how it handles the upload:
find /var/www -name "test.php" -path "*staff*"
The public write-up shows the file taking the uploaded file's own name and saving it into a profile/ folder with no check on type or extension. If your copy does the same, it matches the report. Then look in that folder for files that are not images:
ls -la /var/www/html/profile/
Adjust the path to your install. Any script file such as a .php file in an upload folder deserves a close look, along with any file you do not recognise.
What to do now
- Find every copy of Staff Audit System you run, including test installs.
- Remove or block access to
/test.phpif you do not need it. A file named test is rarely meant to stay in production. - Check the upload folder for files that should not be there, and keep a copy for review before deleting.
- In your own code, allow only the extensions and content types you expect, rename files on save, and store uploads outside the web root.
- Configure the web server so the upload folder cannot run scripts.
- Check the vendor page for a patch and record what you decide.
Why it matters
Unrestricted upload turns a simple profile picture feature into a way to put files of the attacker's choosing on your server. The danger depends on where the file lands and whether the server will run it. If an uploaded script can be requested from the web, the upload becomes code execution. That is why the upload folder should never be able to run scripts, whatever else you do.
The fix is dull and reliable: check the type on the server, choose the file name yourself and keep uploads away from places that execute code. The same project also has a separate SQL injection in its login page, CVE-2025-7180, so a team that runs it should review the whole application, not only this file.
Quick check
Is CVE-2025-7181 exploited in the wild?
The record's KEV flag is false and no advisory I read says it is exploited. Exploit details are public, though, so treat it as easy to try.
Why does the score say medium when the description says critical?
The word critical comes from the VulDB description. The CVSS 3.1 score of 6.3 comes from the vector in the record, which needs a low privilege account. Use the score for triage, but do not use it as a reason to leave an upload flaw open.
Sources
Last reviewed: 18 October 2026.
