Subscribe to receive notifications of new posts:

Protection from Struts Remote Code Execution Vulnerability (S2-057)


4 min read

On August 22 a new vulnerability in the Apache Struts framework was announced. It allows unauthenticated attackers to perform Remote Code Execution (RCE) on vulnerable hosts.

As security researcher Man Yue Mo explained, the vulnerability has similarities with previous Apache Struts vulnerabilities. The Cloudflare WAF already mitigated these so adjusting our rules to handle the new vulnerability was simple. Within hours of the disclosure we deployed a mitigation with no customer action required.

OGNL, again

Apache Struts RCE payloads often come in the form of Object-Graph Navigation Library (OGNL) expressions. OGNL is a language for interacting with the properties and functions of Java classes and Apache Struts supports it in many contexts.

For example, the snippet below uses OGNL to dynamically insert the value "5" into a webpage by calling a function.

<s:property value="%{getSum(2,3)}" />

OGNL expressions can also be used for more general code execution:


Which means if you can find a way to make Apache Struts execute a user supplied OGNL expression, you've found an RCE vulnerability. Security researchers have found a significant number of vulnerabilities where this was the root cause.

What’s different this time?

The major difference between the various OGNL related Struts vulnerabilities is where the payload can be supplied.

For example S2-003, S2-005 and S2-009 allowed OGNL expressions to be included in HTTP Parameters. In S2-045, expressions could be supplied via the ‘Content-Type’ header.  And S2-048 worked by inserting OGNL expressions anywhere they might be used incorrectly with the ActionMessage class (most likely via an HTTP parameter).

With S2-057, the payload is supplied via an action’s “namespace”. Semmel do a great job of explaining the exact conditions for this in their disclosure post.

An example is to omit the "namespace" parameter from the  redirectAction result type.

<package name="public" extends="struts-default">
    <action name="login" class="...">
        <!-- Redirect to another namespace -->
        <result type="redirectAction">
            <param name="actionName">dashboard</param>
            <!-- namespace is omitted -->
            <!--<param name="namespace">/secure</param>-->

The documentation describes this parameter as optional. If you don't include an explicit "namespace" then the client can supply it in the URI.

If the client inserts an OGNL expression instead, it will be executed.${#_memberAccess["allowStaticMethodAccess"]=true,@java.lang.Runtime@getRuntime().exec('calc')}/HelloWorld.action

Cloudflare’s got your covered

Cloudflare has rules to protect against this particular vulnerability, and many other Struts vulnerabilities. These have been configured as Block by default, so no customer action is needed, assuming the Cloudflare Specials rule set is enabled in your WAF configuration.

For customers on our Pro, Business and Enterprise plans, you can do this by going to the “Firewall” tab:

Clicking “Web Application Firewall” and setting the toggle to “On”:

Then finally ensuring the “Cloudflare Specials” rule set is set to “On” as well:

Where possible, we signature OGNL expressions in general, because of how dangerous it is for a server to trust any user-supplied OGNL. This allows the WAF to protect you without detailed knowledge of how specific exploits might work.

Additionally, for this and other Struts vulnerabilities, we produce rules that target specific locations where payloads can be supplied in (e.g. URI, parameters, etc). By focusing on specific payload vectors these rules can be much stricter in the range of inputs allowed, without the risk of increased false positives.

What we've seen in the last 24h

Since the disclosure, we've seen a fairly constant rate of attacks targeting S2-057 vulnerability:

About half of these are coming from known vulnerability scanners, however our research has shown that the vast majority of payloads are only probing, rather than attempting to execute malicious actions. The most common tactics for that are using the OGNL expression print extra strings in the server response, or append extra headers.

Aside from that, our Research team have also seen attempts to run various commands:

  • Ipconfig.exe
  • dir
  • 'cat /etc/passwd'
  • /sbin/ifconfig
  • net users
  • file /etc/passwd
  • Whoami
  • id
  • Ping and nslookup commands to contact external servers

If you have any further questions about how our WAF works, or whether you have the right protections in place, please don’t hesitate to reach out to our Support teams.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.

Follow on X


Related posts

July 09, 2024 12:00 PM

RADIUS/UDP vulnerable to improved MD5 collision attack

The RADIUS protocol is commonly used to control administrative access to networking gear. Despite its importance, RADIUS hasn’t changed much in decades. We discuss an attack on RADIUS as a case study for why it’s important for legacy protocols to keep up with advancements in cryptography...

May 30, 2024 1:00 PM

Disrupting FlyingYeti's campaign targeting Ukraine

In April and May 2024, Cloudforce One employed proactive defense measures to successfully prevent Russia-aligned threat actor FlyingYeti from launching their latest phishing campaign targeting Ukraine...

March 14, 2024 12:30 PM

Mitigating a token-length side-channel attack in our AI products

The Workers AI and AI Gateway team recently collaborated closely with security researchers at Ben Gurion University regarding a report submitted through our Public Bug Bounty program. Through this process, we discovered and fully patched a vulnerability affecting all LLM providers. Here’s the story...