Experience the impact of the Path Traversal Vulnerability to blame for the recent Apache woes

Published Nov 07, 2022
by Charlie Eriksen
tl;dr?

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

View Resource

At the beginning of October, Apache released version 2.4.49 to fix a Path Traversal and Remote Code Execution vulnerability and then subsequently 2.4.50 to address the fact that the fix in 2.4.49 was incomplete. Perhaps you’ve seen talk on social media about the importance of updating to the latest version to avoid these risks, given that Apache powers 25% of the internet by some estimates. But what’s the deal? How much risk exists here?

Why not try it out  yourself? 

We’ve built a mission to demonstrate the risks in a real-life environment and have made it public for everyone to try. In this Mission, we’ll walk you through how the Path Traversal Vulnerability can impact your infrastructure and applications. Click below to jump right in, or continue reading to learn more about the vulnerability in detail.

Banner that says try out the Apache CVE-2021-41773 Mission
Go to public Mission


About the Path Traversal Vulnerability 

The vulnerability was introduced in the 2.4.49 release (due to a change to the URL normalization function), where a new path normalization function was introduced. Unfortunately, it failed to correctly normalize URL encoded paths. This makes it possible to conduct a path traversal attack if the following configuration is not present:

Deny or permit access to directory file system


And if mod_cgi is enabled, it can also be leveraged into a Remote Code Execution vulnerability. But let’s first dig into URL encoding to better understand what went wrong. 

URL Encoding

At its most basic, the vulnerability occurs due to a lack of consideration for URLs with URL encoding. The newly introduced path normalization function did not fully handle cases where dots were URL encoded. 

Remember that to conduct a path traversal attack, you will need to traverse with the sequence ../. The normalization function, however, is smart enough to strip that out. So what do you do? You can URL encode a .(Dot) down to %2e, and use a sequence like .%2e/. That would work in many cases against Apache 2.4.40. But you can also go one step further and double encode it. The URL encoded version of .%2e/ is .%252e/. This was further able to bypass the attempted normalization by Apache.

But there's a catch

If someone wanted to try to exploit this vulnerability straight in their browser, they would not be successful. This is due to the fact that browsers also try to normalize URLs that are sent to servers. This means that even our double-encoded sequence will be removed. It also means  that we can't simply use a browser to demonstrate this.

You can use cURL to demonstrate this by using the --path-as-is flag, which prevents it from normalizing the URL before sending it:

Curl path as is code with link

Prevention and mitigation

To fully prevent the issue, it's important to keep up to date with the latest patches from Apache. Specifically, you will want to upgrade to 2.4.51 at a minimum. But it's a good practice to upgrade on a regular schedule to stay up to date.

To mitigate against this issue if you are running 2.4.49, ensure that you have included the following in your Apache configuration:

Directory code tags with allowoverride none and require all denied rules

And to prevent Remote Code Execution, disable mod_cgi if you do not utilize it.

Experience the impact for yourself

Interested in exploring exactly what happened and trying it out for yourself? 


Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

Secure Code Warrior named in 2022 Gartner® Cool Vendors™

Published Nov 07, 2022
By Charlie Eriksen

At the beginning of October, Apache released version 2.4.49 to fix a Path Traversal and Remote Code Execution vulnerability and then subsequently 2.4.50 to address the fact that the fix in 2.4.49 was incomplete. Perhaps you’ve seen talk on social media about the importance of updating to the latest version to avoid these risks, given that Apache powers 25% of the internet by some estimates. But what’s the deal? How much risk exists here?

Why not try it out  yourself? 

We’ve built a mission to demonstrate the risks in a real-life environment and have made it public for everyone to try. In this Mission, we’ll walk you through how the Path Traversal Vulnerability can impact your infrastructure and applications. Click below to jump right in, or continue reading to learn more about the vulnerability in detail.

Banner that says try out the Apache CVE-2021-41773 Mission
Go to public Mission


About the Path Traversal Vulnerability 

The vulnerability was introduced in the 2.4.49 release (due to a change to the URL normalization function), where a new path normalization function was introduced. Unfortunately, it failed to correctly normalize URL encoded paths. This makes it possible to conduct a path traversal attack if the following configuration is not present:

Deny or permit access to directory file system


And if mod_cgi is enabled, it can also be leveraged into a Remote Code Execution vulnerability. But let’s first dig into URL encoding to better understand what went wrong. 

URL Encoding

At its most basic, the vulnerability occurs due to a lack of consideration for URLs with URL encoding. The newly introduced path normalization function did not fully handle cases where dots were URL encoded. 

Remember that to conduct a path traversal attack, you will need to traverse with the sequence ../. The normalization function, however, is smart enough to strip that out. So what do you do? You can URL encode a .(Dot) down to %2e, and use a sequence like .%2e/. That would work in many cases against Apache 2.4.40. But you can also go one step further and double encode it. The URL encoded version of .%2e/ is .%252e/. This was further able to bypass the attempted normalization by Apache.

But there's a catch

If someone wanted to try to exploit this vulnerability straight in their browser, they would not be successful. This is due to the fact that browsers also try to normalize URLs that are sent to servers. This means that even our double-encoded sequence will be removed. It also means  that we can't simply use a browser to demonstrate this.

You can use cURL to demonstrate this by using the --path-as-is flag, which prevents it from normalizing the URL before sending it:

Curl path as is code with link

Prevention and mitigation

To fully prevent the issue, it's important to keep up to date with the latest patches from Apache. Specifically, you will want to upgrade to 2.4.51 at a minimum. But it's a good practice to upgrade on a regular schedule to stay up to date.

To mitigate against this issue if you are running 2.4.49, ensure that you have included the following in your Apache configuration:

Directory code tags with allowoverride none and require all denied rules

And to prevent Remote Code Execution, disable mod_cgi if you do not utilize it.

Experience the impact for yourself

Interested in exploring exactly what happened and trying it out for yourself? 


Enter your details to access the full report.

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

Oopsie daisy