Erleben Sie die Auswirkungen der Path Traversal Vulnerability, die für die jüngsten Apache-Probleme verantwortlich ist
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.
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:
.avif)
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:
.avif)
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:
.avif)
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?
Anfang Oktober veröffentlichte Apache Version 2.4.49, um eine Sicherheitslücke in Path Traversal und Remote Code Execution zu beheben, und dann 2.4.50, um die Tatsache zu beheben, dass der Fix unvollständig war. Wir haben eine Mission entwickelt, um die Risiken in einer realen Umgebung zu demonstrieren. Probiere es jetzt aus.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
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.
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:
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:
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:
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?
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.
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:
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:
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:
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?
Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
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.
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:
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:
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:
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?
Inhaltsverzeichniss
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
The Power of OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
.png)
