Exploiting the OpenNMS/Jenkins RMI Java Deserialization Vulnerability

Even though this vulnerability was detected back in 2015 I am only starting to notice it popping up on engagements more frequently.

CVE-2015-8103 – Jenkins CLI – RMI Java Deserialization allows remote attackers to execute arbitrary code via a crafted serialized Java object. Apparently, according to Foxglove security Jenkins and OpenNMS are not the only ones that are affected by this issue, Websphere, Weblogic and JBoss are also affected.

Whilst on a recent engagement I tried using the Metasploit module which was readily available but had problems running I then tried another module which was written by Ben Turner also to no avail, I am really not sure why those modules didn’t work for me but I had no time to debug and had to get something that worked sharpish, So I had to look for other ways and here I will show you what I came up with.

The Exploit

Firstly we need a working exploit. The python script I found by Coalfire Labs  worked a treat for me and allowed me to send the commands needed to gain a shell over to the affected server.

Here’s what the code looks like thanks to Pancho

Before we go ahead and run the exploit there are a few things we need to setup.

Setting the Stage

We will go ahead and use msf_venom to create the payload, type the following and make sure msf_venom is in your path. If it isn’t, then do the following first.

Okay, let’s go ahead and create the payload for our vulnerable Linux system.

Once ran, you should have some output from venom telling you it’s saved the payload with no errors as per below.


Cool! That’s your payload created, now we need to create a handler for your shiny new payload.

Let’s fire up Metasploit, remember to start the database first.



Once you’re at the MSF console we need to load the handler

Now let’s tell it what payload we want to use.

We now need to set some parameters for the payload handler such as the IP and Port. This will be the same IP and Port that you used when you created your payload with MSF_Venom.


Let’s set the LHOST and LPORT parameters to those that we used in the MSF_Venom Payload.

Double check that the settings have been set with the command..


Ok, they’re set, let’s run the handler.



  • We have created our Payload to send to the vulnerable system
  • We have created a handler for the payload to connect to

Now we need to send our payload to the vulnerable system via the exploit we downloaded earlier in the article.

Exploiting the System

Fire up another terminal and leave the handler in the previous session running.

Navigate to the directory where you created your payload and fire up a simple HTTP server with the help of python


You now have functional HTTP server running, we’re now going to use the exploit script to send commands to the vulnerable server, we will grab our payload file, change it’s permissions and then execute it all via the exploit python code.

Launch a new terminal window and navigate to the directory where you stored your exploit code and issue the following command to grab the payload file.

Please Note: Your python file will be named differently
In your SimpleHTTPServer window, you should see a GET request with the status ‘200’
This means the vulnerable server has executed our wget command and grabbed the file from us.

Let’s make it executable (We’re working blind here as there is no output from the server via the exploit code)

Then execute and hope for the best 🙂

Let’s have a look at the terminal session where our handler has been waiting. If the job was successful then you should be greeted with a meterpreter session.


Now it’s up to you where you go from here depending on the context of the user you are.

I hope this helped some of you. If you have any tips/tricks on easier/quicker methods or anything you would do differently please get in touch or comment below.




James Smith

Security Researcher, Penetration Tester & Linux Advocate

One Comment

Leave a Reply