CVE-2026-102364 in mall4j
Summary
by MITRE • 09/29/2026
mall4j through 4.0 fails to validate the sysType field in sa-token sessions, allowing storefront customers to authenticate as back-office users by reusing their session tokens. Attackers can register on the public storefront and use their customer session token to access admin endpoints lacking @PreAuthorize permission checks, including menu listings, file uploads, and configuration endpoints.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability in mall4j versions through 4.0 represents a critical authentication bypass rooted in improper validation of session state management mechanisms. Specifically, the application fails to validate the sysType field within sa-token sessions, which is intended to distinguish between different user roles such as storefront customers and back-office administrators. This design flaw allows an attacker who has registered on the public-facing storefront to leverage their existing customer session token to authenticate against administrative endpoints that lack proper role-based access controls. By reusing a valid session identifier associated with a low-privilege account, the attacker can effectively impersonate a high-privilege user without needing to provide additional credentials or exploit separate authentication flaws in the admin interface itself.
From a technical perspective, this issue stems from the application's reliance on sa-token for session management while neglecting to enforce strict separation of contexts based on system type identifiers. When an administrative endpoint is accessed, the framework should verify that the associated session token corresponds to an administrator context by checking the sysType attribute. However, due to the missing validation logic, the backend accepts any valid session token regardless of its original role assignment. This allows attackers to bypass security checks such as @PreAuthorize annotations if those annotations do not explicitly re-verify the user's current system type or role against a trusted source during each request processing cycle. The flaw essentially treats all authenticated sessions as equally privileged, undermining the principle of least privilege and enabling unauthorized access to sensitive administrative functions including menu listings, file uploads, and configuration modifications.
The operational impact of this vulnerability is severe, as it grants attackers full control over critical backend operations typically reserved for trusted administrators. Once an attacker gains access via a reused customer session token, they can manipulate system configurations, potentially altering application behavior or exposing sensitive data through misconfigured endpoints. The ability to upload files introduces risks associated with arbitrary file execution if the server processes uploaded content without sufficient sanitization. Furthermore, accessing menu listings and configuration settings may reveal internal architecture details, API structures, or hardcoded secrets that facilitate further exploitation stages such as remote code execution or database manipulation. This scenario aligns closely with CWE-287 Improper Authentication where insufficient verification of identity leads to privilege escalation, and maps directly to MITRE ATT&CK technique T1078 Valid Accounts which describes adversaries using legitimate credentials obtained through various means including session hijacking or reuse across different contexts.
Mitigation strategies must focus on enforcing strict context validation within the authentication framework. Developers should ensure that every administrative endpoint explicitly validates not only the presence of a valid token but also its associated sysType attribute to confirm it belongs to an administrator role before processing any request. Implementing separate session namespaces for customer and admin interfaces can prevent cross-context token reuse entirely. Additionally, applying @PreAuthorize checks consistently across all sensitive endpoints ensures that even if session validation is bypassed at one layer, authorization logic will still restrict access based on verified roles rather than just token validity. Regular security audits focusing on role-based access control implementations and automated testing for privilege escalation paths are essential to detect similar flaws in future updates or related modules within the mall4j ecosystem.