CVE-2025-15222
Remote Deserialization Vulnerability in Dromara Sa-Token up to
Publication date: 2025-12-30
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| dromara | sa-token | 1.44.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-20 | The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. |
| CWE-502 | The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Dromara Sa-Token up to version 1.44.0, specifically in the ObjectInputStream.readObject function within the SaSerializerTemplateForJdkUseBase64.java file. It allows an attacker to manipulate the deserialization process remotely, potentially leading to unintended code execution or other malicious effects. The attack is complex and difficult to exploit, but the exploit has been publicly disclosed.
How can this vulnerability impact me? :
The vulnerability can impact you by allowing a remote attacker to exploit the deserialization process, which may lead to unauthorized actions such as code execution or data manipulation. Although the exploit is difficult to perform, if successful, it could compromise the integrity, confidentiality, and availability of your system using Dromara Sa-Token.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for suspicious or unexpected Base64-encoded serialized objects in tokens, such as HTTP cookies, headers, or request bodies, especially if the Sa-Token framework is configured to use the JDK/Base64 serialization template. Detection involves inspecting token values for Base64 strings that decode to serialized Java objects. Network monitoring tools or custom scripts can be used to extract and decode these tokens. For example, you can capture HTTP requests and extract the 'satoken' cookie or header, then decode the Base64 content and analyze the serialized object. Commands to detect suspicious tokens might include using curl or tcpdump to capture traffic, followed by base64 decoding and Java deserialization analysis. Example commands: 1) Capture HTTP traffic containing Sa-Token tokens: `tcpdump -i eth0 -A port 80 or port 443 | grep 'satoken'` 2) Extract and decode Base64 token value: `echo '<Base64TokenValue>' | base64 -d > token.ser` 3) Analyze the serialized object with Java deserialization tools or custom scripts to detect gadget chains. Note that detection requires knowledge of the token format and access to network traffic or logs where tokens are stored or transmitted. [1, 3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1) Disable the use of the JDK/Base64 serialization template in Sa-Token and switch to the default JSON serialization template, which is not affected by this vulnerability. 2) Prevent reading tokens from attacker-controlled sources such as cookies by disabling `SaTokenConfig#setIsReadCookie(true)` or equivalent configuration. 3) Restrict or sanitize inputs that can influence token values or session keys to prevent injection of malicious serialized objects. 4) If possible, replace or upgrade the Sa-Token framework to a version that does not use unsafe deserialization or apply patches when available. 5) Monitor and block suspicious tokens or requests that contain unexpected Base64-encoded serialized objects. Since no vendor patch or official fix is currently available, consider isolating or limiting the affected service until a secure version or workaround is implemented. [1, 2]