Insecure Deserialization in Cassandra

Apache Cassandra stores data as raw bytes in columns defined as blob or through user‑defined types that serialize Java objects. When an application retrieves such a blob and passes it directly to java.io.ObjectInputStream (or a library that does the same under the hood), it trusts the byte stream without validating its contents. An attacker who can write to the table—through a public INSERT, an unprotected UDF, or a misconfigured thrift/CQL endpoint—can inject a maliciously crafted serialized object. When the application later deserializes the blob, the malicious object graph is instantiated, potentially triggering gadget chains from libraries like Apache Commons Collections, leading to remote code execution.

This pattern has been observed in real vulnerabilities. For example, CVE-2021-25646 described a deserialization flaw in Cassandra’s thrift interface where unauthenticated users could send a serialized payload that the server would deserialize during request processing, resulting in code execution on the Cassandra node. Similarly, applications that expose a CQL endpoint accepting user‑supplied blobs for later processing (e.g., caching session objects, storing custom metrics) inherit the same risk if they deserialize without safeguards.

Insecure deserialization can also appear when Cassandra User Defined Functions (UDFs) are written in Java and allowed to execute arbitrary code. If a UDF receives a blob argument and calls ObjectInputStream.readObject() on it, the same attack vector applies, but the malicious code runs inside the Cassandra JVM rather than the application tier.

Because middleBrick performs black‑box testing, it looks for observable signs that an endpoint is deserializing untrusted data without proper safeguards. The scanner sends payloads that contain the Java serialization magic bytes (AC ED 00 05) in various parameters (query string, POST body, HTTP headers) and monitors the responses for:

• Error messages or stack traces that reference java.io.ObjectInputStream, readObject, or known gadget classes (e.g., org.apache.commons.collections.functors.InvokerTransformer).
• Changes in response timing or behavior that indicate the payload was processed (e.g., a delayed error consistent with deserialization attempts).
• Presence of serialized data in the response body (sometimes applications echo back the deserialized object’s string representation).

When such indicators appear, middleBrick flags the finding under the "Input Validation" check, providing the exact payload used and a severity rating based on the presence of exploitable gadget chains in the target’s classpath (detected via fingerprinting of common libraries).

For example, running the middleBrick CLI against a Cassandra‑backed API might look like:

middlebrick scan https://api.example.com/cassandra/data

The output would include a finding such as:

[INSECURE_DESERIALIZATION] High – Java ObjectInputStream used on user‑controlled blob (CVE‑2021-25646 pattern). Payload: AC ED 00 05 …

This tells the developer that the endpoint is likely deserializing untrusted data without proper filtering, prompting a review of the corresponding code path.

The most reliable defense is to avoid deserializing data that originates from an untrusted source. If your application must work with blobs coming from Cassandra, consider the following mitigations:

• Use Cassandra’s native types – store values as text, JSON, or numeric types instead of serializing whole Java objects. This eliminates the need for ObjectInputStream altogether.
• Apply an input validation allow‑list – before deserialization, verify that the blob matches an expected schema (e.g., a specific UUID or a short string). Reject any blob that does not conform.
• Enable Java serialization filters (JEP 290) – configure an ObjectInputFilter that only permits classes from a known safe list. Example filter for a service that should only deserialize java.util.Date and java.lang.String:

ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
    "java.util.Date;java.lang.String;*"
);
try (ObjectInputStream ois = new ObjectInputStream(inputStream)) {
    ois.setObjectFilter(filter);
    Object obj = ois.readObject();
    // safe to use obj
} catch (IOException | ClassNotFoundException e) {
    // handle rejection
}

If you rely on a third‑party library for deserialization (e.g., Jackson, Kryo), configure it to deny polymorphic typing unless absolutely required:

• Jackson – disable default typing or enforce an allow‑list:

ObjectMapper mapper = new ObjectMapper();
mapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NONE); // or use PolymorphicTypeValidator with allowed types
mapper.readValue(blob, MyDto.class);

• Kryo – register only the classes you expect and set the resolver to strict mode:

Kryo kryo = new Kryo();
kryo.register(Date.class);
kryo.register(String.class);
kryo.setRegistrationRequired(true); // disallow unregistered classes
Object obj = kryo.readClassAndObject(input);

Finally, restrict who can write blobs to Cassandra. Use role‑based access control (RBAC) to limit INSERT permissions on tables that hold serialized data, and disable or tightly control Java‑based UDFs unless they are strictly necessary and run with a sandboxed security manager.

By combining these practices—avoiding unnecessary deserialization, filtering allowed classes, and limiting write access—you eliminate the attack surface that middleBrick’s insecure deserialization check would otherwise flag.