CVE-2025-15117
Unknown Unknown - Not Provided
Remote Deserialization Vulnerability in Dromara Sa-Token up to

Publication date: 2025-12-28

Last updated on: 2025-12-28

Assigner: VulDB

Description
A weakness has been identified in Dromara Sa-Token up to 1.44.0. This affects the function ObjectInputStream.readObject of the file SaJdkSerializer.java. Executing manipulation can lead to deserialization. The attack may be launched remotely. This attack is characterized by high complexity. It is indicated that the exploitability is difficult. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-28
Last Modified
2025-12-28
Generated
2026-05-07
AI Q&A
2025-12-28
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
dromara sa-token 1.44.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
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]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart