In this quickstart guide, we will be learning about the role of object deserialization in security. Deserialization is featured in most major languages and when implemented improperly, either by the language itself or by the application being written, can be a fruitful attack surface. CVE-2017-5941 is an example of flawed implementation of deserialization in the node.js JavaScript framework.

What is Object Deserialization?

Understanding deserialization requires a basic understanding of object-oriented programming. Most modern programming languages allow for improved efficiency by using the concept of an object. The basic structure of an object is programmed, including its functionality and any details that can vary, just once (into what is called a class). This code can then be re-used when multiple versions of this object are needed, ultimately improving efficiency. There are many more benefits to using objects that don't need to be covered for exploring deserialization. If object-oriented programming is a new concept to you, it can help for this guide to think of an object as a filled out form. The software application can print off as many forms as it wants, and fill them out differently.

Deserialization is the act of reversing serialization. Serialization is a complex type of encoding. Much like we base64 encode URL parameters and cookie data, programming languages serialize objects so that they can be transported under constraint. When receiving a serialized object, a programming language or application will process it and convert it back into an object in memory. This is where things can go awry.


CVE-2017-5941 is a deserialization exploit in the node.js JavaScript framework. Node.js is used very widely across the web in modern web applications, and any version that has not been patched and utilizes deserialization is susceptible to attack.

CVE-2017-5941 takes advantage of the conversion moment in deserialization, where the serialized object has been processed and is being put into memory. It does this by serilaizing an "immediately invoked function" into the object.

Immediately Invoked Functions

JavaScipt syntax includes a way to call a function at the same moment it is defined. The syntax is simply appending two parenthesis, "()", after the definition. Example:

alert("I am an example function!");

Now lets draft a function that we might want to execute on a target:

require('child_process').exec('ls /', function(error, stdout, stderr) { console.log(stdout) });

Exploiting CVE-2017-5941

So we know that code can be executed when a function is defined, but its not ever supposed to be the user's role to define functions. Javascript, however, allows functions to be placed inside regular variables. If a web application is serializing user input as a variable (this could be as simple as a variable called first_name that takes a value from a form field), we can modify the data transmission to send an immediately invoked function with our payload instead of the expected value type for the variable.

However, it is important to realize the role of deserialization at this point. Simply sending an immediately invoked function to a server won't accomplish anything. If the payload isnt deserialized, it never gets treated with the respect of "real code". Much like cross-site scripting, or injection attacks, deserialization exploitation is the result of unintentionally running user input as functional code. However, unlike cross-site scripting or injection attacks, this capacity is a necessity. The entire purpose of deserialization is to transport code and data that is intended to be re-entered into the application as functional code.


This truly unique ability to leave and enter your programming language's interpretation layer is what makes serialization/deserialization in all languages worthy of investigation as an attack surface. Many major languages have had deserialization exploits and there are likely to be new and creative ways to break this system in the future.

In this guide, we will take a look at a few exploits that target remote keyless entry (RKE) systems in modern vehicles. We will learn the theory behind the generic rolljam attack and also implement a specific attack on Subaru vehicles. Read Guide

In this guide we will observe one of Java's most dangerous vulnerabilities, CVE-2012-1723. We will analyze the conditions of the vulnerability and work through an example of practical exploitation through a drive-by attack. Read Guide