CVE-2024-13145 is a medium severity (CVSS 6.3) unrestricted file upload in zhenfeng13 My-Blog 1.0, in the upload function of uploadController.java. The record says the exploit is public and names no fixed version. Limit admin access, check the project issue, and add server side upload checks.
What's affected
- zhenfeng13 My-Blog version 1.0.
- The affected function is upload in src/main/java/com/site/blog/my/core/controller/admin/uploadController.java, through the file argument.
The record names no fixed version, and it describes the exploit as publicly disclosed. Check the project's issue tracker and repository for a patch. If none exists, treat the project as unfixed.
How to check if you're exposed
Run the check below, or read the vendor or project notes linked in Sources.
# Look at your build file for the project and its version
grep -n -i my-blog pom.xml
Compare the result to the affected range above.
What to do now
- Inventory any My-Blog 1.0 installations and take unneeded ones offline.
- Check the linked issue for maintainer replies.
- Block script execution in the upload directory at the web server level.
- Restrict the admin path to trusted networks or place it behind a VPN.
- Look up CVE-2024-13145 on its Gold page to see the current details and any fix information.
- Check your own dependency files with the free in-browser dependency scan. It runs in your browser and does not send the file to a server.
Why it matters
This is the second upload flaw reported against My-Blog 1.0, published on the same day. CVE-2024-13144 covers the editor image upload and this one covers the general upload controller. Both carry the same weakness pair, improper access control and unrestricted upload, and the same medium score.
When the same class of bug appears in two places in a small codebase, it usually means no shared upload validation exists. Fixing one endpoint without a common check leaves the others open, so patch the pattern rather than a single function.
This CVE is an arbitrary file upload flaw (CWE-284, CWE-434, Improper Access Control and Unrestricted File Upload). Nothing in the record says it is exploited in the wild, and it is not marked as listed in CISA's Known Exploited Vulnerabilities catalog. That is a snapshot, so keep checking.
File upload handlers are risky because the server ends up storing something a stranger chose. If the handler does not check the file type properly, a file that the web server treats as code can end up in a web-reachable folder, and code that runs on your server is the start of a full compromise.
The usual defenses are an allowlist of file types checked on the server, renaming uploads, storing them outside the web root or with script execution turned off, and requiring authentication where possible. Double extension tricks work only on some server configurations, which is why the advisory language is conditional. The attack complexity is rated high for that reason.
Quick check
Is this a duplicate of CVE-2024-13144?
No. It is a separate flaw in a different function of the same project.
Is the exploit public?
The record says the exploit has been disclosed to the public.
Sources
Note: these pages could not be retrieved when this post was written, so statements rest on the CVE record text. Check the vendor pages for the latest version information.
Last reviewed: 19 October 2026.