Fix CVE-2025-15138 upload fullpath extension bypass

[billyp2340]

Summary

Fixes CVE-2025-15138, where the upload fullpath parameter could be used to bypass upload extension validation and influence the final upload destination/name.

Changes

• Validate the uploaded file name from $_FILES['file']['name'] using basename() instead of trusting the submitted fullpath.
• Derive the allowed extension check from the sanitized upload filename.
• Treat fullpath only as a directory hint for folder uploads, not as the authoritative target filename.
• Resolve upload folders with realpath() and reject paths outside FM_ROOT_PATH.
• Ensure chunked upload conflict renaming uses the validated filename and resolved folder path.

Security Impact

This prevents attackers from submitting a crafted fullpath value that causes Tiny File Manager to write an uploaded file with a disallowed extension or outside the intended upload root.

Testing

• Verified the upload path now builds the final destination from the sanitized uploaded filename.
• Verified requested upload folders are resolved and checked against FM_ROOT_PATH.
• Verified existing chunked upload handling still writes to .part files and renames using the validated target path.

[Maikuolan]

Putting aside the proposed changes for the moment, there's a discrepancy between the CVE's description and the actual nature of the exploit/vulnerability as per described by the linked reference at mesquite-dream-86b(dot)notion(dot)site.

The CVE's description describes the exploit/vulnerability as a "path traversal vulnerability" ("This manipulation of the argument fullpath causes path traversal").

The linked reference at mesquite-dream-86b(dot)notion(dot)site describes the exploit/vulnerability as an "unrestricted file upload vulnerability" (or "file extension bypass", depending on preferred terminology). In fact, the linked reference mentions, "but since no directory traversal is needed and only the file extension needs to be changed, the code remains vulnerable...".

I think the CVE's description probably should be reworked a little to better align with the information provided by its linked references (I mention this in case, per chance, whoever originally drafted that CVE happens to read my reply here, and happens to be in a position of still being able to modify it). Just makes it a little easier, when some proposed changes are connected to a public CVE or advisory, to be able to properly review and judge the proposed changes, when everything aligns with relevant source information (i.e., when one can checklist whether x/y/z parts of proposed changes address x/y/z parts of relevant CVEs/advisories and also x/y/z parts of connected relevant source information and so on).