最近の Apache の問題の原因となったパストラバーサルの脆弱性の影響を体験してください
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はパストラバーサルとリモートコード実行の脆弱性を修正するバージョン2.4.49をリリースし、修正が不完全だったという事実に対処するバージョン2.4.50をリリースしました。私たちは、現実の環境におけるリスクを実証するという使命を掲げました。今すぐ試してみてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、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 を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
始めるためのリソース
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.
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.
.png)
