Technical Articles
F5 SMEs share good practice.
Showing results for 
Search instead for 
Did you mean: 
F5 Employee
F5 Employee

Today a new security bulletin was published by Apache Struts identified by S2-061 and CVE-2020-17530.


This vulnerability is very similar to a one that we already discussed in a previous post, and also the same conditions must be met for a Struts application to be vulnerable.

This new advisory was published because it was discovered that certain Struts tags which are rendered on the server side will still perform double OGNL evaluation despite of the previous fixes that attempted to prevent such condition.

In order to find those tags we set up our Struts application to use an unpatched version of the Struts library, and we created a Struts server-side form tag that both applies forced OGNL evaluation (uses the %{} syntax) on the “id” attribute value and also allows the attribute value to be user controlled.


Figure 1: Struts form tag set to perform forced OGNL evaluation with user-controlled input

When we send a request that contains an OGNL expression in the “id” parameter we can see that our OGNL expression was not evaluated by the server which means double OGNL evaluation did not happen in this case, as expected.



Figure 2: OGNL expression was not evaluated in the form tag id attribute value

However, if we change our application to use an anchor tag instead of a form tag, we can see that on the same request that we previously sent was now evaluated, which means double OGNL evaluation occurred.


Figure 3: Struts application modified to use an anchor tag instead of a form tag


Figure 4: user specified OGNL expression was evaluated in the application anchor tag id attribute value

In the fixing commit we can see that the calls to the “findString “and “findValue” methods that triggered one of the cycles of the OGNL expression evaluation were removed thus preventing our OGNL expression from being double evaluated.


Figure 5: “findString” method call was removed

Mitigation with Advanced WAF

Advanced WAF customers under any supported version are already protected against this vulnerability as exploitation attempts of this vulnerability are detected by existing Java code injection signatures.


Figure 6: Exploit attempt blocked by signature id 200004224

Version history
Last update:
‎08-Dec-2020 17:37
Updated by: