Insecure deserialisation

Serialisation turns an in-memory object into bytes; deserialisation turns those bytes back into an object. Native formats in several ecosystems record the type of the object as well as its contents, so the reader instantiates whatever type the bytes name and invokes lifecycle methods on it during reconstruction.

That is the opening. An attacker does not need a vulnerable method in the application’s own code. They assemble a gadget chain out of classes that are already on the classpath, usually from libraries, where one object’s reconstruction calls into another’s, and the last link performs something useful such as running a command or opening a network connection. Public tooling exists that generates these chains for common library combinations, which is why this stops being an exotic bug and becomes a repeatable one.

The recurring mistake is trying to fix it with a signature. Signing a serialised blob stops a third party forging one, and does nothing at all if the attacker is a legitimate authenticated user who can obtain a signed blob and modify what the application does with it, or if the signing key is in the same artefact that was shipped to the client.

The second is a type allowlist implemented as a denylist of known gadget classes. New chains appear as dependencies change, so a list of forbidden types is out of date the next time a dependency is bumped, and this is one of the few classes where static analysis reliably points at the sink. The reliable answer is to use a data-only format, bind it to an expected type, and never deserialise a native object graph that crossed a trust boundary. On a test the giveaway is a cookie, a hidden field, a cache entry or a message queue payload carrying a recognisable serialised header, and it is a common route in estates where a vulnerable library is present but nobody ran software composition analysis.

We flag every place a serialised object crosses a boundary, confirm exploitability out of band rather than by triggering something destructive, and record the exact parameter and encoding. The finding names the framework, the format, the entry point and the evidence, and it is written as a remote code execution path when a chain lands, because that is what it is. We also check the same object format on internal queues, where it is usually unauthenticated. This is part of how we test serialised data crossing a trust boundary.