Apache Struts 2: Remote Code Execution Vulnerability

October 04, 2018


Technical Difficulty

Reading time

A new group of security issues have been discovered for applications developed based on Apache Struts, a popular open source framework for developing web applications used by enterprises globally. Applications developed using Apache Struts are potentially vulnerable if they rely on Struts’s special syntax for evaluation. Man Yue Mo, of the Semmle Security Research Team, has discovered and reported several security issues in Apache Struts that may be used to trigger remote code execution.

Organizations and developers who use Struts are warned against the use of the evaluation syntax in Struts, and strongly encouraged to verify that their configuration is safe. Due to the large install base of Apache Struts, previous remote code execution problems in Apache Struts have resulted in great losses for organizations that failed to secure their installations in a timely manner.


The new series of security issues affect several versions of Apache Struts 2, including the most recent release (versions 2.5.17, and 2.3.35), and no versions are guaranteed to be safe. The configuration of a Struts installation determines whether the application is affected. The newly identified security issues affect Struts installations that are configured to use Struts’s evaluation syntax -- ${..} or %{..} --, either in the Struts configuration (defined either in xml or in code), or in Struts tags in their template files (jsp, ftl, etc.). Configurations that allow untrusted input in the evaluation syntax may be vulnerable to remote code execution from such input.

Semmle disclosed the issues to the Apache Struts security team on 20 April 2018. The Apache Struts security team subsequently replied that it is the responsibility of software teams that build applications based on Struts to ensure that untrusted input does not get double evaluated, which can occur in cases where the evaluation syntax is used. Consequently, Struts will not release a patch. Our research suggests that it is relatively easy to accidentally create a vulnerable Struts configuration and that many organizations are unlikely to be aware of these subtle, but critical, security issues. Therefore, we offer the following advice to developers who would like to make sure that they are safe from these vulnerabilities:

I. Avoid use of ${..} or %{..} in Struts tags or configurations

Do not use the either the ${..} or %{..} syntax in Struts tags or Struts configurations (including the xml configurations and in-code configurations with the convention plugin) at all. If you must use one of these syntaxes, be very careful to make sure that no user input is included in them. Bear in mind that user input can often come in surprising ways, e.g. via binding of properties in an Action or some stored database entities that originate from user input.

Example of a vulnerable tag:

<s:hidden name="%{#parameters['name']}"/>

II. Avoid Alias Interceptor in certain configurations

Do not use the Alias Interceptor with any of the names or aliases set with user input, i.e. in following example:

<action name="someAction" class="com.examples.SomeAction">
     <param name="aliases">#{ name : value }</param>
     <interceptor-ref name="alias"/>
     <interceptor-ref name="basicStack"/>
     <result name="success">good_result.ftl</result>

Neither name nor value in the param tag should come from remote user input (e.g. #{#parameters['name'] : #parameters['value']} or if name and value are properties of SomeAction with pubic setters). Any value that name or value turns out to be will be evaluated directly as OGNL, the domain-specific language for customizing Apache Struts.

III. Avoid sanitizing OGNL input by looking for ${..} or %{..} in user input

Do not try to sanitize OGNL input by looking for ${..} or %{..} in user input. Some tags/configurations, as well as the AliasInterceptor will just evaluate user input as OGNL without them being wrapped inside the special ${..} or %{..} syntax. This makes it hard to sanitize input.

About the discovery

The class of vulnerabilities were discovered by Man Yue Mo from the Semmle Security Research team. In his technical blog post about the discovery, Mo explains how he identified the problem using Semmle QL.

Use Semmle technology to keep your code safe

Semmle LGTM finds security vulnerabilities and other critical bugs in codebases and software portfolios. LGTM is powered by Semmle’s QL technology that allows writing queries for deep semantic code search. In the last year, the security team has discovered a large number of security vulnerabilities in open source projects and enterprise codebases using QL and LGTM.com.

Both LGTM and QL technology are free to use for open source projects on LGTM.com. At the time of this disclosure, LGTM.com is constantly analyzing every commit of more than 82,000 open source projects. Project teams from organizations including NASA and Google rely on LGTM.com, while closed source codebases within these organizations are analyzed by Semmle’s enterprise product range.

About Semmle

Semmle secures the software that runs the world, with analytics developers love and CIOs trust. Software engineering and security teams at Credit Suisse, Dell, Google, Microsoft, NASA and Nasdaq depend on the Semmle analytics platform to create more reliable and trustworthy code without slowing down. Headquartered in San Francisco, Semmle is a privately held company funded by Accel, with additional offices in Copenhagen, New York City, Oxford, Seattle and Valencia.

Contact information

If you would like to speak to us about this vulnerability, please contact us at security@semmle.com, or reach out on Twitter: @Semmle