CVE-2025-8504: Medium File Upload Flaw in Kitchen Treasure

CVE-2025-8504 is a medium severity unrestricted file upload in code-projects Kitchen Treasure 1.0. The photo argument handled by /userregistration.php accepts a file without adequate checks. The record scores it CVSS 6.3 and lists no fixed version, so restrict uploads yourself or take the app offline.

What's affected

• Product: code-projects Kitchen Treasure, version 1.0.
• Component: /userregistration.php, through the photo argument.
• Weaknesses: CWE-284 (improper access control) and CWE-434 (unrestricted upload of a dangerous file type).
• Score: CVSS 3.1 base 6.3, Medium, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L. It is network reachable, low complexity, needs a low privileged account and no user interaction.
• Fixed version: none is listed in the record. No vendor advisory was available to confirm one.

The description in the record calls the issue "critical", but the CVSS 3.1 score of 6.3 is in the Medium band. This post follows the score and flags the difference so you can decide for yourself. The record says the exploit has been disclosed to the public. It is not marked as exploited in the wild and is not in the CISA Known Exploited Vulnerabilities catalog.

How to check if you're exposed

First find out whether the app is running anywhere. Look for userregistration.php in your web roots, including old staging copies and shared hosting accounts.

find /var/www -name "userregistration.php"

Then look at where uploaded photos land and what they are. An upload directory should hold images and nothing else. List anything in it that a web server could run as code:

find /var/www -path "*upload*" \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)

Any hit in a folder meant for profile photos deserves a closer look at who put it there and when. Check the file's modification time against your access logs for POST requests to the registration page.

What to do now

1. Take the app off the public internet, or restrict it by IP address, until the upload handling is fixed.
2. Remove any script files from the upload directory after you have saved them for review.
3. Accept only the image types you need, by allowlist, and check the actual file contents rather than the file name or the type the browser reports.
4. Store uploads outside the web root, or configure the web server so nothing in the upload directory is ever executed.
5. Give each stored file a generated name and drop the original extension.
6. If you saw unexpected files, rotate database and admin credentials stored on that host.

Why it matters

Upload handlers sit on the boundary between a stranger's data and your server. When the app does not check what type of file it is receiving, an attacker can submit something other than a photo. The risk depends on what the server does next. If the file lands somewhere the web server will execute it, a harmless looking registration form can become a way to run code. If the folder is locked down, the same flaw is mostly a storage nuisance.

This is why the score is moderate: it needs an account and the outcome depends on configuration. That also means you can shrink the risk quickly with a server setting, even before the code is fixed.

You can run the free in-browser dependency scan at gold.safeguard.sh/scan on your manifests to see which known-vulnerable packages you carry. It reads dependencies, so it will not see a flaw that lives only in an application's own source.

Quick check

Sources

• Safeguard Gold entry: CVE-2025-8504 (NVD record data: description, CVSS, CWEs, published 2025-08-03)
• The researcher write-up and other reference links in the record could not be retrieved when this post was prepared, so the details above come from the record alone.

Last reviewed: 18 October 2026.