CVE-2025-9847 is a medium severity (6.3, CVSS 3.1) unrestricted file upload in ScriptAndTools Real Estate Management System 1.0. The uimage argument in register.php accepts files without enough checks. No fixed release is confirmed, so lock down uploads now.
What's affected
The record lists ScriptAndTools Real Estate Management System version 1.0. The description says manipulating the uimage argument in register.php causes an unrestricted upload, and that remote exploitation is possible. The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L: network reachable, low complexity, a low privilege account needed, and limited impact on each of confidentiality, integrity and availability.
The record names the weakness classes CWE-284 (improper access control) and CWE-434 (unrestricted upload of a file with a dangerous type).
Severity and weakness do not fully agree between sources. The record scores this 6.3 (medium). The independent researcher write-up we fetched, published in August 2025 before the CVE was assigned, describes the same upload flaw as remote code execution and lists CWE 94. Both can be true: a medium score reflects the vector in the record, while the write-up describes what an upload that accepts executable files can lead to on a web server. Read both before you decide how urgent this is for you.
Fixed versions: none confirmed. The record and the write-up name no patched release, and the write-up points to a public project repository on GitHub. Check that project for changes.
The record says the exploit has been made public. It is not in the CISA Known Exploited Vulnerabilities catalog, and nothing we read reports exploitation in the wild.
How to check if you're exposed
Confirm that you run this application and that it is version 1.0. Then look at register.php in your copy and see how the image upload is handled.
grep -n "uimage" /path/to/register.php
find /path/to/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) 2>/dev/null
The first command shows how the uploaded file is received. The second lists script files that have landed in the upload directory. Any server side script file there that you did not put there yourself should be treated as a sign of compromise. Also review web server access logs for requests to files under the upload path.
What to do now
- Stop the web server from running scripts in the upload directory. In Apache, disable script handlers for that path. In nginx, do not pass that path to the PHP handler.
- Change register.php to accept only a short allowlist of image types, check the real file content and not just the name, and store files under generated names.
- Store uploads outside the web root where you can, and serve them through a handler that sets a safe content type.
- Remove any script files you find in the upload directory, then investigate how they got there before you trust the host again.
- Rotate database and admin credentials if you find any sign of misuse.
- Watch the project repository for a fix and check it before you upgrade.
Why it matters
An unrestricted upload turns a profile picture field into a way to place files on the server. If the server then runs a file the attacker chose, the attacker gets code execution under the web server account. That is why a flaw scored medium in a vector can still be serious in practice. The score assumes limited impact; your server configuration decides how limited it is.
The fix has two layers. Validate what is uploaded, and make sure the upload location cannot execute anything. Either layer alone leaves a gap.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is this remote code execution?
The record calls it an unrestricted upload and scores it medium. The researcher write-up we read calls it remote code execution. Whether it reaches code execution depends on whether your server will run an uploaded script, so close that path regardless.
Is there a patched version?
We could not confirm one. Check the project repository and apply the upload checks above yourself.
Sources
- Researcher write-up referenced by the record
- Project repository named in the researcher write-up
- VulDB entry listed in the record (the page would not load for us, so nothing here relies on it)
- Gold vulnerability page
- Free in-browser dependency scan
Last reviewed: 18 October 2026.
