CVE-2024-6681 is a medium severity (CVSS 6.3) SQL injection in witmy my-springsecurity-plus, in the /api/dept endpoint, through the 2024-07-04 snapshot. The record names no fixed version. Treat the params.dataScope argument as untrusted, check the upstream repository for a patch, and use bound parameters in your own copy.
What's affected
The record lists witmy my-springsecurity-plus, described as affected up to 2024-07-04. That is a date, not a normal version number, so the project appears to be tracked by snapshot or commit date. The vulnerable endpoint is /api/dept, and the weak input is the params.dataScope argument.
The record names no fixed version. VulDB tracks this as VDB-271154, and the public report is a Gitee issue on the project (issue IAAGZY on gitee.com). Check the project repository for a commit that changes how dataScope reaches the database layer before you assume you are covered.
This is the third report in a short series. The first covers /api/role and the second /api/dept/build.
How to check if you're exposed
Look for the department listing controller and the query it runs. The /api/dept route is the base route for departments, so it is often the most used of the three and the easiest to find in access logs.
grep -rn "dept" src/main/java | grep -i mapper
In web server logs, look for unusual values in the dataScope field of requests to this route. Normal values are short and predictable. A long or oddly formatted value is a reason to read the matching database log lines.
What to do now
- List where my-springsecurity-plus or a fork is deployed.
- Check upstream for a patch tied to issue IAAGZY and note the commit you adopt.
- Replace any dynamic SQL for data scope with parameters or a fixed set of allowed values.
- Review web and database logs for odd
dataScopevalues since July 2024. - Re-run your tests on all three affected routes after the change.
Why it matters
The class is CWE-89. What sets this entry apart is its place as the base route of a department API. Base routes get the most traffic, so any flaw there is easy to reach and easy to find. A reviewer who only fixes the two newer endpoints in the series and misses this one leaves the most visible door open.
The score reflects network access, low complexity and a need for a logged in account, with limited impact on all three of confidentiality, integrity and availability. The public disclosure is noted in the record. The record has no known exploitation entry. Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan for checking the packages your own projects pull in.
Quick check
Which of the three is the most exposed?
The record gives all three the same score. The base /api/dept route is likely the most used, so check it first.
Is there a vendor advisory?
The record points to a public Gitee issue and VulDB, not a vendor advisory. Check the repository for updates.
Sources
Last reviewed: 19 October 2026.
