最近のApacheの問題の原因となったPath Traversal脆弱性の影響を体験する
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
.avif)
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
.avif)
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
.avif)
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49をリリースし、その後、修正が不完全であったことに対応した2.4.50をリリースしました。私たちは、実際の環境でリスクを実証するために、ミッションを構築しました。今すぐお試しください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
始めるためのリソース
OpenText アプリケーションセキュリティのパワー + 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.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
