Safeguard
Vulnerability Analysis•

CVE-2025-8752: High Command Injection in spring-shiro-training

CVE-2025-8752 is a High command injection in spring-shiro-training at /role/add. It is a rolling release with no fixed version; do not expose it.

Safeguard Security Team
4 min read

CVE-2025-8752 is a high severity command injection in wangzhixuan spring-shiro-training, in the /role/add function, reachable remotely with no login. The project uses rolling releases, so the record gives no affected or fixed versions beyond commit 94812c1fd8f7fe796c931f4984ff1aa0671ab562. No fix is confirmed, so review your own copy.

What's affected

  • Product: wangzhixuan spring-shiro-training, up to commit 94812c1fd8f7fe796c931f4984ff1aa0671ab562.
  • Component: the /role/add endpoint.
  • Weaknesses: CWE-74 (injection) and CWE-77 (command injection).
  • Score: CVSS 3.1 base 7.3, High, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. It is network reachable and needs no privileges.
  • Fixed version: none. The record says the product uses continuous delivery with rolling releases, so no version details of affected or updated releases are available.

The public report I could read describes the problem differently from the record. The record says command injection at /role/add with a High score. The report, filed on the project's Gitee tracker on 27 July 2025, describes an unauthenticated remote command execution caused by a weak access control rule in the Shiro configuration combined with an unsafe version of the log4j logging library, and says the endpoint is reachable through a path under a static resources route. Both descriptions point at the same endpoint, but they name different root causes. The report says all versions up to the commit are affected. Gitee also shows a content risk marker on the page, so the full details may be restricted.

The record says the exploit has been disclosed publicly. It does not flag exploitation in the wild, and the CVE is not in the CISA Known Exploited Vulnerabilities catalog.

How to check if you're exposed

This is an open source teaching project for Spring and Apache Shiro, so most exposure comes from copies used as a starting point for a real service. Check whether your code descends from it, and which commit you copied.

git log --oneline | head
git merge-base --is-ancestor 94812c1fd8f7fe796c931f4984ff1aa0671ab562 HEAD && echo "contains the affected commit"

Then check your dependencies for the logging library the report names. In a Maven project:

mvn dependency:tree | grep -i -E "log4j|shiro"

Finally, review your Shiro filter chain. Look for rules that treat whole path prefixes as open, and check whether a request to a protected route can reach it through a different path form.

What to do now

  1. Do not expose a copy of this project to the internet.
  2. If you based a service on it, update the logging library and Shiro to current maintained versions.
  3. Review the Shiro filter chain so every route is denied unless it is explicitly allowed, and normalize paths before matching.
  4. Remove or protect the role management endpoints behind real authentication.
  5. Run the service as an unprivileged user in a container with no extra network reach, so a command execution flaw has less to work with.
  6. Watch the project for a fix, and expect that you may have to patch your own copy.

Why it matters

Command injection means attacker controlled text reaches the operating system or the process, which is among the most serious outcomes for a web service. The two root causes in the sources are both classic: an access rule that matches the wrong thing, and a component that does unsafe work with logged or deserialized data.

Rolling release projects are hard to track because there is no version to compare. The honest answer to "am I affected" is a commit hash check, and the honest answer to "is it fixed" is often to patch your own fork.

You can run the free in-browser dependency scan at gold.safeguard.sh/scan on your manifests to see which known-vulnerable packages you carry. It reads dependencies, so it will not see a flaw that lives only in an application's own source.

Quick check

Why does the record give no fixed version?

The project ships continuously from a branch, and the record says so. Compare commit hashes instead of version numbers.

Do the record and the report agree?

On the endpoint and the seriousness, yes. On the root cause they differ, as described above, so review both the filter rules and the dependencies.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.