Submeter #717703: https://github.com/dromara/sa-token Sa-Token <=1.44.0 Deserializationinformação

Títulohttps://github.com/dromara/sa-token Sa-Token <=1.44.0 Deserialization
DescriçãoVulnerability 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
Fonte⚠️ https://github.com/Yohane-Mashiro/satoken-deserialization
Utilizador
 Yohane-Mashiro (UID 92825)
Submissão17/12/2025 13h57 (há 6 meses)
Moderação28/12/2025 17h00 (11 days later)
EstadoAceite
Entrada VulDB338607 [Dromara Sa-Token até 1.44.0 SaSerializerTemplateForJdkUseBase64.java ObjectInputStream.readObject Elevação de Privilégios]
Pontos20

Want to stay up to date on a daily basis?

Enable the mail alert feature now!