CVE-2025-2219 is a high severity unrestricted file upload flaw (CVSS 7.3) in LoveCards LoveCardsV2 up to version 2.3.2. The /api/upload/image endpoint accepts the file argument without checking it well enough. No fixed version is named, so restrict access and review uploads.
What's affected
- Product: LoveCards LoveCardsV2
- Affected versions: up to and including 2.3.2
- Vulnerable endpoint:
/api/upload/image, argumentfile - CVSS: 7.3 (High), vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L - Published: 2025-03-12
The record says no privileges or user interaction are needed, and that the exploit has been disclosed to the public. The vendor was contacted early and did not respond. The CISA Known Exploited Vulnerabilities flag is false for this CVE, and none of the pages I read report active exploitation. A sibling CVE, CVE-2025-2218, covers an access control flaw in the same release line.
How to check if you're exposed
Check the application and its upload storage.
# list files in the upload folder that are not images (adjust the path)
find /path/to/uploads -type f ! \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" -o -iname "*.gif" -o -iname "*.webp" \) 2>/dev/null
- Confirm the LoveCardsV2 version. Anything up to 2.3.2 is affected.
- Run the command above. Any file that is not an image in an image folder needs review.
- Check proxy logs for requests to
/api/upload/imagefrom addresses you do not know. - Confirm whether the upload folder is served by the web server and whether anything in it can run as code.
A free in-browser dependency scan will cover the project's libraries, but not this upload handler.
What to do now
- Locate every LoveCardsV2 deployment and its version.
- Require authentication on
/api/upload/imageat the proxy or in the application, and cap file size. - Make sure files in the upload folder cannot be executed, and serve them with fixed image content types.
- Remove files that are not valid images after you have reviewed them, and look for related changes elsewhere on the host.
- Watch for a release newer than 2.3.2. Plan an alternative if the vendor stays silent.
Why it matters
The weakness is CWE-434, unrestricted upload of a file of a dangerous type. An endpoint intended for images trusts the file it receives. If the server also runs files of that kind, an upload becomes a way to run code on the host.
The score of 7.3 comes from rated low impacts on each axis with no privileges needed. The real outcome depends on setup. The safe pattern is well known: check content as well as the name, store uploads outside the web root or in a folder that cannot execute, and rename the file on the server so the client never picks the final path.
Quick check
What is the main defence?
Make the upload folder non executable and validate the file content on the server. Authentication on the endpoint helps too.
Is there a patch?
The record names no fixed version and says the vendor did not respond.
Sources
Last reviewed: 19 October 2026.
