Struts 2, OGNL and the S2 family

01Why Struts is a filter

StrutsPrepareAndExecuteFilter is a jakarta.servlet.Filter, not a servlet. That single fact explains most of its interaction with the container.

<filter>
  <filter-name>struts2</filter-name>
  <filter-class>
    org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter
  </filter-class>
</filter>
<filter-mapping>
  <filter-name>struts2</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

Consequences worth holding onto:

• It sits inside the container's filter chain, so every filter-ordering concern applies. A filter declared before Struts sees raw requests; one declared after it may never run, because Struts does not call chain.doFilter() when it handles a request itself.
• Mapped to /*, it inspects every request and decides whether the path resolves to an action. Non-actions are passed down the chain to static resources and JSPs.
• It runs after Tomcat has already normalised the URI, so the path Struts matches on is the decoded one.

02The invocation and the stack

The default stack is roughly eighteen interceptors. The order that matters for review:

// defaultStack, abbreviated — declaration order IS execution order
exception → alias → servletConfig → i18n → prepare → chain
  → scopedModelDriven → modelDriven → fileUpload → checkbox
  → datetime → multiselect → staticParams → actionMappingParams
  → params → conversionError → validation → workflow

params runs before validation and workflow. Binding happens first; validation only decides whether execute() is reached. A field is populated with attacker data even when validation later rejects the request — so a setter with a side effect runs regardless.

03OGNL and the ValueStack

OGNL — Object-Graph Navigation Language — is a full expression language. It reads and writes properties, indexes collections, calls methods, constructs objects and references static members.

The last three rows are the problem. An expression language with constructors, static access and sequencing is a scripting language, and if a request value is parsed as one, the request is a script.

The ValueStack is the evaluation root: a stack of objects searched top-down for a property. During an action invocation it holds the action instance, so name resolves to the action's getName() / setName().

// What the framework ultimately performs, via OgnlUtil:
Object tree = Ognl.parseExpression(expression);
Ognl.setValue(tree, ognlContext, root, value);

Note which argument the attacker influences. In parameter binding it is expression — built from the parameter name — not just value.

04The params interceptor

This is the mechanism in one block:

// ParametersInterceptor, shape of setParameters()
for (Map.Entry<String, Parameter> entry : parameters.entrySet()) {
    String name = entry.getKey();          // the PARAMETER NAME
    if (!isAcceptableParameter(name, action)) continue;
    stack.setValue(name, entry.getValue().getObject());
    //        ^^^^ parsed as an OGNL expression
}

So an ordinary form post:

POST /contact/save.action
contact.name=Paul&contact.address.city=Chennai

becomes two OGNL assignments against the action:

stack.setValue("contact.name", "Paul");
stack.setValue("contact.address.city", "Chennai");
// -> action.getContact().setName("Paul")
// -> action.getContact().getAddress().setCity("Chennai")

This is a genuinely elegant binding mechanism and it is also mass assignment by construction. Any property reachable by navigation from the action is writable, including through getters that return shared or persistent objects.

05What the guards actually guard

Struts has two distinct protections. They operate at different points and are frequently confused.

1. Parameter-name filtering — excludeParams

acceptableName() tests each parameter name against an accepted pattern and a set of excluded patterns before the expression is evaluated. The excluded set blocks names reaching class, session, request, application, servlet*, parameters, dojo, struts and java.*-ish shapes.

This is a deny-list over an expression grammar. It is applied to the parameter name as a string, and the grammar has many ways to spell the same navigation — bracket syntax, quoting, case variation, nested expressions. Its history is a sequence of bypasses followed by regex amendments.

2. Runtime member access — SecurityMemberAccess

The second guard sits inside OGNL evaluation. Before any member is accessed, isAccessible() consults excluded classes and package prefixes:

# struts-default.xml, abbreviated
excludedClasses =
    java.lang.Object, java.lang.Runtime, java.lang.System,
    java.lang.Class, java.lang.ClassLoader, java.lang.ProcessBuilder,
    java.lang.Shutdown, ognl.OgnlContext, ognl.MemberAccess, ...

excludedPackageNames =
    ognl., java.io., java.net., java.nio., javax., jakarta.,
    sun., java.lang.reflect., org.apache.struts2.,
    com.opensymphony.xwork2., ...

This is the stronger of the two because it applies at access time rather than to a string. It is still a deny-list, and historical bypasses have worked by reaching an equivalent capability through a class nobody listed.

06S2-045, end to end

CVE-2017-5638. Remote code execution through the Content-Type header, with no authentication and no valid action required. Fixed in 2.3.32 and 2.5.10.1.

The chain is worth following because every step is ordinary code doing its job:

// Shape of the header. Deliberately not a working payload.
Content-Type: %{(#nike='multipart/form-data').
  (#ctx=@com.opensymphony.xwork2.ActionContext@getContext()).
  (#ctx.setMemberAccess(#unguarded)).
  (#cmd='...').
  (@java.lang.ProcessBuilder@... )}

Three properties made this so damaging:

• No valid action needed. Multipart wrapping happens in PrepareOperations, before action selection, so any URL on a Struts-mapped application worked.
• No authentication needed. It executes before the interceptor stack, so authentication interceptors never ran.
• It is a header. Logging, WAFs and request filters that inspected parameters saw nothing unusual.

07S2-057 and the namespace

CVE-2018-11776. Fixed in 2.3.35 and 2.5.17. Same root cause, different entry point: the namespace taken from the URL reaching OGNL evaluation.

It requires a specific configuration — which is why it is a useful illustration that "vulnerable version" is not the same as "vulnerable application":

• alwaysSelectFullNamespace is true (the Convention plugin sets this), and
• an action configuration specifies no namespace, or a wildcard namespace, and
• a result is reached that renders a URL from that namespace.

Under those conditions the URL-supplied namespace is carried through and later evaluated, so a path segment becomes an expression.

<!-- Always declare an explicit namespace -->
<package name="contacts" extends="struts-default"
         namespace="/contacts">
  <action name="view" class="com.example.ViewContactAction">
    <result>/WEB-INF/views/contact.jsp</result>
  </action>
</package>

Review rules that fall out of this:

• Every <package> declares a literal namespace.
• No namespace, action or method attribute is built from a variable.
• Wildcard action mappings (name="*", method="{1}") are read carefully — they are the mechanism behind dynamic method invocation issues as well.
• struts.enable.DynamicMethodInvocation is false. It defaults to false in current versions; confirm rather than assume.

08Triaging a Struts application

Establish the version first, from the artifact

$ unzip -Z1 app.war 'WEB-INF/lib/struts2-core*'
WEB-INF/lib/struts2-core-2.5.10.jar

# Confirm against the JAR's own manifest, not just the filename
$ unzip -p app.war 'WEB-INF/lib/struts2-core*' > /tmp/s.jar \
  && unzip -p /tmp/s.jar META-INF/MANIFEST.MF | grep -i version

A filename can be renamed; the manifest usually cannot be, and a mismatch between the two is itself worth noting.

Then read the configuration

# Dynamic values in evaluated positions — the strongest signal
$ grep -rnE 'namespace="[^"]*\$|namespace="[^"]*%|action="[^"]*\{|method="[^"]*\{' \
    --include=struts.xml --include='struts-*.xml' .

# Constants that widen the surface
$ grep -rnE 'alwaysSelectFullNamespace|DynamicMethodInvocation|excludeParams' .

# OGNL in JSP tag attributes
$ grep -rnE '%\{|\$\{' --include='*.jsp' . | grep -vE 'c:out|fn:escapeXml'

Then prove reachability in a debugger

Static reading tells you what is configured. Breakpoints tell you what happened. Run the lab Tomcat with the debug agent and attach:

$ CATALINA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=localhost:5005" \
    ~/tools/tomcat/bin/catalina.sh run

# Breakpoints that answer the three questions that matter:
com.opensymphony.xwork2.interceptor.ParametersInterceptor#setParameters
    // which parameters were accepted, and what expression each became
com.opensymphony.xwork2.ognl.OgnlValueStack#setValue
    // the expression actually handed to the parser
com.opensymphony.xwork2.ognl.SecurityMemberAccess#isAccessible
    // what the guard was asked about, and what it answered

Stepping through setParameters once makes the whole model concrete: you watch a string from the wire become an expression, and you watch the guard decide. After that the advisories read as variations rather than as separate mysteries.