CVE-2025-15117
Remote Deserialization Vulnerability in Dromara Sa-Token up to
Publication date: 2025-12-28
Last updated on: 2025-12-28
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 is a weakness in the Dromara Sa-Token library up to version 1.44.0, specifically in the ObjectInputStream.readObject function within the SaJdkSerializer.java file. It allows for manipulation that can lead to deserialization attacks. Such attacks can be launched remotely but are characterized by high complexity and difficult exploitability.
How can this vulnerability impact me? :
The vulnerability can lead to deserialization attacks which may impact the availability of the affected system or application. However, the attack is difficult to exploit and has a low severity score, indicating limited impact on confidentiality and integrity.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection involves identifying if your system uses vulnerable versions of Sa-Token (up to 1.44.0) and if unsafe deserialization is possible. Specifically, check if your environment uses JDK native deserialization in SaJdkSerializer, Jackson polymorphic deserialization with default typing enabled, or Fastjson with autoType enabled. You can monitor network traffic or logs for suspicious serialized byte streams or JSON payloads containing '@class' type metadata being sent to the application. Commands to detect vulnerable components or suspicious activity could include: 1. Checking Sa-Token version in your dependencies (e.g., using Maven or Gradle commands). 2. Searching logs for serialized data or JSON with '@class' fields. 3. Using network capture tools (e.g., tcpdump, Wireshark) to inspect incoming serialized objects or JSON payloads. 4. Scanning your codebase for usage of ObjectInputStream.readObject without ObjectInputFilter or whitelist. Example commands: - `grep -r 'ObjectInputStream.readObject' ./` to find deserialization calls. - `grep -r 'activateDefaultTyping' ./` to find Jackson default typing usage. - `tcpdump -A -s 0 'tcp port 80 or tcp port 443'` to capture HTTP traffic for inspection. - `grep -r '@class' ./logs/` to find JSON payloads with type metadata. These steps help detect potential exploitation attempts or vulnerable configurations. [2, 3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1. Implement ObjectInputFilter (JDK 9+) or custom whitelist checks in SaJdkSerializer to restrict deserialization to safe packages such as `java.*`, `cn.dev33.satoken.*`, and exclude known gadget packages like `org.apache.commons.collections`. 2. Refactor Jackson deserialization by using two separate ObjectMapper instances: one safe mapper without default typing for external/untrusted input, and one unsafe mapper with strict PolymorphicTypeValidator and explicit package whitelisting for trusted scenarios only. 3. For Fastjson or Fastjson2, ensure that autoType is disabled or strictly whitelisted to prevent unsafe deserialization. 4. Avoid processing untrusted serialized data or JSON with polymorphic type information without validation. 5. Consider replacing or upgrading the affected Sa-Token components or switching to safer serialization methods such as JSON with explicit DTOs and field whitelisting or binary serializers requiring explicit class registration (e.g., Kryo). 6. Integrate dependency scanning in CI pipelines to detect gadget classes or vulnerable library versions. These steps reduce the risk of remote code execution or denial of service caused by unsafe deserialization. [2, 3]