CVE-2024-13191 is a medium severity (CVSS 6.3) unrestricted file upload in ZeroWdd myblog 1.0, in the upload function of uploadController.java. The record says the exploit is public and names no fixed version. Restrict the admin area and add server side upload checks.
What's affected
- ZeroWdd myblog version 1.0.
- The affected function is upload in src/main/java/com/wdd/myblog/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 zerowdd pom.xml
Compare the result to the affected range above.
What to do now
- Locate every myblog 1.0 deployment.
- Check the linked issue for maintainer replies.
- Disable script execution in the folder that stores uploads.
- Limit the admin path to trusted networks.
- Look up CVE-2024-13191 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 upload flaw comes from the same project as CVE-2024-13189, a permission issue in the configuration class. The weakness pair here is improper access control and unrestricted file upload, and the vector needs a low privilege account.
Taken together, the two records suggest the project lacks consistent access and input checks in its admin code. If you depend on it, assume other endpoints share the same gaps, and put controls around the whole admin path rather than one 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 it the same as CVE-2024-13189?
No. That one is a permission issue in a configuration file. This is an upload flaw in a controller.
Do I need an account?
The vector lists low privileges required.
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.
