CVE-2023-44794 is a critical authentication-bypass and privilege-escalation vulnerability in Dromara Sa-Token 1.36.0 and earlier, where a mismatch between how Sa-Token normalizes request paths and how Spring routes them lets an attacker craft a URL that slips past route-based authentication checks. NVD assigns it a CVSS 3.1 base score of 9.8 (critical), reflecting a network-reachable, unauthenticated bypass with high impact on confidentiality, integrity, and availability.
Sa-Token is a widely used Java authentication and authorization framework in the Chinese-speaking developer community, often paired with Spring Boot. When your authorization layer and your web framework disagree about what path a request is targeting, the gap between them becomes an open door.
The root cause: two views of the same URL
The vulnerability is a classic path-confusion bug. Sa-Token's SaRequestForServlet.getRequestPath() obtained the request path using HttpServletRequest.getServletPath(). Spring, in versions after 2.3.1.RELEASE, changed how it matches and dispatches paths, working from a different representation of the raw URI.
The result is two components looking at the same incoming request and computing two different "paths." Sa-Token evaluates its route interceptors, deciding whether the request needs authentication, against one path. Spring then dispatches the request to a controller based on another. An attacker who understands the discrepancy can construct a URL that Sa-Token classifies as a public, unprotected route while Spring routes it to a protected handler.
Two flaws combined to make this exploitable, per the published analysis: the discrepancy between Sa-Token's getServletPath-based normalization and Spring's raw-URI handling, and the absence of validation for malicious path patterns in the security-check logic.
Why path-confusion bugs keep happening
This is not unique to Sa-Token. Any time authorization is enforced by one layer and routing by another, and the two normalize paths differently, you get an authorization bypass. Trailing slashes, . and .. segments, matrix parameters (;jsessionid=...), encoded characters, and double slashes all get handled inconsistently across frameworks. The security lesson generalizes well beyond this one library: enforce authorization on the same canonical representation your router uses, or authorize inside the handler where the routing decision is already made.
Affected versions and severity
Verified against the NVD record and the vendor advisory:
Affected: Dromara Sa-Token <= 1.36.0
Fixed in: Sa-Token 1.37.0
Condition: Spring Boot >= 2.3.1.RELEASE, or Spring >= 5.3.0
CVSS 3.1: 9.8 CRITICAL
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Published: 2023-10-25
The Spring version condition matters. The bug surfaces because of the path-handling change introduced after Spring Boot 2.3.1.RELEASE, so applications on Sa-Token paired with those newer Spring versions are the exposed population.
How to detect exposure
Start with the dependency version. If your build pulls cn.dev33:sa-token-* at 1.36.0 or below and you are on a modern Spring Boot, treat it as exploitable. A Maven dependency tree makes transitive inclusion visible:
mvn dependency:tree -Dincludes=cn.dev33:sa-token-core
Because Sa-Token is frequently a transitive dependency of internal starters and shared platform libraries, teams often do not realize they ship it. An SCA scanner can surface the affected coordinate across every service and tell you which are on a vulnerable range, which beats auditing each pom.xml by hand.
For runtime confirmation, security testing that exercises route protections, the kind of coverage a DAST scan provides, can reveal whether a protected endpoint is reachable through a crafted path even before you finish the dependency audit.
Remediation
Upgrade Sa-Token to 1.37.0 or later. That version aligns the path handling and adds validation for the malicious patterns that made the bypass possible.
If you cannot upgrade immediately, the vendor documented a configuration workaround: force Spring's path matching back to the older AntPathMatcher strategy so both layers agree on the path representation.
spring.mvc.pathmatch.matching-strategy=ant_path_matcher
Apply that as a stopgap, not a permanent fix. It realigns the two path views but does not add the input validation that 1.37.0 introduced, so the version upgrade remains the correct remediation.
After patching, verify by attempting to reach a protected route through the path variations that caused the confusion. If your authorization interceptor now consistently challenges those requests, the fix is in effect.
FAQ
What is the CVSS score of CVE-2023-44794?
NVD assigns it 9.8 (critical) under CVSS 3.1, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. It is network-reachable, needs no authentication, and has high impact across confidentiality, integrity, and availability.
Which version of Sa-Token fixes it?
Sa-Token 1.37.0. Versions 1.36.0 and earlier are affected.
Is my application vulnerable if I use an old Spring version?
The bug depends on the path-handling change introduced after Spring Boot 2.3.1.RELEASE (or Spring 5.3.0). Applications on older Spring may not exhibit the discrepancy, but upgrading Sa-Token is still recommended.
Does the configuration workaround fully protect me?
It realigns Spring's path matching so the two layers agree, which closes the immediate bypass, but it does not add the input validation shipped in 1.37.0. Treat it as temporary and upgrade the library.