إرسال #717703: https://github.com/dromara/sa-token Sa-Token <=1.44.0 Deserializationالمعلومات

عنوان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)
ارسال17/12/2025 01:57 PM (6 أشهر منذ)
الاعتدال28/12/2025 05:00 PM (11 days later)
الحالةتمت الموافقة
إدخال VulDB338607 [Dromara Sa-Token حتى 1.44.0 SaSerializerTemplateForJdkUseBase64.java ObjectInputStream.readObject تجاوز الصلاحيات]
النقاط20

Want to know what is going to be exploited?

We predict KEV entries!