提出 #717703: https://github.com/dromara/sa-token Sa-Token <=1.44.0 Deserialization

Vulnerability Summary
<=1.44.0

Type: Insecure Deserialization (CWE-502) Component: Sa-Token JDK/Base64 Serialization template does not perform type/filter control during deserialization, ObjectInputStream directly reads any object. If the string value in the persistence layer can be controlled by an attacker and the classpath contains exploitable gadgets (such as Commons-Collections 3.x), it can lead to arbitrary code execution. Trigger: When the JDK serialization template is enabled and a string is retrieved from external storage and then Base64 decoded → JDK deserialization. Default Impact: Default JSON templates are unaffected; only affected when the JDK/Base64 template is explicitly enabled.

Overview of Vulnerability Cause
Sa-Token in Token-Session read path:

Read token from external controllable media (Cookie/Header/Body)
Splice Session Key based on token
Read string from SaTokenDao
Using JDK native deserialization to deserialize a string into an object
No whitelist/blacklist validation was performed on the deserialization type
This allows attackers to construct malicious serialized data, triggering a Gadget chain to execute arbitrary code at ObjectInputStream.readObject() stage.

Affected code:
JDK deserialization entry (without type filtering): SaSerializerTemplateForJdk.java
Base64 wrapped template (after enabling, it goes through the above deserialization path): SaSerializerTemplateForJdkUseBase64.java
DAO converts String and Object, deserialization is determined by the global template: SaTokenDaoByObjectFollowString.java
Token-Session access path (used to trigger reading): StpLogic.java:1480-1510, StpLogic.java
Exploiting Chain
User-controllable Token Input Point
The attacker carries the token in Cookies through HTTP requests

Condition:

SaTokenConfig#setIsReadCookie(true)
Code path (logically equivalent):

HTTP Cookie → SaHolder.getRequest() → getTokenValue()
Token → Token-Session Key mapping
Sa-Token uses the token to construct a Token-Session storage key:

token
↓
splicingKeyTokenSession(token)
↓
如：satoken:token-session:test
This key is completely determined by the attacker-controlled token

SaTokenDao returns malicious strings
When using:

SaTokenDaoByObjectFollowString
:

DAO stores String

Reading Session:

Automatically triggers String → Object deserialization
The attacker only needs to set the value of the corresponding key in the DAO to:

Base64(JDK Serialized Object)
Trigger JDK native deserialization
Core points of the call path:

StpLogic.getTokenSession()
↓
SaSession.create()
↓
SaManager.getSaSerializerTemplate().stringToObject()
↓
ObjectInputStream.readObject()
Here no type checks / security filtering

• ソース: ⚠️ https://github.com/Yohane-Mashiro/satoken-deserialization
• ユーザー: Yohane-Mashiro (UID 92825)
• 送信: 2025年12月17日 13:57 (6 月 ago)
• モデレーション: 2025年12月28日 17:00 (11 days later)
• ステータス: 承諾済み
• VulDBエントリ: 338607 [Dromara Sa-Token 迄 1.44.0 SaSerializerTemplateForJdkUseBase64.java ObjectInputStream.readObject 特権昇格]
• ポイント: 20