CVE-2023-47458 is a missing authorization flaw in SpringBlade 3.7.0 and earlier. NVD scores it 9.8, Critical. The record says a remote attacker can escalate privileges because the project lacks a permissions control framework. I could not confirm a fixed release, so add your own access checks and read the project's current releases.
What's affected
The record lists SpringBlade from bladex, version 3.7.0 and before. SpringBlade is an open source Spring Cloud and Spring Boot development framework hosted on Gitee. No fixed version is named in the record or in the researcher's note.
The weakness listed is CWE-862, missing authorization.
Source conflict on the identifier: the researcher's public note, a GitHub Gist, carries the same description text but is headed CVE-2023-40788, not CVE-2023-47458. The record I was given assigns this description to CVE-2023-47458. Both identifiers may exist for related reports, or one may be a duplicate. Check the NVD entries for both before you record either in a register.
The note describes the issue as insufficient user permission control across functions, reachable by constructing routes directly, with the attack type remote.
How to check if you're exposed
SpringBlade is a framework, so you are exposed if you built an application on top of it. Check your build files for the dependency or the template you started from. For a Maven project:
mvn dependency:tree | grep -i blade
For Gradle, use the equivalent dependencies task and search for blade. If you copied the framework source into your own repository, look for the project version in its pom file or release notes. Anything at 3.7.0 or earlier is in scope.
Then review which of your endpoints depend on the framework's role handling and which have their own checks. The note says the framework did not provide a permissions control layer, so what matters is the code you wrote on top.
What to do now
- Find every service built on SpringBlade 3.7.0 or earlier, using the dependency check above or an inventory scan.
- Check the project's repository for a newer release and read its notes for permission handling changes.
- Add authorization checks to each endpoint in your own code, covering both role and ownership, and deny by default.
- Put sensitive administrative routes behind a gateway rule or network restriction until the application is fixed.
- Test your routes as a low-privilege user and confirm that every administrative function is refused.
Why it matters
Missing authorization, CWE-862, is a different problem from weak login. The user may be signed in correctly and still be allowed to do things reserved for someone else. Frameworks usually offer role checks, but they have to be applied to each route. When the framework has no permissions layer to apply, the burden falls on every developer using it.
The record's score of 9.8 comes from a vector that needs no privileges and no user interaction over the network, with full impact on confidentiality, integrity and availability. The sources do not give detail on which functions an attacker could reach. Take the score as the maximum the vector allows, and test your own deployment to see where it lands.
For teams on frameworks that came from a template, this is a reminder to treat authorization as part of your own code, with its own tests, and not as something inherited. The Safeguard dependency scan can show where the framework sits in your tree.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is SpringBlade itself fixed?
I could not confirm a fixed release from the sources. Check the project repository for current versions.
Why do two CVE identifiers appear for the same text?
The researcher's public note is headed CVE-2023-40788 while the record uses CVE-2023-47458. Check both NVD entries.
Sources
Last reviewed: 19 October 2026.
